Separate virtual machines
Not a shared container with directories kept apart. Each session gets its own machine, and it is destroyed within the hour whether it was used or not.
Security
Written down, including the limits.
This system runs agent-written code on behalf of strangers, holds credentials that reach their infrastructure, and publishes what it produces to the internet. Those are the three places worth being careful, so here is how each one is handled.
Three boundaries: a disposable machine that holds only your own credential, an encrypted store whose key is not in the database, and published code kept off the domain your session lives on.
Deploy this build.
machine holds only this account's repo tokendestroyed hourly · never the admin key
The boundaries
Three places, and what each one may hold.
The design question is never “is this component trustworthy” but “what does it cost us when this one is not”.
The machine — assume it is hostile
- Agent-written code
- Your project’s files
- A token for your repos only
Runs untrusted code by design. It is given the least that lets it work, and destroyed within the hour.
The accounts service — the valuable one
- Connected credentials, sealed
- Your account and billing
- The encryption key is NOT here
AES-256-GCM at rest with the key held in the environment, so a copy of the database alone opens nothing.
The sites domain — everything published
- Your build
- Every other customer’s build
A different registrable domain, so a published page cannot reach a signed-in session.
Isolation
One machine, one session.
Reachable only by its owner
Each machine has its own credential. A listening port in a sandbox is publicly addressable by default, which is exactly why nothing here relies on it being private.
Never the admin credential
The token inside a machine belongs to one account and reaches only that account's repositories. A machine running untrusted code is one escape away from whatever it holds, so it holds as little as possible.
Credentials
The highest-value table we have.
A connected GitHub or Cloudflare token has to be replayed against the provider, so it cannot be hashed — it must come back out in plaintext. That makes the store of them a thing sitting in front of every connected customer's infrastructure, where the blast radius scales with the customer base rather than with any one relationship. It is treated accordingly: AES-256-GCM, a separate random value per record, and the encryption key held in the environment rather than in the database, so a database dump alone is not enough to use anything in it.
And where a provider offers OAuth, that is what we take — a scoped token you can revoke from their dashboard, a control that does not depend on us being trustworthy or still running. More in integrations.
Plainly
What we can and cannot see.
Per thing, per way of running it. “Sealed” means AES-256-GCM with the key outside the database; it also means our server can open it when a machine needs it — that is what makes it usable, and pretending otherwise would be the lie this page exists to avoid.
| What | On a machine we run | On your own machine |
|---|---|---|
| Your code and files | On the build machine for its hour, and in your repository on our git host in Germany. We can technically read it; it is private to your account. | Never reaches us. |
| Your prompts and chat | Pass through our relay to the model you chose; transcripts are archived to your account so conversations survive the machine. | Go only to the model provider you point it at — and with a local model, nowhere at all. |
| Connected account tokens | Sealed at rest, opened server-side only when a machine of yours needs them. Revocable from the provider's own dashboard any time. | Stay in your own configuration. We never hold them. |
| Project secrets | Sealed the same way. Once saved, no screen and no API returns the value — it goes forward into machines and your deployed app, never back out. | Not applicable — use your own environment. |
| Your card | Never touches us. Stripe holds it; we see the outcome of a charge, not the number. | Same. |
What gets published
Other people's code, kept off our origin.
Published sites are served from a separate registrable domain, never a subdomain of this one, because agent-written JavaScript on a shared domain would run beside the origin holding your signed-in session. The service that decides whether you may publish is also not the one with write access to the directory being served.
The limits
What we do not claim.
We are a small company, not a compliance department. There is no SOC 2 report, no HIPAA posture and no BAA. Code you build here is stored on our infrastructure unless you run the agent yourself. If your work carries regulated data, the honest recommendation is the self-hosted path, where none of it reaches us at all — and saying so costs us a sale we would rather not make badly.
If you find something wrong, tell us. It reaches a person.
Read the limits, then try it anyway.
Sign in and run a real build — the machine that runs it holds only what that build needs, and nothing else.
Questions
Asked, answered
Is my code private?
Your repositories are yours and are not public. If your work carries regulated data the honest recommendation is to run the agent on your own hardware, where none of it reaches us.
Are you SOC 2 or HIPAA compliant?
No. There is no SOC 2 report, no HIPAA posture and no BAA, and we would rather say so than sell you something on a claim we cannot support.
How are the machines isolated?
One virtual machine per session, destroyed within the hour, holding a credential that reaches only your own repositories and never an admin one.