Security & compliance
How dply protects your code and data.
dply runs many customers’ apps on shared infrastructure, so it treats every build as untrusted and scopes every resource to the organization that owns it. This page describes the platform as it runs today, for teams completing a security review.
Infrastructure and subprocessors
Your apps run on Cloudflare’s network. Builds and your account, organization and billing records run on dply’s build and control-plane servers. These companies process customer data for dply:
| Subprocessor | Purpose | Location |
|---|---|---|
| Cloudflare | Hosting, delivery, storage and compute for your apps (Workers, R2, KV, D1, Queues, Durable Objects, Containers); DNS and certificates for custom domains; account email | Global network |
| DigitalOcean | dply databases (Postgres, MySQL, MongoDB) and Valkey stores | New York, USA |
| Stripe | Payments, subscriptions and invoices. dply never receives or stores your card number. | Stripe |
| GitHub, GitLab, Bitbucket | Source code access and sign-in, only for the providers you connect | The provider |
| Bunny Fonts (BunnyWay d.o.o.) | Web fonts for the dply website and dashboard. The font request carries the visitor’s IP address; Bunny does not log it or set cookies. | EU (Slovenia) |
Data locations and regions
- Built files, routing and edge code — stored in Cloudflare R2 and replicated across Cloudflare’s network; Worker SSR and middleware run at the location nearest each visitor.
- Container apps — run on Cloudflare Containers. You can restrict an app to EU-only or US FedRAMP-only regions, or pick regions yourself.
- dply databases and Valkey — hosted on DigitalOcean in New York. They can’t be moved to another region yet.
- Object storage, Edge SQL, key-value and queues — on Cloudflare. Object storage buckets can be created in the EU jurisdiction; the others take a location hint.
- Your account and organization records — on dply’s control plane. You can’t choose where they are stored yet.
Encryption
- In transit — every site is served over HTTPS. Certificates for custom domains are issued by Cloudflare once the domain is verified. dply databases and Valkey accept TLS connections only.
- On Cloudflare — Cloudflare encrypts R2, KV and D1 data at rest.
- dply databases and Valkey — stored on DigitalOcean block storage volumes, which DigitalOcean encrypts at rest. Database backups are written to Cloudflare R2.
- Secrets in dply — environment variables, organization secrets, Git provider tokens, Cloudflare credentials, notification channel settings and resource connection strings are encrypted in dply’s database with AES-256. Access-control passwords are stored hashed.
- Off-site key escrow — the platform’s own encryption keys and database backups are escrowed daily to off-site storage with age public-key encryption, so a copy can be restored without the running servers. A daily drill proves the newest backup still decrypts.
Tenant isolation
- Organization-scoped resources — databases, queues, key-value stores, object storage and secrets belong to the organization that created them. Bindings declared in your repository resolve only inside your organization, so a binding name can’t reach another customer’s resource or dply’s own storage.
- One hostname, one app — a hostname can belong to only one app across all of dply, checked when you attach a domain and again when you verify it.
- Sandboxed builds — every build runs in its own container as a non-root user, with all Linux capabilities dropped, privilege escalation blocked, memory, CPU and process limits, and a network where one build can’t reach another. Only your checkout and your organization’s own caches are mounted.
- Per-organization build caches — npm, pnpm and Yarn caches are kept per organization, so one organization’s build can’t poison another’s.
- Isolated image builds — container app images are built in an isolated BuildKit builder with the same kind of limits, per-organization cache mounts, and no deploy credentials present.
- Separate runtimes — SSR apps and middleware run as their own Cloudflare Worker scripts in Cloudflare’s isolate sandbox; container apps run in their own containers.
- Outbound requests — when dply calls a URL you provide (webhooks, origin checks, external Redis), it refuses private, loopback, link-local and cloud-metadata addresses and pins the request to the checked address.
Access control
- Roles — Owner, Admin, Member, Deployer and Viewer, plus per-app roles. A Deployer can ship code and read logs but can’t change environment variables, domains, resources, security settings, members or billing. A Viewer changes nothing.
- Sign-in — passwords, passkeys, and GitHub, GitLab or Bitbucket sign-in. Authenticator-app two-factor authentication is available on every account and is required on password and OAuth sign-in once enabled.
- API tokens — limited to the abilities you grant and to their owner’s role, and stop working when the owner leaves the organization.
- Audit log — the organization activity log records who changed what. The full audit log and compliance export are on the Team plan, and entries are kept for 365 days.
Data retention and deletion
- Your data — stays until you delete it. Deleting an app, resource or organization removes it; you can also delete your account from your profile.
- Paused organizations — if an organization is paused because its trial or subscription ended, its apps, resources and data are deleted 30 days after the pause. Owners are emailed 7 days and 1 day before, and deletion never happens without both warnings.
- Database backups — dply Postgres, MySQL and MongoDB stream every change to storage and take a full backup daily. Backups are kept for 7, 14 or 30 days by plan, and you can restore to any point in that window. A weekly check restores each Postgres database from its backups. Deleting a database deletes its backups.
- Request logs — kept for 7 days.
Incident response and status
- If a security incident affects your organization’s data, we email the organization’s owners with what happened and what we are doing about it.
- dply doesn’t publish a status page for the platform itself yet. You can publish your own status pages and uptime monitors for your apps.
- Security fixes that change how the platform behaves are listed in the changelog.
Responsible disclosure
If you find a vulnerability in dply, email security@dply.io. Please include:
- the affected URL, feature or API endpoint;
- steps to reproduce, and a proof of concept if you have one;
- what an attacker could do with it;
- how to reach you, and whether you’d like to be credited.
We won’t pursue legal action against research done in good faith under these rules: test only against accounts and data you own, don’t access, change or delete other customers’ data, don’t degrade the service (no denial-of-service or spam), and give us reasonable time to fix the issue before disclosing it publicly. If you reach someone else’s data by accident, stop and tell us.
To report abuse hosted on dply, or for anything else, email hello@dply.io.
Compliance status
- Certifications — dply has no third-party security certifications or audit reports yet, such as SOC 2 or ISO 27001, and doesn’t offer a HIPAA business associate agreement. Don’t host workloads that require them.
- GDPR — dply processes your apps’ data on your behalf under the Data Processing Addendum, uses the subprocessors listed above, and lets you export or delete your data. dply databases and Valkey are in the US, and object storage location is a placement hint, not a guarantee: dply doesn’t offer EU-only storage yet, so keep data that must stay in the EU with a provider that guarantees it.
- Data processing agreement — the Data Processing Addendum is part of the Terms, with the EU standard contractual clauses. Organization owners are emailed at least 30 days before a new subprocessor is added, and can object. For a countersigned copy, email hello@dply.io.
- Not available yet — single sign-on (SAML or OIDC), SCIM provisioning, and choosing where your account data is stored.