What this instance stores, and what it does not.

This policy describes what the software actually does, rather than reserving every right a template would. Where the answer is 'nothing', it says nothing.

Last updated 7 August 2026

Not legal advice — and not written by a lawyer

This document was written by the developer who built PhaseBoard, in order to describe the implementation accurately. He is not a lawyer, this is not legal advice, and the page has not yet been reviewed by a qualified professional. That review is planned before any payment is taken or any wider data collection begins.

So read it as an honest technical description of what the software does — which is what it is — and not as a document that has been checked against the privacy law of your country.

Who runs this instance.

PhaseBoard is self-hosted software operated by one person, Umair Mahmood, on a rented virtual server. There is no company, no support desk and no third-party platform sitting between you and it.

“We” below means that one operator. This policy covers this instance of PhaseBoard — the public pages you are reading and the signed-in application behind them.

Reading these public pages collects nothing.

If you never sign in and never submit a form, this site learns nothing about you that it keeps.

You are set no cookie at all. Not an analytics cookie, not a preference cookie, not a 'strictly necessary' one — none, which is why there is no consent banner to click through.
No request is made to any other server. No fonts, scripts, images, embeds or beacons are loaded from anywhere but this domain, and the content-security policy served with these pages enforces that rather than relying on our restraint.
The public pages are rendered ahead of time and served as static files, so there is no per-visitor processing to record.
The web server in front of the application keeps ordinary access logs, as any web server does. Those are used to keep the service running, not to build a profile, and nothing is joined to them.

The waitlist and the contact form.

These are the only two ways a visitor who is not signed in can send us anything.

Both forms are open. This section was written while they were still disabled, describing what would be collected when they opened; they opened, and it describes what is collected now. Nothing beyond the fields listed below is captured — no cookie is set by either form, and no fingerprint, referrer or analytics identifier is stored with a submission.

The web server’s ordinary access logs still exist, as described above, and the application applies a per-connection submission limit so neither form can be used for anything other than what it is for.

The waitlist form

email address: The only field the form asks for. It is stored so the operator can reach you when access opens — nothing is sent to it now, because this instance sends no email at all.
what you would use it for: An optional free-text note the endpoint accepts but the form does not currently ask for. If it is ever added, this is what it would be: optional, and stored as nothing when left empty.

Joining the waitlist creates no account, grants no access and signs you in to nothing. The confirmation you get is identical whether the address is new, already on the list, or already belongs to an account — deliberately, so the form cannot be used by anyone to test whether a person has an account here.

The contact form

name, email address, message: Stored in this instance's own data, where the operator reads them. Nothing else is captured from the form.

Your message is not emailed anywhere, because this instance sends no email. It is stored and read in the app. That also means we cannot promise a response time, and we do not.

If you have an account.

Accounts are created by the operator — there is no self-serve signup — so the information we hold about you is the information needed to give you an account and to run the board.

name, email address: Supplied by the operator when your account is created. Your name is shown next to work you are assigned or that you author.
password: Stored only as an Argon2 hash. The password itself is never written to disk or to a log, and cannot be recovered from what is stored — only replaced.
role, organization and project membership: What you are allowed to reach. Checked on the server for every request.
your work: Tasks, specs, comments, links, labels, attachments, project documents and design bundles you create, plus an activity trail recording who changed what and when.

The one cookie, and only for signed-in users.

app-session: The only cookie this product sets. It holds a signed token carrying your user id, your role and a password-change counter — nothing else, and no personal information.
httpOnly, SameSite=Lax, Secure: It cannot be read by JavaScript in your browser, it is not sent along with requests from other sites, and over HTTPS it is only ever sent encrypted.
eight hours: Its lifetime. It is renewed while you keep working and deleted when you sign out. There is no other cookie, no local-storage identifier and no fingerprinting.

Where the data lives, and why its history is kept.

PhaseBoard stores everything as files on its own server. There is no external database service and no data warehouse.

Those files are a git repository. Every change to a task, a document or a setting becomes a commit, which is what gives the product its version history and its offsite backup — the repository is pushed to a private repository on GitHub that only the operator can read. GitHub therefore holds a copy of the same data, as the backup destination.

This is worth understanding because it has a real consequence: history is retained by design. Editing a comment does not remove the earlier version from the repository’s history, and the product deliberately archives rather than hard-deletes tasks, projects and accounts, so that the record of what a team decided cannot quietly disappear. See section 08 for what that means for a removal request.

Files you attach are stored the same way. Large ones are held through git large-file storage, still inside the same private repository.

Sign-in attempts are recorded, including your IP address.

This is the one place the product deliberately records a network identifier, so it is stated plainly rather than buried in a clause about 'security purposes'.

Every sign-in success and failure appends one line to an audit log containing the time, the email address that was submitted, a best-effort client IP address, and — for password changes, resets and role changes — which account and which administrator was involved.
It exists to lock out password guessing: repeated failures from the same address and email temporarily block further attempts, and re-reading the log after a restart is how those blocks survive it.
It never contains a password, a password hash or a session token. The log's shape is fixed in code so that no free-text field exists to leak one into, and a test greps the written file to prove it.
It is capped: the file rolls over at 5 MB and three previous generations are kept, so old entries age out rather than accumulating forever.
Application logs are separate and record the route, timing and an error code — not your IP address, and never an authorization header or a cookie, both of which are redacted before a line is written.

How long it is kept, and how to have it removed.

Waitlist entries and contact messages are kept until they have been dealt with and are no longer useful; there is no fixed schedule because there is no automated clear-out. Account data is kept while the account exists. The sign-in audit log ages out as described above.

To have your waitlist entry, your contact message or your account data removed, ask through the contact page. The operator handles the request personally, because there is nobody else to hand it to.

One honest limitation: removing something from the live store does not by itself remove earlier versions from the git history described in section 06. Erasing it there means rewriting that history, which the operator will do on request — but it is a manual job, not an instant one, and it is better that you know that before you decide what to put in.

What this product never does.

No third-party analytics, product analytics or session recording. None is installed, and the content policy these pages are served with would block one.
No advertising, no ad networks, no tracking pixels, no cross-site or cross-device tracking, no advertising identifiers.
No selling, renting or trading of personal information, and no sharing of it for anyone else's marketing.
No profiling and no automated decision-making about you.
No email address is used to send you anything — this instance has no outbound email at all.
No personal information in a URL, a query string or an application log line.

Changes to this policy.

The date at the top of the page is the notice. There is no mailing list to announce a change on, and we are not going to start one for this. If the product begins collecting something it does not collect today, this page changes in the same release.

Questions about any of it are welcome through the contact page.