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.

A small activity log records three events only: an organisation being created, a member joining, and a board being created. Each row holds the organisation, the board where relevant, who acted, the verb, and a short JSON payload — a slug, a role, or a board name. Nothing else is logged: node, edge and comment changes are not recorded, and neither are sign-ins.

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.

Invitations are not currently emailed. No mail provider is wired up: the inviter copies the link out of the interface and sends it however they like, 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.

Billing

For paid plans we store a Stripe customer id, a Stripe subscription id, the plan, the subscription status, the seat count and the current period end. Card numbers never reach NodeKanban; they are entered on Stripe's own pages.

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.

Two companies, both acting on our behalf:

• 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.
• Stripe — processes payments. At checkout we send Stripe the organisation's name, the billing user's email address, the number of seats, and the organisation's id and slug as metadata so that incoming webhooks can be attributed to the right organisation. The seat count is re-sent to Stripe whenever membership changes. Stripe collects card and billing details directly and returns only the identifiers listed above.

There is no analytics SDK, no advertising network, no session recorder and no third-party error-reporting service in this application. Errors are written to our own server log. If that ever changes, this page changes with it.

Two things do cause your browser to contact a third party while you use NodeKanban, which exposes your IP address to them: the site's typefaces are loaded from Google Fonts, and member avatars are displayed from GitHub's or Google's image hosts rather than copied onto our own.

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 Stripe webhook and 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 on a schedule that depends on the plan: 7 days on Free, 90 days on Pro, kept indefinitely on Enterprise. Older entries are removed automatically as new ones are written, so the record of who changed what does not accumulate forever on a free organisation. Activity rows are also removed outright when the organisation or board they describe is deleted.

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. None of that can be undone. Your personal organisation cannot be deleted separately from your account.

Deleting an organisation cancels its Stripe subscription immediately, and so does deleting your account for every organisation that goes with it; the rest of the current billing period is not refunded. What Stripe itself holds — the customer record, the invoices — is kept by Stripe under its own retention rules.

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].

There is no automated export tool today, on any plan. Access and export requests are 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.