Security

How Deplane isolates your apps, protects your account, tokens, and secrets, and how to report a vulnerability.

Deplane is in an invite-only beta. This page describes what is in place today, and says plainly where today's setup differs from what we require before open signup.

Isolation

• Each app runs in its own microVM. Builds and databases run in their own microVMs too, separate from running apps.
• Customer apps and builds run only on customer servers. These servers hold no platform credentials. The API, the database, and the image storage run on separate servers that never run customer code.
• An app cannot reach the platform's internal network, cloud metadata addresses, private address ranges, or Deplane's own servers. These rules are enforced in each server's firewall, outside the sandbox, so code inside an app cannot change them.
• An app cannot reach another organization's apps.
• Outbound email on port 25 is blocked. Ports 465 and 587 are rate limited. Outbound TCP to the ports cryptocurrency mining pools commonly use (3333, 4444, 5555, 7777, 9999, 14444 and 45700) is blocked.
• Traffic between our servers is encrypted.
• The edge server, the only one that faces the internet, holds no Kubernetes credentials and cannot read any app's secrets. It sees only what it needs to route requests.
• Only the edge server accepts connections from the internet, and only on ports 80 and 443. Every other server, including the ones that run apps, accepts no inbound connections from the internet.
• You never configure isolation, TLS, network rules, or firewalls. HTTPS is on for every app.

The sandbox. Apps, builds and databases run in Kata Containers microVMs (Cloud Hypervisor): each sandbox is a small virtual machine with its own Linux kernel, so code inside it never shares a kernel with another team's code. An isolation test suite of 185 checks runs against the live servers. We run it by hand at each platform change; the last full run, on 2026-10-16, had no failures (185 passed, 1 skipped).

Builds

A build turns your code into an image. It runs in its own microVM on a customer server, in a namespace that belongs to your team alone, and it is handed exactly four things:

What a build never gets:

• Runtime secrets. The controller asks for the build scope only. A value set with deplane secrets set without --build is not in the build.
• Anything about you or your team. The build pod carries only the app's and the team's IDs, as labels for usage metering: no names, no email addresses, no members, nothing about other teams.
• Platform credentials. No Kubernetes service account token, no links to other services, no database or key-encryption key. The API, the database and the keys are on servers a build cannot reach.
• The private network. A build reaches the internet (for packages and base images) and the image storage. It cannot reach private address ranges, cloud metadata addresses, Deplane's own servers, or another team's builds and apps.
• Files that never leave your machine. deplane deploy never uploads .git or any .env* file.

When the build ends, its credential and build secrets are deleted; a sweep removes any that outlived their build. The build log is yours: a build step that prints a secret value writes it into your build log, which your team can read, so do not print them.

What reaches a build pod is pinned by a test (TestBuildPodSeesOnlyItsOwnInputs in internal/controller): a change that hands a build one more variable, volume, label or Secret key fails the test until this page says why.

Login

• Passkeys first. Sign in with Touch ID, Face ID, Windows Hello, or a security key. If your device has no passkey support, use an authenticator app.
• A second factor is mandatory. Every login needs it, whether you start from a passkey, a sign-in link, or GitHub.
• Admins use passkeys only, and confirm every admin action with a fresh tap.
• Scanner-proof sign-in links. A sign-in link opens a page with one "Continue" button. The link is used only when you press it, so security scanners that open links cannot use it up. Links work once and expire after 15 minutes.
• GitHub login matches accounts only by GitHub's permanent user ID, never by email. GitHub can be linked only by a user who is already signed in with their second factor. The GitHub access token is thrown away after sign-in.
• CLI login resists phishing. deplane login shows a code that you type on the login site; the site never takes it from a link. Before you approve, the page shows the requesting IP address, approximate location, CLI version, and time. Approval needs your passkey. Codes expire after 10 minutes.
• Revoking logins. You can revoke a CLI login at once. New-login emails with a "this wasn't me" link are built but not sent yet, because email sending is not set up.
• Rate limits on login, sign-in links, and second-factor attempts, and a lockout after too many wrong codes.
• Browser sessions use secure, HTTP-only cookies, last 12 hours, and are protected against cross-site request forgery.

