Privacy

what we hold (and why)

• Your account: an email address and a username. That's the identity record. Cubby has no passwords — you sign in with a single-use magic link that expires in ten minutes — so there is no password database to breach, because there is no password database. When you ask for a sign-in link, the email tells you roughly where and on what browser the request came from, worked out at that moment from the request's network location and browser. It goes into that email and nowhere else: we don't store or log it. If you choose Continue with Google, Google tells us your email address; we keep nothing else from Google.
• Your workspaces and apps. Workspace names, who's a member, app names and hostnames, and the app code your AI deploys. This is the working material of the product; we hold it because serving your app requires it.
• Your apps' databases. Every app gets its own Neon Postgres project — its own credentials, its own storage, nobody else's rows. What your app stores there is yours. We operate the infrastructure underneath it; we don't mine it, resell it, or train anybody's models on it.
• Vaulted connection secrets. When you connect an app to a real system — a database, an API with a bearer token — the credential goes into the vault, encrypted at rest with AES-256-GCM, keys derived with PBKDF2, every ciphertext versioned. And it gets there through your browser, over TLS, via a setup link: secret values never transit a chat transcript. Not at creation, not in tool results, not in logs. The model building your app never sees them.
• Walkthrough requests. An email address and — if you chose one — which door you picked (work, or your people), checked by Cloudflare Turnstile, stored in a Resend audience. That's the entire record.
• Billing. Stripe handles payment for paid plans: the checkout page and the billing portal are Stripe's, your card details live at Stripe, and we never see full card numbers. We keep the customer and subscription ids and the plan, nothing more.

what we deliberately don't collect

The product telemetry that tells us whether deploys succeed carries zero personal data by construction: opaque ids, booleans, a closed vocabulary of failure classes, and millisecond timings. No emails, no file paths, no file contents, no tool payloads, no prompts. The recorder drops anything outside that vocabulary — it cannot hold what you'd redact.

Your chat with Claude stays with Claude: through the connector, Cubby receives only what each tool call carries — the tool's name and the arguments Claude fills in, such as an app description, the files to deploy or an email address to share an app with — and never the conversation itself.

For the Cubby product and your app data, the list of things we don't run is repeated here from the security page because it belongs on both: no analytics broker, no session-replay service, no ad tech, no data resale, no training anybody's models on your apps or your data.

where your data lives

Cubby is the data processor for what you put in it. These are the subprocessors under the hood — the complete list, and it stays complete:

If this table ever gains a row, the change lands here before it lands in production. One site-level honesty note that isn't a subprocessor: this website loads its fonts from Google Fonts, so your browser makes a request to Google's font servers when the page loads — that request carries what any web request carries (your IP address and browser signature), and no Cubby data.

optional website analytics

On the public cubbyapps.com website, optional Metricool analytics measures page visits, traffic sources and country. It loads only after you allow analytics and stays off when your browser sends Global Privacy Control. Metricool says its website tracker uses no cookies; requests carry technical information such as your IP address and browser information, and the IP address is used to determine country. This integration does not run on the Cubby dashboard or customer apps and does not send form contents. Use “privacy & analytics” to change your choice. Declining after allowing reloads the page to stop this tracker; it does not delete earlier measurements.

Read Metricool's privacy policy.

how long we keep it

• Deleting an app starts a 14-day hold. The URL stops serving immediately; nothing is destroyed for two weeks; you can restore the app — database and all — from the dashboard's Deleted apps any time inside the hold. Export your database first if you want a copy. When the hold expires, the app's Neon project, its source code, its build files, its deployed Worker with the connection secrets bound into it, and its vault entries are permanently destroyed, and its custom domains are released.
• Removing a connection destroys its vaulted secret — immediately, no hold.
• What destroyed means here. On every clock on this page, destroying an app destroys everything the first bullet lists — on the 60-day clocks, for every app in the workspace. Build files that are byte-for-byte identical to another app's build stay while that app is live or still restorable, because they are its build too. What stays is the record that an app existed — its name, its address, who it was shared with and its deploy history. Only the account-deletion clock erases an account — its email address, its username and its workspace's name — and only one that belongs to no other workspace; the other clocks never touch your account.
• Non-payment never touches your data. If a payment fails, new deploys pause and your apps stay up — nothing is deleted, nothing is suspended. A payment problem should be a conversation, not an outage. If it is never resolved and the subscription finally lapses, a 60-day clock starts on the workspace's data — and any activity after that clears it: signing in or deploying an app is enough. Sixty days after a subscription ends we destroy the data only if nobody came back.
• Canceling a paid plan drops the workspace to the free tier. Your apps and data stay where they are — cancellation is a quota change, not a deletion. Canceling starts the same 60-day clock as a lapse, and the same thing clears it: keep using the workspace, free tier and all, and nothing is ever destroyed. The window is for abandoned workspaces — cancel, then go silent for 60 days, and the workspace's data is destroyed.
• Deleting your account: 60 days, then its data is destroyed. Ask us to delete your account and the clock starts; the underlying data is retained for 60 days in case you tell us it was a mistake, then permanently destroyed. This one is a request rather than abandonment, so activity does not clear this clock — you asked us to delete it.
• Magic links are short-lived by design: a sign-in link is single-use and dies after ten minutes, used or not.

