What NodeKanban stores, and who else sees it

NodeKanban is operated by [COMPANY LEGAL NAME], [REGISTERED ADDRESS]. For anything on this page, write to [PRIVACY CONTACT EMAIL].

Your account

Your email address, a display name and an avatar URL. The display name is taken from what you type at sign-up, or from your identity provider if you signed in with one. Passwords are handled by Supabase Auth and are never stored by us in a readable form.

Creating an account also creates your personal organisation. Its URL slug is derived from the part of your email address before the @, so that fragment of your address appears in your own board URLs.

Your email address is visible to the other members of any organisation you share. The app shows it in the member list and next to comments when no display name has been set. This is deliberate — a shared workspace has to be able to tell people apart — but it is worth knowing before you join one.

Your organisations and boards

Organisation names and slugs; who is a member and with which role; board names and descriptions; and everything you put on a board — node titles, node bodies, assignees, due dates, positions and colours, the dependency edges between nodes, and comments. That content is yours and can contain whatever you type into it, so treat it the way you would treat any document in a shared workspace.

There are no file uploads or attachments in NodeKanban. Nothing you store here is a file.

While a board is open, your cursor position and presence are broadcast live to the other people viewing that same board. Those messages pass through the connection and are never written to the database.

An activity log records what happens to the organisation and, since it is meant to be worth reading rather than only auditing, to the work itself: an organisation being created, renamed, deleted or converted from personal to a team; a member joining, being removed, or having their role changed; an invitation being revoked (nothing is logged when one is sent, only when it is taken back); a board or a team being created or deleted, a board moving into or out of a team's private view, and someone joining or leaving a team; and a task being finished, or becoming unblocked because whatever it was waiting on finished — those last two name the task by its title in the log entry. Sixteen kinds of event in total, each row holding the organisation, the board where relevant, who acted, the verb, and that short JSON payload. Sign-ins are not recorded.

Invitations

When someone invites a teammate we store the invited email address, the role offered, who invited them, an expiry seven days out, and a one-way hash of the invitation token. The token itself is shown to the inviter once and never stored, so a leak of the database does not leak usable invitation links.

The invite link is always shown to the person who sends it. When a mail provider is configured, the same invitation is also emailed to the address invited, so the inviter does not have to relay it by hand — but the link on screen is the one path that always works, mail provider or not. Unconfigured, no email goes out at all and the message the product would have sent is written to our server log instead. Anyone holding an invitation link can see the organisation name, the invited address, the role, and the name or email of whoever sent it — so treat the link as a secret.

Accepting an invitation does not delete it. The row, including the invited email address, is kept and marked accepted.

Payment

None. NodeKanban is free, we do not sell anything, and we neither collect nor store a payment card, a billing address or any payment identifier.

Rate limiting

Sign-in, sign-up, invitation and organisation-creation attempts are counted against a key that includes the email address involved, so that a password-guessing run can be slowed down. Those counters are discarded about a day after they were last touched.

A handful of companies, each acting on our behalf for one narrow job:

• Supabase — runs the Postgres database, the authentication service and the realtime connection. Everything described above lives there. It also delivers the transactional emails the product depends on: address confirmation and password resets.
• Vercel — hosts the application, and runs its own Web Analytics on every page. That script is cookieless: it counts page views and records the referring page and a coarse device and location — browser, operating system and country, not a precise location and nothing that follows you across other sites. It sets no cookie and no identifier that would let it recognise you again on a later visit.
• Axiom — receives our own application logs, but only once an operator has configured it; unconfigured, those logs go no further than the server's own console. What reaches it is operational — an error, an operation name, a Postgres error code, a request id — never your email address, a request body, or anything you put on a board.
• Resend — when configured, delivers the invitation email described below. Unconfigured, no invitation is emailed and nothing is sent to Resend at all.

Stripe is wired into the codebase for billing that does not exist yet: nothing on any page can start a checkout, and no payment data is collected. If billing is switched back on, this page will say so before it happens.

There is no advertising network, no session recorder and no third-party error-reporting service in this application. Our own errors are written to our own server log (via Axiom, above, when it is configured). If that ever changes, this page changes with it.

