Security you can check.
Every statement on this page says where it stands: in place today, planned, or not offered. Where a provider does the work, the statement is the provider's, made under its name and linked to its own page.
Last reviewed Oct 5, 2026.
Not certified yet, and saying so.
A certification is an audit of a company's own systems. Our providers' certifications cover theirs, not ours, so they are listed under each provider's name further down.
Not audited yet. An audit starts when a customer needs one. A provider's report covers that provider's own systems, not ours.
Not certified. Planned after a first audit, reusing its evidence.
Card payments to us run on Stripe's hosted pages, so card numbers never reach our servers; we have not yet completed the merchant self-assessment that confirms it. We are not a payment service provider: take card numbers in your apps only through your payment processor's hosted fields.
Not supported. We do not sign business associate agreements, and our terms do not allow health information on the platform.
You can export an organization's data and delete your account, and we list the providers that process data for us. Our privacy policy and data processing agreement are drafts awaiting legal review.
Not certified. Our draft data processing agreement relies on the EU standard contractual clauses for transfers instead.
Not planned.
The controls, area by area.
Between the internet and your app.
- In place
Every public app address is served over HTTPS, and plain HTTP is redirected to it.
- In place
Fly.io, which runs every app on the platform, works with upstream traffic providers to mitigate DDoS attacks at the network level. Source: Fly.io
- In place
A service can be private: it gets no public address at all, and is reachable only over the platform's private network.
- In place
Our own site sends a Content Security Policy and HSTS, and every deploy of it checks that both are present.
- Planned
Cloudflare's automatic DDoS mitigation, in front of apps behind our edge. Source: Cloudflare
- Planned
Cloudflare's managed rulesets, including its OWASP Core Rule Set, for every app behind our edge on every plan. Source: Cloudflare
- Planned
A firewall for each environment behind our edge: custom rules, IP blocking, rate limits and a challenge mode, with every change kept so it can be restored.
- Planned
Access protection for apps behind our edge: only signed-in members of your organization, a password, or trusted IP addresses.
Isolated, encrypted, and pinned to what was built.
- In place
Each organization's data is kept apart in the application, and every table in the database carries row-level security policies that are checked on every deploy of the platform.
- In place
Each environment is created on a private network of its own, shared only by that environment's services and databases.
- In place
Managed databases never get a public address, and each one has its own long random password.
- In place
Environment variables and database passwords are encrypted at rest with AES-256-GCM, each bound to the record it belongs to, and the product never shows them back.
- In place
You can keep a secret in your own vault — Azure Key Vault, AWS Secrets Manager, Google Secret Manager or HashiCorp Vault — and we store only a reference to it, read when your app deploys.
- In place
Fly.io encrypts the volumes your databases live on with Linux LUKS block-storage encryption. Source: Fly.io
- In place
Supabase, which hosts our own database, encrypts it at rest with AES-256 and in transit with TLS. Source: Supabase
- In place
Managed databases keep daily restore points for as many days as your plan includes, up to 60, and roll back in place — and a rollback can itself be undone.
- In place
A release runs the exact image its build produced: new builds are pinned by content digest, and an image whose tag moved is refused.
- In place
Builds run without the platform's credentials, and fetch your source with a read-only token for that one repository, revoked as soon as the download finishes.
- In place
Build caches are never shared between builds: each Dockerfile build gets its own BuildKit instance, and other builds use cache keys unique to the build.
- Planned
A restore drill for our own database every quarter.
- Planned
A dedicated virtual machine for every build.
Strong sign-in, and only the permissions granted.
- In place
Two-factor authentication is required for organization owners and admins, and for our own staff accounts.
- In place
Signing in with GitHub or Google asks for the second factor too.
- In place
Passkeys and authenticator apps work on every account.
- In place
Custom roles grant members exactly the permissions they need; a member without a role holds none.
- In place
API keys are scoped to what they may do, can expire, and are rate-limited.
- In place
Security-relevant actions in your organization are recorded in its audit log and kept for 12 months.
- In place
A record in your organization's audit log each time our staff sign in as one of your users.
- In place
An organization-wide requirement for every member to use two-factor authentication.
- In place
Exporting the audit log, and streaming it to an endpoint of yours.
- Planned
Single sign-on with SAML or OIDC, and directory sync with SCIM, on Enterprise.
Your data stays yours to take and to delete.
- In place
An organization owner can export the organization's data as JSON at any time.
- In place
You can delete your account yourself; organizations where you are the only member are deleted with it.
- In place
A public list of the providers that process data for us, with what each one holds.
- In place
A draft data processing agreement, published for you to read.
- Planned
A data processing agreement reviewed by counsel, ready to sign.
- Planned
Terms of service and a privacy policy reviewed by counsel; today's are templates.
Checked before every deploy, and answerable when it fails.
- In place
Automated checks of access control, encryption and isolation run before every deploy of the platform.
- In place
Adversarial probes test tenant isolation, cryptography, server-side request forgery, authorization and resilience against our own code.
- In place
Our repository is scanned for known-vulnerable dependencies and leaked secrets on every push and pull request, and weekly.
- In place
A vulnerability disclosure policy, with a safe harbour for good-faith research, and a security.txt.
- In place
Anyone can report abuse of an app we host, through a form or by email.
- In place
A written procedure for responding to a security incident and telling the customers it affects.
- Planned
A penetration test by an independent firm.
- Planned
A paid bug bounty.
- Planned
Taking an abusive app offline within minutes, with a notice and an appeal for its owner.
- Planned
Verifying an organization before its apps share our apps domain or use a domain of their own.
- Planned
A copyright agent registered with the US Copyright Office.
Our providers, and what each one holds.
Each provider's attestations are its own and cover its own systems. What data each one receives is on the subprocessor list.
Runs every app you deploy, its databases and the private network they share.
Fly.io holdsSOC 2 Type 2
Registers the domain names you buy through us, and serves DNS for them and for our own domains.
Cloudflare holdsSOC 2 Type II · ISO 27001 · ISO 27701 · ISO 27018 · PCI DSS Level 1, as a service provider
Stores the images you upload and the archive of our background-job history.
Tigris Data holdsSOC 2 Type II
Takes payments for plans, usage and domain names.
Stripe holdsPCI DSS Level 1, as a service provider · SOC 1 and SOC 2 Type II reports · EU–US Data Privacy Framework
Hosts the mailboxes that receive email sent to our support and abuse addresses, which Cloudflare's email routing forwards there.
Answers the in-app assistant and writes AI fixes.
Anthropic holdsSOC 2 Type I and Type II · ISO 27001:2022 · ISO/IEC 42001:2023
Holds the repositories you connect: we read them to build your apps, and open fix pull requests you ask for.
GitHub holdsSOC 1 Type 2 and SOC 2 Type 2 · ISO/IEC 27001:2022
What buyers ask, answered as things stand.
Do you protect apps against DDoS attacks?
Partly.
- In placeFly.io, which runs every app on the platform, works with upstream traffic providers to mitigate DDoS attacks at the network level.
- PlannedCloudflare's automatic DDoS mitigation, in front of apps behind our edge.
Are you SOC 2 Type 2 certified?
Not yet. Not audited yet. An audit starts when a customer needs one. A provider's report covers that provider's own systems, not ours.
Do you comply with the GDPR?
Partly. You can export an organization's data and delete your account, and we list the providers that process data for us. Our privacy policy and data processing agreement are drafts awaiting legal review.
Are you ISO 27001 certified?
Not yet. Not certified. Planned after a first audit, reusing its evidence.
Do you hold a TISAX label?
No. Not planned.
Are you certified under the EU–US Data Privacy Framework?
No. Not certified. Our draft data processing agreement relies on the EU standard contractual clauses for transfers instead.
Can I host health information covered by HIPAA?
No. Not supported. We do not sign business associate agreements, and our terms do not allow health information on the platform.
Are you PCI DSS compliant?
Not yet. Card payments to us run on Stripe's hosted pages, so card numbers never reach our servers; we have not yet completed the merchant self-assessment that confirms it. We are not a payment service provider: take card numbers in your apps only through your payment processor's hosted fields.
Can I require a sign-in or a password before anyone reaches my app?
Not yet.
- PlannedAccess protection for apps behind our edge: only signed-in members of your organization, a password, or trusted IP addresses.
Is my data encrypted?
Yes.
- In placeEnvironment variables and database passwords are encrypted at rest with AES-256-GCM, each bound to the record it belongs to, and the product never shows them back.
- In placeEvery public app address is served over HTTPS, and plain HTTP is redirected to it.
- In placeFly.io encrypts the volumes your databases live on with Linux LUKS block-storage encryption.
- In placeSupabase, which hosts our own database, encrypts it at rest with AES-256 and in transit with TLS.
Do you take backups?
Partly.
- In placeManaged databases keep daily restore points for as many days as your plan includes, up to 60, and roll back in place — and a rollback can itself be undone.
- PlannedA restore drill for our own database every quarter.
What infrastructure do you run on?
- Fly.io — Runs every app you deploy, its databases and the private network they share.
- Supabase — Hosts our own database.
- Cloudflare — Registers the domain names you buy through us, and serves DNS for them and for our own domains.
- Tigris Data — Stores the images you upload and the archive of our background-job history.
- Stripe — Takes payments for plans, usage and domain names.
- Resend — Sends our transactional email.
- Google — Hosts the mailboxes that receive email sent to our support and abuse addresses, which Cloudflare's email routing forwards there.
- Anthropic — Answers the in-app assistant and writes AI fixes.
- GitHub — Holds the repositories you connect: we read them to build your apps, and open fix pull requests you ask for.
- Sentry — Collects error reports from our own servers.
What each one receives is on the subprocessor list.
Are customers kept apart from each other?
Partly.
- In placeEach organization's data is kept apart in the application, and every table in the database carries row-level security policies that are checked on every deploy of the platform.
- In placeEach environment is created on a private network of its own, shared only by that environment's services and databases.
- In placeBuild caches are never shared between builds: each Dockerfile build gets its own BuildKit instance, and other builds use cache keys unique to the build.
- PlannedA dedicated virtual machine for every build.
Do you run penetration tests and security scans?
Partly.
- In placeAdversarial probes test tenant isolation, cryptography, server-side request forgery, authorization and resilience against our own code.
- In placeOur repository is scanned for known-vulnerable dependencies and leaked secrets on every push and pull request, and weekly.
- PlannedA penetration test by an independent firm.
Do you publish a list of subprocessors?
Yes.
- In placeA public list of the providers that process data for us, with what each one holds.
Do you run a bug bounty?
Not yet.
- PlannedA paid bug bounty.
- In placeA vulnerability disclosure policy, with a safe harbour for good-faith research, and a security.txt.
Do you protect against the OWASP Top 10?
Not yet.
- PlannedCloudflare's managed rulesets, including its OWASP Core Rule Set, for every app behind our edge on every plan.
Can I sign a data processing agreement?
Not yet.
- PlannedA data processing agreement reviewed by counsel, ready to sign.
- In placeA draft data processing agreement, published for you to read.
- SubprocessorsWho processes data for us, and what each one holds.
- Data processing agreementA draft, awaiting legal review.
- Vulnerability disclosureHow to report a hole, and our safe harbour.
- Report abusePhishing, malware, copyright and other abuse of an app we host.
- Terms of serviceIncluding what may not be hosted here.
- Privacy policyWhat we collect, why, and for how long.
- security.txtOur security contact, machine-readable.
- A vulnerability in the platform
- security@deployyourcode.com
- Abuse of an app we host
- abuse@deployyourcode.com
- Your personal data
- privacy@deployyourcode.com