your controls

• Export your database any time with the db tool's export action, up to 16 MiB of SQL — larger databases export through a one-hour read-only connection string with pg_dump. Either way it is a standard, replayable SQL export of your app's own Postgres database, because it is a real Postgres database, not an abstraction over one.
• Delete an app yourself. delete_app is deliberately annotated destructive and requires typed confirmation — then the 14-day hold above, then destruction.
• Delete your account: email us and we delete your workspace's apps and destroy their databases, their source code, their build files, their deployed Workers and your vault entries. At our current size that is a human doing it promptly and confirming to you when it's done — we'd rather promise the manual process we actually perform than a self-serve button that doesn't exist yet. Sixty days after you ask, we also erase your account: its email address, its username, your workspace's name and the records of the sign-in links we emailed you — and we sign you out everywhere. If you still belong to another workspace, your account stays for that one. The record of which apps existed, invitations to your address you never accepted, and the billing records (ours and Stripe's) stay on file.
• Take your app and leave. Every Cubby app is an ordinary React/Vite TypeScript project; the exit is real and rehearsed — the security page has the details.

Whatever privacy rights your jurisdiction gives you — access, correction, deletion, portability — the mechanism is the same: email, and a human answers. The same human who built the system, which at our size is the strongest guarantee we can offer that your request won't fall into a ticket queue.

cookies

• Session cookies are host-only. No Domain= attribute — the dashboard's cookie is invisible to every app, and one app's cookie is invisible to every other app and to us.
• No tracking cookies. This site sets none. Your theme choice (light/dark) is stored in your own browser's localStorage and never sent anywhere.
• Turnstile runs on the walkthrough request form to keep bots out; that's Cloudflare's check, on our page, for that one purpose.

apps you build, and the people who use them

Two roles, two answers:

If you build an app and share it, the people you share with sign in with their own Cubby identity — magic-link email, same as you — and your app checks access itself. Cubby processes their email address as the identity anchor of the grant. What they type into your app lands in your app's database, which belongs to your workspace: you are responsible for what your app collects.

If you use someone else's Cubby-built app, the data you put in it is between you and the app's owner — they own the app and its database. Cubby is the infrastructure underneath: we hold it, encrypted at rest, under everything this page promises, but the owner decides what their app does with it. Provenance rule, same as everywhere: anything on cubbyapps.com is us; anything on cubby.pro is user-built.

who we are, honestly

Cubby is built and run by one person, after years of running production systems and putting AI to work inside real businesses — the security page tells that story in full, because the architecture you're trusting came out of it. The privacy-relevant version:

• No SOC 2, no compliance attestation, no privacy-framework certification. We won't imply one with a badge. What we have is a surface small enough to describe completely and a policy short enough to actually read.
• Don't put regulated data here. If your threat model involves PHI, PCI-scope cardholder data, or anything procurement needs an attestation for — we are not there yet, and we'll tell you the same thing in a sales conversation.
• Cubby is a developer tool for building and running apps. It is not directed at children, and we don't knowingly hold children's data.

contact and changes

Privacy questions, data requests, deletions: security@cubbyapps.com — one mailbox, one person reading it, for security and privacy both. Saying that plainly beats inventing a privacy@ alias nobody staffs.

This page changes when the system changes, and each substantive revision is dated. No silent edits.