One thing does cause your browser to contact a third party while you use NodeKanban, which exposes your IP address to it: member avatars are displayed from GitHub's, Google's or Gravatar's image hosts rather than copied onto our own. The site's typefaces are not part of this — they are downloaded once when the application is built and served from our own domain from then on, so simply loading a page never talks to Google Fonts.

Data is hosted in [HOSTING REGION — CONFIRM IN THE SUPABASE DASHBOARD]. Where that involves a transfer out of your own country, the mechanism relied on is [TRANSFER MECHANISM].

NodeKanban sets session cookies through Supabase's auth library — names beginning sb- and ending -auth-token, plus a short-lived verifier cookie during a sign-in exchange. They carry your session and are refreshed as you browse; without them the app cannot keep you signed in.

One cookie is ours: nb-auth-next. It holds the in-app page you were trying to reach when you were asked to sign in, lasts an hour, and is cleared as soon as it has been used.

There are no analytics or advertising cookies and no consent cookie. Your light/dark theme preference is kept in your browser's local storage under nb-theme and never leaves your device.

Access is enforced in the database itself, by Postgres row-level security, and not only by the interface. Somebody who is not a member of your organisation cannot read its rows, including over the realtime connection. Inside an organisation, what you can see and change follows your role: owner, admin, member or viewer.

Operating the service requires a credential that bypasses row-level security. It is confined to server-side code, is never sent to a browser, and is used only by the invitation lookup that has to work before you are a member. Beyond that, [DESCRIBE WHO ON THE TEAM HAS PRODUCTION DATABASE ACCESS AND UNDER WHAT CONTROLS].

Your content is kept until you delete it. Boards, nodes, edges and comments stay until you or your organisation's owner removes them, or until you delete your account. No job deletes them on a timer.

The activity log is the one exception, and it is trimmed automatically: entries older than 90 days are removed as new ones are written, so the record of who changed what does not accumulate forever. Activity rows are also removed outright when the organisation or board they describe is deleted — except the single row that records an organisation's own deletion, which survives with the organisation's identifier cleared, because nothing is left to attribute it to and it is the one entry the log cannot lose.

What you delete yourself is genuinely deleted. Removing a node removes its comments and its edges; removing a board removes its nodes; an owner deleting an organisation removes every board, node, edge, comment, invitation, membership and activity row in it, bar the one tombstone row described above. None of that can be undone. Your personal organisation cannot be deleted separately from your account.

You can edit your organisation and boards, and delete your own content, from inside the app. Two of those live on your account page:

• Changing your display name or avatar. Account → Profile, at any time.
• Deleting your account. Account → Danger zone, confirmed by typing your own address. It removes your profile, your personal organisation and any organisation you were the last member of. Where you were an organisation's last owner but not its last member, ownership passes to the longest-standing member so the organisation is not left unreachable. Content you created in other people's organisations — nodes, edges and comments — stays on their boards, with your name detached from it. It cannot be undone.

Anything else, write to [PRIVACY CONTACT EMAIL]. We aim to respond within [TARGET RESPONSE TIME].

Depending on where you live you may have rights to access, correct, export, delete or restrict the processing of your personal data, and to object to it. [LIST THE RIGHTS THAT APPLY UNDER THE GOVERNING LAW CHOSEN IN THE TERMS].

You can export a board as a spreadsheet yourself from any board you can open, and an organisation owner or admin can export the whole organisation as one file from Settings → General. A request that goes beyond that self-serve export is fulfilled by hand at [PRIVACY CONTACT EMAIL].

[SUPERVISORY AUTHORITY OR COMPLAINTS ROUTE, IF APPLICABLE].

Authorization lives in the database, so a mistake in the interface cannot hand out rows the database would refuse. Invitation tokens are stored only as hashes. The credential that bypasses row-level security never leaves the server. No system is perfect; if you find a problem, report it to [SECURITY CONTACT EMAIL].

[BREACH NOTIFICATION COMMITMENT AND TIMEFRAME].

NodeKanban is not intended for children. You must be at least [MINIMUM AGE] to hold an account.

We will update this page when what we store or who we send it to changes, and revise the date at the top. Questions go to [PRIVACY CONTACT EMAIL]. The terms of service cover the rest of the relationship.