1. The short version
Nebulai has two separate halves, and the split is the most important thing to understand about your privacy.
- The hosted account service, run by us. It knows who you are, which organisation you belong to, and whether your installation is entitled to run. It is deliberately built so that it cannot receive your code.
- Your installation, run by you on your own computers. It holds your repositories, indexes, queries and answers. We have no access to it.
The account database is physically separate from any installation database and contains no repository, project, query, source, chunk, embedding, prompt, answer or discovery fields. This is enforced in the schema itself, not only by policy.
2. Who is responsible for your data
For the account service, [legal entity name], [registered office address], is the data controller. We decide what is stored about your account and why.
For your own installation, you are the controller. Your repositories, your GitHub App credentials and everything Nebulai derives from them stay on your infrastructure. We are not a processor of that data, because we never receive it.
Contact us about privacy at [privacy email].
3. What the account service stores
This is the complete list of personal data the hosted service holds.
| Data | Why we hold it |
|---|---|
| Verified email address | Identifies your account and lets us contact you about it |
| Display name | Shown to other members of your organisation |
| GitHub user identifier and login | Links your account to the GitHub identity you signed in with |
| Account status and creation date | Distinguishes active, suspended and closed accounts |
| Terms version and the time you accepted it | Evidence of what you agreed to |
| Organisation name, slug and your role in it | Determines who may approve installations and administer the organisation |
| Session records | Keeps you signed in; only a hash of the session token is stored, never the token |
| Installation name, mode, hostname, version and last-seen time | Shows you which installations belong to your organisation and whether they are current |
| Assigned seat count | Checks your installation against the agreed seat limit; a number only, with no user identities |
| Five health flags | online, database ready, GitHub connected, first repository indexed, MCP verified — booleans only |
| Licence lease records | Proves which entitlement was issued to which installation and when |
| Audit events | Records administrative actions such as approving or revoking an installation |
If you become a paying Team customer, we also hold the billing identifiers and subscription record needed to invoice you.
4. What the account service never receives
The following never leave your installation and are rejected by the account service's request schemas rather than merely discarded.
- Repository contents, source code, file names and commit contents
- Project data, indexes, chunks and embeddings
- Questions you ask, prompts sent to models, and the answers returned
- Discoveries, briefings and any other derived project knowledge
- Your GitHub App credentials, private keys, webhook secrets and MCP tokens
- The identities of individual users of your installation
The only operational information your installation sends us is its version, its seat count as a number, and the five booleans listed above.
5. Signing in with GitHub
Sign-in uses GitHub OAuth with the scopes read:user and user:email only. Those scopes let us read your public profile and your verified email address. They do not grant access to any repository.
The GitHub access token issued during sign-in is used once to read your profile and email, and is never written to our database.
The GitHub App that indexes your repositories is a separate thing that you create and own inside your own installation. Its credentials never reach us.
6. Why we are allowed to process it
| Purpose | Lawful basis |
|---|---|
| Creating your account and organisation, issuing entitlements | Performance of a contract with you |
| Invoicing and managing a Team subscription | Performance of a contract with you |
| Keeping records of terms acceptance and administrative actions | Legal obligation and our legitimate interest in being able to evidence agreements |
| Securing the service, preventing abuse and misuse of entitlements | Our legitimate interest in protecting the service and our customers |
| Contacting you about security, availability or changes to your service | Our legitimate interest in keeping customers informed |
We do not sell personal data, we do not use it for advertising, and we do not use it to train models.
7. How long we keep it
| Data | Retention |
|---|---|
| Sign-in state during the OAuth exchange | 10 minutes, then deleted |
| Installation approval codes | 10 minutes, then expired |
| Browser sessions | 30 days from sign-in, or until you sign out |
| Account, organisation and membership records | For as long as the account is open |
| Terms acceptance records and audit events | Kept after account closure for as long as we may need to evidence the agreement |
| Billing and subscription records | Kept as required by tax and accounting law |
When you ask us to close your account we mark it closed so that it can no longer sign in or hold a role, and we delete or anonymise the data we no longer need. Records we must keep to evidence an agreement or to satisfy tax law are retained for that purpose only.
8. Who else sees it
We keep the number of parties involved deliberately small.
| Who | What they handle |
|---|---|
| [hosting provider] | Hosts the account service and its database |
| GitHub | Authenticates you when you sign in, and receives nothing else from us |
| Our payment processor | Handles Team invoicing, for paying customers only |
We may also disclose data if the law requires it, or to establish or defend legal claims. We will tell you about a legally compelled disclosure unless we are prohibited from doing so.
The marketing website you are reading sets no cookies and runs no analytics or tracking scripts. The account service sets one strictly necessary cookie to keep you signed in, together with a paired anti-forgery token. There is nothing to opt out of.
9. Where it is held
The account service and its database are operated in [hosting region].
Where a provider processes data outside your region, we rely on an approved transfer mechanism such as standard contractual clauses. We will tell you which on request.
10. Your rights
Depending on where you live, you have rights over the data we hold about you.
- Ask for a copy of it, or for it in a portable form
- Ask us to correct it if it is wrong
- Ask us to delete it, subject to records we must keep
- Object to, or ask us to restrict, processing based on our legitimate interests
- Complain to your data protection authority
Write to [privacy email] and we will respond within one month. We may need to confirm your identity first.
These rights cover the account service. For data inside your own installation, you are the controller: a request about that data should go to whoever operates the installation, and it is answered with your own tools, because we have no way to reach it.
11. Security
The account service is served over HTTPS. Session tokens, installation credentials and approval codes are stored only as hashes, so a copy of the database does not yield a usable credential. Entitlements are signed with a private key held outside the application repository.
Approving an installation requires you to check a short code, the hostname and the mode in your browser before granting it, so a device cannot enrol itself into your organisation without a human confirming it.
No system is perfectly secure. If we suffer a breach affecting your personal data, we will notify you and the relevant authority as the law requires. Report suspected vulnerabilities to [security email].
12. Changes to this notice
Each version of this notice has its own identifier and stays available at its own permanent address. We record which version you accepted at sign-up, and we will tell you before a materially different version takes effect.