Isolation you don't have to think about.
Deplane runs code from many teams on shared hardware, and more of that code is written by AI and read by no one. So we built the platform around one rule: every app, every build and every database gets its own virtual machine with its own kernel. Everything else on this page follows from that.
A shared kernel is a shared risk.
Most app platforms run customers in containers. Containers are a good way to package software, but every container on a server talks to the same Linux kernel. The walls between customers are rules inside that one kernel, and a single kernel bug can take them down. Kernel bugs like that are found several times a year.
- On Deplane, each workload boots its own small kernel inside a hardware-virtualized microVM (Kata Containers 4.2 with Cloud Hypervisor).
- To reach another customer, code would have to escape a virtual machine, not just a container. That is a much harder and much rarer kind of bug.
- Builds are isolated too. A build runs your
npm installand your Dockerfile, which is untrusted code. It gets its own microVM, separate from running apps. - You configure none of it. Isolation, TLS, firewalls and network rules are on for every app from the first deploy.
Customer code and the platform never share a server.
The servers that run your apps hold nothing worth stealing. The servers that hold the platform never run your code.
Separate server roles
Apps, builds and databases run only on customer servers, which hold no platform credentials. The API, the platform database and the image registry run on separate servers that never run customer code.
Network rules outside the sandbox
An app cannot reach the platform's internal network, cloud metadata addresses, private address ranges, Deplane's own servers, or another team's apps. The rules live in each server's firewall, where code inside a VM cannot change them.
A small surface on the internet
Only the edge server accepts traffic from the internet, and only on ports 80 and 443. Every app gets HTTPS. Traffic between our servers is encrypted.
Abuse stopped at the edge of the VM
Outbound email on port 25 is blocked, ports 465 and 587 are rate limited, and known cryptocurrency mining pools are blocked. Abuse is spotted from network flows, DNS lookups and CPU use.
Escape attempts are watched
Runtime detection (Falco) watches the host side of every sandbox for unexpected processes, file access, listening sockets or network connections started by the sandbox runtime.
Tested against the real thing
185 isolation checks run against the live servers: cross-team traffic, metadata access, privileged pods, volumes, admission rules and an external port scan. They run again after every kernel, sandbox or orchestration upgrade.
No passwords. Nothing to phish.
Most breaches start with a stolen login. Deplane has no passwords to steal, and every way in asks for a second factor.
Passkeys first
Sign in with Touch ID, Face ID, Windows Hello or a security key. Devices without passkeys use an authenticator app. A second factor is mandatory on every login.
A tap for what can't be undone
Deleting an app or a database, and restoring or switching one, each need their own passkey tap, so a stolen CLI login can't do them. Deplane operators sign in with passkeys only and tap for every admin change.
Sign-in links scanners can't burn
A sign-in link opens a page with one Continue button. Security scanners that open links can't use it up. Links work once and expire after 15 minutes.
GitHub matched by ID, not email
GitHub accounts are matched only by GitHub's permanent user ID, linked only by someone already signed in with a second factor, and the access token is thrown away after sign-in.
A CLI login that resists phishing
deplane login shows a code you type on the sign-in site. Before you approve with your passkey, the page shows the requesting IP address, approximate location, CLI version and time.
Revoke a login in one click
A CLI login can be revoked at once. New-login emails with a revoke link are built but not sent until email is set up. Logins, links and second-factor attempts are rate limited, with a lockout after too many wrong codes.
Secrets stay secret. Changes leave a trail.
- Envelope encryption for every secret. Each value has its own data key, and that key is encrypted with a key kept outside the database.
- Write-only by design. Values are never returned by the API, never shown by the CLI, and never written to logs or the audit log. Build secrets are never written into images.
- Tokens you can reason about. Every token starts with
dpl_, carries 32 random bytes, belongs to one team, and expires. We store only a hash. Revoking takes effect at once. - An audit log that can't be edited. Every change is recorded in the same database transaction as the change itself. The database account the API uses cannot change or delete audit entries.
- Admin actions are recorded and need a fresh tap. Every admin action is written to the audit log and needs a passkey confirmation from the last five minutes. Admins sign in with passkeys only.
- Backups that are actually restored. The platform database is backed up every night and encrypted before the backup is written, with a key kept off the servers.
- Your databases, backed up continuously. Every change is streamed as it happens and encrypted with that database's own key. A separate backup server pulls a copy every 15 minutes; the platform's servers hold no key to it, so they cannot change or delete it.
Secret names appear in the log. Values never do.
Deadlines we hold ourselves to.
From the day a fix is available. Servers reboot one at a time, and their apps move to other servers first, so patching causes no downtime.
| Component | Critical | High |
|---|---|---|
| Linux kernel on customer servers | 72 hours, with reboot | 7 days |
| Sandbox runtime, build engine, image storage | 72 hours | 7 days |
| Private network, orchestration and routing software | 72 hours | 14 days |
Least privilege, even with your code.
What the Deplane GitHub App can do
Read the code of the repositories you choose. Set commit statuses. Write one comment on a pull request, and keep updating it. That's all.
What it can't
Push code, change settings, or read other repositories. Access tokens are created per job, limited to the one repository, and never stored. .env files are never used.
What we're still working on.
Deplane is in an invite-only beta. Here is what is not done yet, so you can decide with the full picture.
Independent penetration test
An outside firm tests the platform before sign-up opens to everyone. We will publish the summary.
Backups in a second data center
Every backup is already copied to a separate backup server. We plan a further copy in another data center.
SOC 2 and ISO 27001
The controls on this page are the base. Formal audits are on the 2027 plan.
Single sign-on
SAML and OIDC sign-in, and SCIM user provisioning, for Enterprise teams.
Found a problem? Tell us.
Email security@deplane.cloud. Our contact details are also in security.txt. We answer every report and credit researchers who want to be credited.
Seen an abusive app?
Phishing, malware or spam on a Deplane address: report it here. We acknowledge every report within 24 hours.
Secure by default. Every app, every time.
No settings to remember, no add-on to buy. It's how Deplane works.