This page describes how the platform works, in plain words. If you need more for a review, write to us — a person answers.
Isolation per organization
An organization is a complete, isolated cloud — not a folder. Its servers, networks, containers, databases, buckets, secrets, workspaces, members, policies, billing and audit log are its own, and nothing is shared with another organization. Servers are created for your organization; containers reach each other only on your own Docker networks; a bucket belongs to one organization and a key for it opens that bucket and nothing else.
Every request to the API is checked in the same order: who is asking (a session, a personal token or an API key), that they belong to the organization in the address, that their membership and the organization are in good standing and meet its sign-in rules, and that their role grants the permission the action needs. A member of one organization who asks for another’s resource gets “not found”, not a clue.
Sign-in and sessions
- Passwords of at least 12 characters, stored as argon2id, and checked against known breaches with a k-anonymity lookup that never sends the password.
- Passkeys, as a password-free sign-in or as a second factor.
- Two-factor sign-in with an authenticator app or a passkey, with one-time recovery codes.
- Single sign-on with OIDC or SAML 2.0 on Enterprise, on email domains the organization has proven it owns with a DNS record — people with that domain can join automatically.
- An organization can require two-factor sign-in, or single sign-on, for everyone; owners keep password access as a break-glass.
- Access tokens live 15 minutes, in memory only. Refresh tokens are rotated on every use and kept only as a hash; a stale one presented again is treated as theft and ends the session.
- Sign-in is rate-limited per address and per account, and a failure takes the same time whether or not the account exists.
- Every device’s session is listed and can be signed out; new sign-ins, password and two-factor changes are emailed to you.
Roles, permissions and keys
Every member has a role — Owner, Admin, Developer, Operator, Billing, Viewer, Guest — and each role maps to permissions, the same table that guards the API and draws the Roles page. Sensitive actions have permissions of their own on purpose:
- Opening a terminal on a server is separate from managing servers.
- Deploying to production is separate from deploying to staging.
- Revealing a secret’s value is separate from managing secrets.
- Calling a system’s tools is separate from publishing what it exposes — and from managing the containers behind it.
- Restoring a backup is its own permission, and asks for the container’s name typed back.
Scripts use organization API keys or personal tokens, each limited to the scopes you choose; they are stored as hashes and shown once. Only people — never a key — may change or reveal a secret.
Secrets
One store, scoped to the organization, a stack, a container or a workspace environment. Each value is encrypted with AES-256-GCM bound to its own row and version, so a ciphertext copied onto another secret fails rather than revealing it. Values leave the store in two ways only: into a container’s environment at the moment it is deployed — sent to the server on stdin, never in a command line — and to a person with permission to reveal it, which is rate-limited and recorded.
A secret never appears in an API response, a log line, the audit log, a deploy record or a webhook. Container logs are masked on the way out, for every secret name in your organization. Previews and reviews name secrets; they never show them.
Approvals and the call ledger
Nothing runs on a click. Every create, install, deploy, redeploy and rollback opens a review of exactly what will run — the steps and the Docker commands, who can reach each port, every variable by where its value comes from — and only a person’s approval enables it. The server works the plan out again when the approval arrives and refuses it if anything changed in between.
Every tool of a published system has a class. A read runs; a write, or a tool that reaches outside, asks for a confirmation; anything that cannot be undone asks for its name typed back. Before a call is sent, a row is written to a ledger with who asked, the tool and its arguments with anything that looks like a secret removed; the answer is kept, capped, and marked as someone else’s data. The assistant and agents pass the same gate and write to the same ledger.
Networks and ports
A container’s port is internal — reachable only by name from its own networks — unless you say otherwise. Local binds it to the server’s loopback address. Private binds it to the server’s private address, and because that network is shared with other customers, the platform writes an allowlist into Docker’s own firewall chain that admits only your organization’s servers; it is rebuilt on every change and re-applied at boot. Public means anyone, and the review warns when that would expose a database’s password prompt to the internet.
Addresses you give the platform — a webhook, an MCP server — must be public addresses, and a system’s must be https; they are checked when saved and again on the connection itself, and redirects are not followed.
Servers
- Sign-in with SSH keys only — no passwords, no root password — and a firewall that admits only SSH, HTTP and HTTPS.
- Security updates installed automatically; Fail2ban available at create.
- The platform reaches a server with its own key over SSH, with the server’s host key pinned on first contact; every command it runs is recorded.
- The browser terminal opens with a single-use ticket, only from our own app, and closes after 30 idle minutes or8 hours. Every session — who, when, from where, how long — is recorded.
- We never hold your private SSH keys: you add public keys, and choose which go onto each server.
The audit log
Every change in an organization is recorded: who did it — a person, an API key, the system, or our staff — what, to what, from where, and whether it was allowed. Denied permission checks are recorded automatically. The log can be filtered and exported as CSV. It is kept 30 days on Free, without limit on Enterprise, and seven years with the extended-retention add-on.
Money safety
Every server, volume, snapshot and bucket is tagged with the record that owns it; every call that can cost money is written to a ledger before it is made; and the platform compares its records with what really exists every 10 minutes for servers and every 30 for buckets. Billing follows what is confirmed to exist — never a request — so a server that never came up is never charged and one that vanished stops being billed the moment it is found missing. A bucket that no record owns is reported to a person, never deleted by a timer, because it holds data.
Our own access
Our staff use a separate admin panel with separate accounts: an admin account can never be a customer account, and a customer account can never be an admin. Every admin signs in with a password and an authenticator app, always; admin sessions expire after an hour idle and twelve hours in total, and the panel can be limited to known addresses.
Every action staff take on your organization — a plan change, credits, a support action on a server — is written to your own audit log, labelled as staff. The admin panel has no way to read a secret’s value. For support, an operator can power a server, reconcile it or run a command on it; each of those needs a written reason, is recorded with the command and its output, and appears on the server’s activity where you can see it.
Your data
Your servers run in the location you choose, and your buckets in the location you choose. We don’t store your code: workspaces read it from GitHub when a page asks, with the App’s short-lived tokens, and keep only the link — builds happen on your own server. Container logs are kept for72 hours. When an organization is deleted it can be restored for 7 days; after that its servers, buckets, secrets and everything they held are destroyed, and billing for them ends that second. How we handle personal data is in the privacy policy.
Reporting a vulnerability
If you believe you have found a security problem, write to [email protected]with “Security report” in the subject, what you found and how to reproduce it. Please give us a reasonable time to fix it before telling anyone else, and don’t access or change data that isn’t yours while you test. We will answer, keep you posted, and credit you if you would like.