dply is a managed hosting platform for websites and web applications. You connect a Git repository, dply detects how to build it, and each push deploys to Cloudflare's global edge network. Static sites, server-rendered JavaScript apps and full PHP, Ruby or Node servers all deploy the same way, from the same dashboard.
You don't need a Cloudflare account, servers or Docker knowledge. dply runs the builds, stores the output, routes traffic, issues TLS certificates and meters usage.
Runtime modes
Every app runs in one of four modes. dply picks one from what it detects in your repository and shows it on the create page next to the framework name.
| Mode | Shown as | What runs | Use it for |
|---|---|---|---|
| Static | Static | Built files served from the edge cache | Static sites and static site generators |
| Hybrid | Hybrid | Static files from the edge; matching routes proxied to a server you already run | A server-rendered app that already has a host |
| Worker SSR | Worker SSR | Your app's server code as a Cloudflare Worker, next to its static assets | Next.js, SvelteKit, Astro, Remix and Keel |
| Container | Container | Your app in a container on Cloudflare Containers, built from your Dockerfile or one dply generates | Laravel, Symfony, Rails, Sinatra and Node HTTP servers |
See How dply works for what each mode does with a request.
Frameworks
dply recognizes these frameworks and runtimes. The full list, with versions and detection rules, is in Frameworks & runtimes.
| Framework | Language | Default mode |
|---|---|---|
| Laravel, Symfony, other Composer apps | PHP | Container |
| Rails, Sinatra, other Rack apps | Ruby | Container |
| Express, Fastify, Koa, NestJS | Node.js | Container |
| Django, Flask, FastAPI | Python | Container |
| Go, Rust, Java (Spring, Micronaut), Scala (Play), .NET, Elixir (Phoenix), Deno, Bun | Their own | Container |
| Next.js, Nuxt, SvelteKit, Remix, Astro, Hono, Keel | Node.js | Static, Hybrid or Worker SSR, depending on the project |
| Vite, Gatsby, Eleventy, VitePress, Docusaurus | Node.js | Static |
| Plain HTML | None | Static |
WordPress is not supported. Anything else that runs in a container deploys from its Dockerfile.
What dply manages
- Builds. Each deploy clones your repository and runs its build in an isolated container. See Builds.
- Deployments. On GitHub, every push to your production branch can deploy automatically. Earlier deployments stay available to roll back to. See Deployments.
- Preview deployments. Pull requests on GitHub get their own preview URL. See Preview deployments.
- Domains and TLS. Every app gets a dply hostname. You can attach your own domains, and certificates are issued for you. See Domains.
- Resources. Key-value storage, object storage, SQL databases, Postgres, MySQL, MongoDB, Valkey, queues, realtime WebSockets and more, attached to an app from its Overview page. See Resources overview.
- Background work. Queue workers and scheduled tasks for container apps. See Queue workers and Scheduled tasks.
- Security. Firewall rules, rate limits, bot protection, access control and a waiting room at the edge. See Firewall.
- Observability. Traffic analytics, build and request logs, and alerts. See Traffic & analytics.
Prerequisites
- A GitHub, GitLab or Bitbucket account that can read the repository you want to deploy.
- A payment card. Every plan, including the $0 Starter plan, asks for one at Checkout. See Plans & pricing. Static sites can also use the free tier without a card.
- For Worker SSR, SvelteKit, Astro and Remix need their Cloudflare adapter in your project. Next.js and Keel don't. See Server rendering (SSR).
Next steps
- Quickstart: deploy your first app.
- How dply works: what happens between a push and a live URL.
- Plans & pricing: what each plan includes.