Coral Hub: privacy details

This is the full version. A shorter summary is on the Coral Hub privacy information page.

This page describes the Coral Hub service we operate at app.coralhub.dev. It does not apply to a hub you host yourself using coral --hub (see Run your own hub). On this page, “the hub” means Coral Hub (the hosted service at app.coralhub.dev).

Coral Hub is in closed beta. This page describes how the hub handles your data. It is a technical disclosure written in plain language, not legal advice. It is about Coral Hub only: the Coral app privacy policy covers the Coral desktop app.

Last updated: 17 October 2026. Coral Hub is in closed beta; this information may change, and we will update the date when it does.

The short version

Coral Hub can read what passes through it. When you open a terminal, chat or file from one of your Coral machines in the hub, the content travels from your machine to the hub and on to your browser. Both connections use TLS, but the hub is the end of each one, so it can read the content while it passes through. This is not end-to-end encryption.
Coral Hub does not save that content. It is held in memory while it is being relayed and is not written to the database, the logs or disk.
Coral Hub does save a small amount of account information, listed below.

What the hub keeps in memory briefly

To show your agents in one list, the hub keeps a short summary of each connected machine's agents in memory (names, status, branch, a short summary, token counts; at most 500 live agents plus up to 200 archived ones per machine, about 1.25 MiB in all). If a machine's connection drops, the hub keeps only presence (name and status, not summaries, prompts, paths or commands) for 10 minutes and then forgets it. None of this is written to disk or the database. A signed-in session's account id and email are also held in memory for a few seconds, so the hub does not have to read the database on every request (a short session cache); nothing new is written anywhere.

What passes through the hub but is not stored

Terminal output and the keys you type, chat messages, file contents and listings, agent prompts, task and board data, and the requests used to launch agents. Hub logs record only that a request happened (method, route name, result, size, duration), never its content, its query string or any credential.

If you are not comfortable with a service operated by someone else being technically able to read this traffic while it is in transit, do not connect that Coral machine to the hub. Local Coral keeps working without the hub.

Messages between your own Coral machines (team messaging)

Team messaging is on by default for new accounts; accounts created before that change keep the setting they had. Nothing flows until you link two teams, one direction at a time, and you can switch it off at any time in Coral Hub. The receiving Coral machine’s own settings still decide what it accepts.

What it does. When team messaging is on and you have linked two teams, the hub passes a message from a team on one of your Coral machines to a team on another of your Coral machines. This happens between your machines, without a browser open, and the hub can read the message while it passes through.
It does not store the message. The message is held in memory only while it is being delivered. It is not written to the database, the logs or disk, and there is no queue. To stop duplicates, the hub keeps the sender's message id (not the content) in memory for 10 minutes. If the receiving machine is offline, the message is refused, the sender is told it failed, and it can send the message again.
Links are yours to control. A message can only go along a link you created, from one named team to one named team. A link works in one direction only (you can approve both directions in one step, which creates two links). You can revoke a link, or switch team messaging off, at any time.
Notices to both teams. When you create or revoke a link, Coral Hub posts a short notice to the message boards of both teams (for example, "You can now message homelab/platform (via Coral Hub)"). The text is fixed and written by Coral; nothing is stored for it, and if a machine is offline the notice is not delivered later.
A machine can ask where it may send. A Coral machine can ask the hub which teams a given team is linked to. The hub answers with only the addresses you approved for that team. It is not a directory: it does not list your other machines or teams.
Machines in your account only. A message can only reach a machine in your own account.

Planned billing and Hub team data

Billing is not live. The following describes the planned billing model for the closed beta, subject to confirmation of coverage and eligibility before launch.

Coral Hub subscriptions purchased through Managed Payments will be sold through Stripe/Link as merchant of record for covered sales. Stripe/Link will collect billing and payment information under its own terms and privacy notice. Coral Hub does not store payment-card details, billing addresses or tax IDs. See Stripe's privacy notice and Managed Payments terms.

The planned Team billing system keeps customer and subscription identifiers, the plan, seat counts, subscription status and dates so it can manage the subscription. Team data stays with Coral Hub: the team's name, membership and roles, and records of team changes. The planned Individual subscription is separate product work; its included features and billing-data details have not yet been defined.

Under the planned model, Stripe/Link will handle covered indirect taxes, transaction support, refunds and disputes under its own terms; Subgentic will handle Coral Hub product support. A refund does not by itself cancel a subscription.

Deleting a Hub team: under the planned deletion flow, members are removed immediately, the subscription is cancelled, and team data is removed once cancellation is confirmed. A record that the team existed is kept. Deletion cannot be undone. Deleting a Coral Hub team does not delete Stripe's transaction records, which Stripe may retain for legal, accounting and fraud-prevention purposes.