Tokens

• Tokens start with dpl_ and contain 32 random bytes. We store only a hash of each token, never the token itself. A token is shown once, when it is created.
• Each token belongs to one organization and can act only there.
• CLI logins last 30 days. CI tokens last 90 days by default and at most one year.
• Creating a CI token needs a fresh passkey tap. CI tokens cannot create tokens or run admin commands.
• Destroying an app, and deleting, restoring or switching a database, need a passkey tap from the last 5 minutes, in the dashboard or (for the CLI) in the browser for that same login. Each tap covers one such action. A stolen CLI login alone cannot do them; CI tokens and AI tools cannot do them at all.
• Inviting and removing team members need a fresh passkey tap too.
• Revoking a token takes effect at once. Revoking a login also revokes the tokens created with it.
• The CLI hides tokens in its output and in --debug logs.

Secrets

• Secret values are encrypted with envelope encryption: each value has its own data key, and that key is encrypted with a key-encryption key that is kept outside the database.
• Values are never returned by the API, never shown by the CLI, and never written to logs or to the audit log.
• Build secrets are available only during the build and are never written into images.

See Secrets.

Audit log

Every change is recorded in an audit log in the same transaction as the change itself: logins, tokens created and revoked, apps created, scaled, configured, and destroyed, secrets set and removed (names only), releases, and admin actions. The database account the API uses cannot change or delete audit entries.

Operator access

• Secret values are never returned by the API, shown in the dashboard or CLI, or written to logs.
• Deplane admins sign in with passkeys only, and every admin action needs a fresh passkey tap from the last five minutes.
• Every admin action is written to the audit log.
• We do not yet have a formal two-person access procedure or alerts on operator reads of secrets. Do not rely on those.

Backups

• The platform database, which holds your app settings and your encrypted secrets, is backed up every night and encrypted before the backup is written. The key that decrypts it is kept offline.
• Platform state snapshots are taken hourly and encrypted before they leave the server.
• Managed databases are backed up continuously (their change log, streamed as it happens, and a nightly full copy) by a service on the control server. Each database's backups are encrypted to its own key, which is stored encrypted with the platform's key-encryption key; nothing inside a database's microVM can read, change or delete them. Only the backup service may connect to a database's replication port, from its one address. A restore runs into a new database with a one-time key that works for 6 hours, for that restore only. When a deleted database's backup window ends, its backups and its key are deleted.
• Every 15 minutes, a separate backup server pulls a copy of all of these backups, still encrypted. It is not part of the cluster and runs no customer code. It only reads from the control server, and the control server holds no credential for it, so someone who took over the control server could not change or delete the copies.

Runtime detection

The customer servers watch the host side of every sandbox for signs of an escape attempt: unexpected processes, file access, listening sockets, or network connections started by the sandbox runtime. There is no automatic detection of abuse inside a sandbox yet: abuse is handled from reports (see Abuse).

Patch deadlines

We apply security patches within these times after a fix is available:

Servers reboot one at a time, and their apps move to other servers first. Kernel updates install automatically; the isolation test suite is run by hand at each platform change, not automatically after every upgrade.

Supply chain

• Dependencies are pinned with checksums, and base and build images are pinned by digest.
• Automatic vulnerability scanning of dependencies and images is not set up yet.
• Signed releases are coming with the first CLI release.

Report a vulnerability

Email security@deplane.io. Our security contact details are at https://app.deplane.io/.well-known/security.txt.

• Tell us what you found and how to reproduce it.
• Test only against your own apps and account. Do not access other people's data, degrade the service, or run denial-of-service tests.
• Give us reasonable time to fix the problem before you publish it.

We acknowledge reports within 24 hours. See the Acceptable use policy for the rules on security research.

To report an app that hosts phishing, malware, or other abuse, see Reporting abuse.

This page is also available as Markdown. AI agents can start at /llms.txt.