What we store, why, and for how long

Data	Why	How long
Email address	Your account and sign-in links	For as long as your account exists. During the closed beta, write to hello@subgentic.ai and we will close and disable your account promptly, once we receive your request; erasure of its data will follow when our erasure job ships (see “Closing your account” below)
GitHub numeric id (if you sign in with GitHub)	To recognise you on later sign-ins. We do not store your GitHub access token or other profile data	For as long as your account exists; closing the account does not yet erase it
Sign-in identifier from Auth0, and the sign-in method used (if you sign in with Google)	To recognise you on later sign-ins. The hub asks Auth0 for your email address only; we do not store your name or picture, and we do not store any Auth0 or Google access token	For as long as your account exists; closing the account does not yet erase it
Machine labels, settings (for example the machine's access mode: view, interact or launch) and last-seen time	To show and manage your connected machines	Until you remove the machine. Closing your account does not yet erase it
Dashboard preferences: theme, default agent type and permission mode, diff mode, display toggles, your custom colour themes, tags, folder tags and saved views	So the web dashboard looks and behaves the way you set it, on every device	Until you change or delete them. Closing your account does not yet erase them. Never contains session content or paths from your machines other than the folder names you tag
Team links you create (if you use team messaging): the sending and receiving machine, and the team names you chose on each	To know which team may message which team	Until you revoke it; a revoked link is kept for 30 days, then deleted automatically; all your links go when the machine is removed
Machine address names: a short name for each machine (for example `mac-mini`), made from the machine's label when it is enrolled and used to address messages between your machines	So a team can name another of your machines when sending a message	Kept after a machine is removed (the name is reserved and never reused). Renaming the machine does not change its address name
Hashed machine tokens	To let your Coral machine reconnect. We store only a one-way hash, never the token itself	Until revoked; revoked machines are kept for 30 days for the audit trail, then deleted
Hashed session identifiers	To keep you signed in	Deleted at sign-out; at most 24 hours idle and 30 days total
Hashed one-time codes: sign-in links, OAuth state, machine enrollment codes	To complete sign-in and enrollment	Minutes to hours; expired rows are purged automatically
Audit events: sign-in, sign-out, enrolling or revoking a machine, setting changes, launches from the web, and turning auto-accept on or off (time, your account, the machine, on or off; never the agent name or any prompt text), and, if you use team messaging, switching it on or off and creating or revoking a link (time, your account, the machine and your IP address, but not your browser's user-agent text). Relayed messages are recorded separately: only ids, the outcome (delivered or why not) and the size in bytes, with no IP address or browser text, and never the message content or any team or board names (nor the sender's names or the message id). Every other audit event also has a time, your account, the machine involved, your IP address and your browser's user-agent text	Security, abuse response and so you can review activity on your account	30 days, then purged automatically
Failed-sign-in and attack-signal events (bad machine tokens, refused sign-in links, enrollment lockouts, blocked-access attempts), with the IP address, but no account details when the account is unknown	Security and abuse response	30 days, then purged automatically
Operator actions (disabling an account, revoking a machine by hand)	A tamper-evident operator log kept outside the database so the actions can be re-applied after a restore. Holds account and machine ids, the operator's name and times, never emails or content	360 days; older entries are replaced by a summary of the resulting state, which holds only pseudonymous account and machine ids (never emails). This log is operator data, outside the database backups, and is not covered by the 30-day retention
Operational metrics	Running the service. Counts only; no emails, ids, IP addresses or content in labels	30 days
Web server and application logs (the proxy and the hub)	Abuse response and troubleshooting. Time, request path (no query string), your IP address, TLS server name, result and timing; no headers, cookies or emails	Kept up to 30 days, then deleted automatically (size-capped)
Beta access request details: the email address you enter, the plan you ask about, a team size if you ask for a team, and any note you add (from the request form on coralhub.dev, before you have an account)	To contact you about Coral Hub beta access, and for nothing else	12 months, or until the closed beta ends if that is sooner, then deleted; deleted earlier on request (write to support@subgentic.ai). The IP address is used only to rate-limit requests and is not stored with the request
Encrypted database backups	Recovery	30 days of backups are kept, then deleted. The encrypted backup is also copied off-site to object storage at the hosting provider, and the 30-day retention applies to that copy as well. Backups contain the data above in encrypted form. A restored backup can briefly bring back rows older than 30 days until the next purge run

We do not sell this data. We do not use it for advertising. We do not store payment information in the hub.

Cookies

Three cookies, all strictly necessary, all Secure and HttpOnly. __Host-coral_hub_session keeps you signed in. __Host-coral_hub_pre (about an hour) is used during sign-in to make sure the link or OAuth reply returns to the same browser. __Host-coral_next (10 minutes) is set only when you open a dashboard link while signed out. It remembers which page you were opening, so sign-in can take you back to it; it holds only a path on the hub, is used once, and is then cleared. All three are host-only: the browser sends them to the hub's own address and to no other. No tracking or advertising cookies. The Coral Hub web app at app.coralhub.dev loads no third-party scripts, fonts or images. The pages of this website (not the hub app) are served through Cloudflare, which sets one security cookie, __cf_bm (HttpOnly, Secure, about 30 minutes), for its bot management; it is set by Cloudflare, not by us, and we do not read or use it. If you sign in with Google, you are sent to Auth0's sign-in page at login.coralhub.dev, which sets its own cookies for the sign-in on that domain; the hub does not read them. The hub asks Auth0 to ask you to sign in each time, so a shared browser is not signed in again silently after you sign out of the hub. Sign-in with GitHub or an email link does not use Auth0 or its cookies.

Who else sees your data

Your email provider and the mail service used to send sign-in links see your address and that a link was sent.
Website delivery: the pages of this website (not the hub itself) are delivered through DigitalOcean's App Platform, which serves them through Cloudflare's network. As with any web host, DigitalOcean and Cloudflare see the IP address and browser details sent with each page request.
GitHub, if you choose GitHub sign-in, sees that you signed in to this service.
Auth0 (a service of Okta, Inc.), if you choose Google sign-in. Auth0 handles the sign-in for us as our processor, under the data processing terms Okta publishes on its Trust and Compliance page, and Google sees that you signed in to this service. For each sign-in through Auth0, Auth0 sees and keeps your email address, your name and picture where Google supplies them, that you used Google, your IP address and browser details (user agent), and the time of each sign-in. It keeps a user record for you until it is deleted, and sign-in logs for 1 day (Auth0's retention for our plan; see Auth0's log retention). Auth0's data is held in the United States. See Okta's list of subprocessors (the Auth0 table). The hub receives from Auth0 only your email address, an identifier for your sign-in and which sign-in method you used. GitHub sign-in and email sign-in links do not pass through Auth0.
GitHub (release check): the hub server itself contacts api.github.com once an hour to learn the newest public Coral release, so it can tell you when your machine is behind. It sends no user data, credentials, account or machine information; GitHub sees only the hub's IP address and a coral-hub user agent.
The hosting provider: the hub runs on a single server at a commercial cloud provider, with an encrypted off-site backup copy at the same provider. Traffic and stored data are on their infrastructure. The provider and region are not yet listed here.
A certificate authority: the public certificate request for the hub's domain.
Operators of the hub have access to the database and to live traffic on the machine. That access is limited to the operators of the service; changes made through the Hub's operator commands are recorded in the operator log.

Who can see what, between users

Each account sees only its own machines and agents. The hub enforces this in the application and again in the database. Another user cannot list, open or launch anything on your machines.

Your choices

Your access to a machine never exceeds what that machine allows. A machine tells the hub, each time it connects, the most its own settings allow; until it has connected you have View. The hub’s own setting defaults to the top and can only lower it. Typing into agents (interact) and starting agents (launch) are separate, per-machine choices that also need the setting on the Coral machine itself. Cross-team messaging between boards on a machine is off by default and both boards must opt in. It is turned on from that machine, per board, and cannot be turned on through Coral Hub at any access mode, Interact and Launch included. Once on, it lets agents on different boards of the same machine pass messages to each other.
Auto-accept: Turning auto-accept on for an agent requires Launch mode on that machine and the local switch in Coral's Settings. Turn it off at any time with Interact mode or from the machine itself. Auto-accept ends automatically when the time limit runs out, when the agent restarts or wakes, when access is lowered below Launch, or when the owner lowers the local maximum.
You can switch team messaging off at any time, and each link is one-way and revocable. While it is off nothing is relayed between your machines, and your links are kept. Switching it on or off is done in Coral Hub and needs a signed-in account owner. Messages between your machines need the receiving machine to be set to Interact or higher.
Revoke any machine from the Servers page at any time; its connection is closed.
Sign out everywhere to end all browser sessions.

Closing your account

You can close your account yourself from your Account page (we email you a link to confirm), or, during the closed beta, write to hello@subgentic.ai and we will close it for you promptly, once we receive your request. Either way, the account is closed and disabled, so no one can sign in to it. Erasure of its data will follow when our erasure job ships; until then, closing an account does not erase its data. When our erasure job ships, copies in encrypted backups will age out within the 30 days the table above states.

If you signed in with Google, your user record at Auth0 stays there until we delete it by hand when your account is erased. Closing the account does not delete it.

Questions

Write to hello@subgentic.ai.