Can you replace Amplify Hosting with a self-hosted platform?
Yes, for the hosting layer, but not for the whole Amplify stack. Coolify and Dokploy can run Git-triggered builds, containers, preview deployments and custom domains on servers your team controls. Neither replicates Amplify's managed CDN, its server-side rendering runtime or its AWS-integrated backend, so the team has to plan for those pieces separately. The core decision is which parts of the app move and which stay on AWS. A common split keeps the frontend build and hosting on your servers while Cognito, AppSync, DynamoDB, Lambda and S3 remain in place until a backend migration is scoped on its own. Confirm this split with your architects before you change any DNS records.
Start by inventorying what Amplify Hosting currently does for each app: branch deployments, custom domain and certificate handling, environment variables, rewrites and redirects, and whether Next.js pages use server-side rendering or API routes. Coolify supports Nixpacks, Dockerfile and Docker Compose build packs, and Dokploy supports Nixpacks, Dockerfile, Heroku and Paketo buildpacks and static sites served from NGINX. Check that each framework feature your app depends on runs in the chosen build pack, and test a preview deployment against wildcard DNS before you rely on it. Confirm with the vendor how each platform handles caching and edge distribution, because a self-hosted server does not provide Amplify's global CDN by default.
Plan for the operational side as well. Your team will own the servers, operating system patches, TLS renewal, container updates and build capacity, and those costs recur every month even though both platforms are free to self-host. Coolify's self-hosted edition is free under Apache-2.0, while Dokploy's core is Apache-2.0 but its /proprietary directory is source-available and production use of those features requires a commercial agreement. If you need SSO, SCIM or audit logs from Dokploy, read its license files and get written terms first. Ask each vendor for its current support options and release cadence, since neither offers the managed uptime commitments that Amplify's AWS service terms describe.
Which Amplify Hosting capabilities map to Coolify and Dokploy
This table maps each Amplify Hosting capability to the Coolify and Dokploy feature that covers it, and lists what your team must add on its own. Read the last column first, because the gaps determine most of the migration work. Items marked as needing vendor confirmation are not established in the supplied documentation and should be checked before you commit.
| Amplify Hosting capability | Coolify coverage | Dokploy coverage and what you add |
|---|---|---|
| Build from Git | Deploys from a Git repository using Nixpacks, Dockerfile, Static or Docker Compose build packs; GitHub, GitLab, Gitea and Bitbucket are supported. | Builds from Git with Nixpacks (default), Dockerfile, Railpack, Heroku or Paketo Buildpacks, or Static via NGINX. Confirm your Git provider integration with Dokploy. |
| Branch deployments | Deploys the branch you configure per application. Confirm how multiple long-lived branches map to separate applications. | Supports per-branch application setup. Confirm how branch triggers are configured in your version. |
| SSR for Next.js and other frameworks | Runs SSR as a container built with Nixpacks or a Dockerfile. You manage Node runtime, scaling and process restarts. | Runs SSR through Nixpacks or a Dockerfile on Docker Swarm. Confirm the Next.js output mode you need is supported by the chosen build type. |
| CDN and edge caching | Not included. Coolify does not provide a global CDN. Add one in front of your servers if you need edge caching. | Not included. Dokploy does not provide a global CDN. Add a CDN or cache layer yourself. |
| HTTPS and certificates | Traefik (default) or Caddy handles HTTPS automatically on each server. The Custom (None) option leaves TLS to you. | Traefik on ports 80 and 443 handles routing and TLS. Confirm certificate automation for your domain setup. |
| Custom domains | Assign domains to applications through the proxy. Point DNS at each server you deploy to. | Assign domains through the Traefik routing layer. Confirm multi-server domain routing with the vendor. |
| Environment variables | Set per application and per environment. Secrets are stored on the Coolify instance, so back up and restrict that instance. | Set per application through the web interface. Store and rotate secrets under your own process. |
| Preview deployments | Builds pull or merge requests from GitHub, GitLab, Gitea and Bitbucket at a {{pr_id}}.{{domain}} URL. Requires wildcard DNS and deletes previews on close or merge. | Preview deployments are documented. Confirm the Git provider support and the wildcard DNS requirement in the current docs. |
| Build caching | Not confirmed in the supplied facts. Confirm Docker layer caching behavior with the vendor for your build pack. | Not confirmed in the supplied facts. Confirm build cache behavior before sizing disk. |
| High availability and multi-region failover | Multi-server deployments are documented, but failover across regions is your responsibility. Plan DNS and load balancing yourself. | Clusters use Docker Swarm. Dokploy's docs recommend vertical scaling first. Multi-region failover, WAF and monitoring are yours to build. |
Coolify or Dokploy: which fits which team
Coolify suits teams that want a fully open, Apache-2.0 licensed platform with no feature gating in the self-hosted edition. It connects to each server over SSH, prepares it for Docker workloads and deploys from a Git repository, Dockerfile, Docker Compose file or prebuilt image. Its proxy layer runs one coolify-proxy container per server, with Traefik as the default and Caddy as the alternative, and both handle HTTPS automatically.
- Licensing: Apache-2.0 for the core, and the self-hosted edition is described as free forever with all features and no restrictions.
- Preview deployments: Built from GitHub (via a GitHub App or webhook), GitLab, Gitea and Bitbucket pull or merge requests, at a default
{{pr_id}}.{{domain}}URL that needs wildcard DNS. - Databases and backups: PostgreSQL, MySQL, MariaDB and MongoDB backups run on cron schedules, with uploads to S3-compatible storage.
- Minimum server size: At least 2 CPU cores, 2 GB RAM and 10 GB of free disk on Linux.
- Custom routing: The Custom (None) proxy option leaves routing and TLS certificates to your team.
Confirm the wildcard DNS, proxy choice and backup retention you need against the current Coolify documentation before you commit.
Dokploy suits teams that want a Docker Swarm based platform with a broad set of build types and a commercial route for enterprise controls. Its installer sets up Docker Swarm, uses ports 80 and 443 for Traefik and port 3000 for the web interface, and offers Nixpacks, Railpack, Dockerfile, Heroku and Paketo buildpacks, and static sites served from NGINX.
- Licensing split: Code outside the /proprietary directories is Apache 2.0. Code inside it, including SSO with OIDC and SAML, SCIM, audit logs, custom roles and license key handling, falls under the Dokploy Source Available License 1.0.
- Enterprise features: Production use of the proprietary components requires a commercial agreement with Dokploy.
- Scaling: Clusters use Docker Swarm managers and workers and need a Docker registry. Dokploy recommends vertical scaling first, because horizontal scaling needs more configuration.
- Minimum server size: At least 2 GB RAM and 30 GB of disk, tested on several Ubuntu, Debian, Fedora and CentOS releases.
- Database support: Postgres, MySQL, MariaDB, MongoDB and Redis, with S3 backup destinations.
Read the Dokploy LICENSE files with your legal team before you rely on any proprietary component.
The licensing question depends on how the platform will be used, not only on which project you choose. Coolify's core and self-hosted edition are Apache-2.0 with no feature restrictions. Dokploy's core is Apache 2.0, but its enterprise components are source-available and its terms forbid commercial resale or redistribution of Dokploy as a service without explicit consent from the Dokploy team.
- Internal use: A company running apps for its own products or staff is not reselling the platform, so the resale restriction does not apply to it.
- Hosting for clients: An agency or managed service provider that operates the platform for other businesses should treat the resale clause as a direct constraint.
- Enterprise controls: If SSO, SCIM or audit logs are required, Dokploy's commercial agreement becomes part of the cost model.
- Copyright holder: Dokploy's license files name Dokploy Technology, Inc.
- Audit trail: Keep the license files of the version you deploy with your change records.
Ask legal counsel to confirm whether your planned use counts as resale, and get the Dokploy commercial terms in writing if you need proprietary features.
Both platforms are designed for single-server or small multi-server deployments, but they scale in different ways. Coolify manages multiple servers over SSH, and each server runs its own proxy and deployments. Dokploy uses Docker Swarm, which brings cluster behavior and a registry dependency. The minimum sizes in the two installation guides also differ, which affects the smallest viable server.
- Coolify sizing: Plan for at least 2 CPU cores, 2 GB RAM and 10 GB of free disk per server.
- Dokploy sizing: Plan for at least 2 GB RAM and 30 GB of disk, with more disk for images and backups.
- Dokploy scaling path: Vertical scaling is the recommended first step, and horizontal scaling needs extra Swarm and registry configuration.
- Operations load: A Swarm cluster adds manager and worker roles to monitor and patch.
- Load testing: Test your own workload on the target server size before choosing either platform.
Before you size servers, ask each vendor or your own platform team to confirm current requirements for your workload, since real traffic patterns vary widely.
The better fit depends on who runs the platform day to day. A small platform team that wants one tool across many small apps usually has different needs from an infrastructure group that already runs Docker Swarm or wants enterprise identity controls. Both platforms can run the same Git-based workflow, so the decision comes down to licensing, cluster needs and the controls your auditors expect.
- Small platform team: Coolify's single-server model and permissive license keep the operating surface small.
- Teams with Swarm experience: Dokploy's cluster model fits teams that already operate Docker Swarm.
- Teams needing SSO and SCIM: Dokploy's enterprise components are the direct route, but they carry a commercial agreement.
- Teams with multi-provider Git: Coolify's preview support covers GitHub, GitLab, Gitea and Bitbucket.
- Pilot first: Run a short pilot of each on a non-production server.
Write your identity, backup and resale requirements down, then test both platforms against them before you decide.
Why Dokploy's license split matters for enterprise buyers
Dokploy is open core, and its license is split by directory. The Apache License 2.0 covers the code outside the /proprietary directories, as set out in its LICENSE.MD. Code inside /proprietary falls under the Dokploy Source Available License 1.0, which permits production use only under a commercial agreement with Dokploy. In the repository, that proprietary code includes SSO with OIDC and SAML, SCIM provisioning, audit logs, custom roles and license key handling. These are the controls a regulated buyer usually needs for access reviews and evidence, so they are the features most likely to decide whether a Dokploy deployment can run in production without a contract.
Legal and procurement should read LICENSE.MD, LICENSE_PROPRIETARY.md and TERMS_AND_CONDITIONS.md before any commitment, using the Dokploy proprietary components directory to map which features sit under which license. Confirm with Dokploy in writing whether your intended use, including internal production use across your own servers and any use by contractors, is covered by the free terms or requires a commercial agreement. The terms also forbid commercial resale or redistribution of Dokploy as a service without explicit consent, which matters if your platform team serves other business units or subsidiaries. Ask for the current wording, since repository terms can change between versions.
For comparison, Coolify's pricing page describes its self-hosted edition as free forever with all features and no limitations or restrictions, and Coolify is licensed under Apache-2.0. That does not remove the need to read the license for your own use, but it means a Coolify evaluation does not hinge on which features sit behind a commercial agreement. Whichever platform you choose, record the license basis, the features you depend on and the named contact who confirmed them, so the decision survives a change in staff or a future renewal.
Running Coolify or Dokploy alongside the rest of AWS
Moving the frontend and server-side rendering off Amplify Hosting does not require moving the whole backend at the same time. The points below show where the self-hosted hosting layer still touches AWS, where it can stand alone, and what to verify before cutover.
Keeping Cognito, AppSync and DynamoDB
The Amplify backend can stay on AWS while Coolify or Dokploy serves the frontend and SSR. The app keeps calling the same Cognito user pool, AppSync endpoint and DynamoDB tables, so the hosting change is independent of the data migration. Confirm which AWS services the SSR app still calls, including any Lambda functions or S3 buckets reached through environment variables, because those calls keep generating AWS charges and need credentials on your servers.
Calling AWS APIs from your servers
Once the app runs on your own servers, every AWS call goes out from your network under an IAM identity you configure. Store access keys as environment variables in Coolify or Dokploy, scope them to the specific Cognito, AppSync or S3 resources the app needs, and rotate them on a schedule. Check which secrets are exposed to build steps, since a value needed only at runtime should not be baked into a build image.
S3-compatible backup targets
Coolify and Dokploy can send database backups to S3-compatible storage. Coolify's PostgreSQL backups use the pg_dump custom format and can be uploaded to S3-compatible storage with retention by count, days or size, while Dokploy offers automated backups to S3 destinations configured in its settings. Decide whether backups go to an existing AWS bucket or to a separate account, and confirm that Redis, Dragonfly and KeyDB data is not covered by Coolify's scheduled backups.
DNS and certificates for custom domains
Custom domains for the frontend move to your DNS provider or Route 53, pointed at the server running the proxy. Coolify runs Traefik or Caddy and handles HTTPS automatically, while Dokploy uses Traefik on ports 80 and 443. Preview deployments in Coolify need wildcard DNS for the {{pr_id}}.{{domain}} pattern. Confirm who owns the zone, how Amplify's domain association is released, and whether a DNS change is needed before traffic moves.
Git and CI webhooks
Deployments on Coolify and Dokploy are triggered by Git provider webhooks or a GitHub App rather than by the Amplify console. Each Git provider's webhook URL and secret must be configured again, and any CI pipeline that currently runs Amplify build steps needs an equivalent step. Check that the repository branch mapping matches what Amplify used, and that production deploys are gated the same way.
How to move an Amplify Hosting app to Coolify or Dokploy
This sequence moves the web front end of an Amplify app, its builds, SSR routes, preview URLs and custom domains, onto servers you run, with Amplify kept live until the switch is verified and rollback is ready.
Inventory branches, variables and domains
The app owner or platform engineer records every connected branch, its build settings, the environment variables set per branch, the custom domains and their DNS records, and any rewrite and redirect rules in the Amplify console. Keep secret values in a password manager rather than copying them into a spreadsheet. The step is done when every branch and domain has a written row that someone other than the author can check against the console.
Choose a build method for each app
For each app, the team selects Nixpacks, a Dockerfile or the Static build pack in Coolify, or the equivalent in Dokploy, based on how the framework is built today. Nixpacks suits many standard Next.js projects with no custom build steps, a Dockerfile suits apps with system packages or a specific runtime, and Static suits pre-rendered sites that do not need server-side rendering. Confirm that SSR routes are not served as static output, because a Static build will drop them. The output is a one-line decision per app recorded in the inventory.
Provision and harden the servers
The platform team provisions Linux servers that meet the stated minimums for the chosen tool: at least 2 CPU cores, 2 GB RAM and 10 GB free disk for Coolify, or at least 2 GB RAM and 30 GB disk for Dokploy. The team then applies its own hardening baseline, including SSH key access, firewall rules for ports 80 and 443, and patching. Confirm that the installer runs on the operating system version your security team has approved. The step closes when the installer completes and the admin interface is reachable only through the agreed path.
Deploy apps alongside Amplify
The team deploys each app from its Git repository to the new server while Amplify keeps serving production traffic. Environment variables are re-entered in the new platform, and any build-time variables are checked separately from runtime ones. Use a test hostname or the platform's preview URL for this stage, so no public DNS changes yet. The step is done when each app builds successfully and its deployment logs show no missing variable errors.
Test SSR routes and preview URLs
QA staff walk through server-rendered pages, API routes, authenticated pages and redirects on the new host, comparing responses with the Amplify version. Preview deployments in Coolify use a pull or merge request URL pattern that needs wildcard DNS, so confirm that DNS is in place before testing previews. Record any route that returns different content, headers or status codes. The step is done when a written test list passes on the new host and every discrepancy has an owner and a fix.
Switch DNS with a rollback plan
The network owner lowers the DNS record time-to-live in advance where the DNS provider allows it, then points each custom domain to the new server and issues the TLS certificate through the proxy. The rollback plan keeps the original Amplify DNS target written down and ready to restore, and Amplify stays connected until the rollback window the team has agreed is over. The step is done when each domain resolves to the new server, serves valid HTTPS and passes the test list from the previous step.
Decommission Amplify hosting
Once production has been stable through the agreed window, the team disconnects the branches from Amplify, removes the custom domains there and records a final export of build settings and environment variables for the audit file. Check the Amplify bill for the period to confirm that build and hosting charges have stopped. If the app uses Amplify's data layer, the database data migrates on a separate path: the sibling migration and export pages cover DynamoDB, Cognito users and S3 files, so this step does not repeat them. The step is done when Amplify has no active branches or domains for the app.
What Amplify charges versus what self-hosting costs
Amplify Hosting meters the parts of a frontend deployment that grow with traffic and release cadence: build minutes, hosted storage, data served to visitors and server-side rendering compute for frameworks such as Next.js. Each line item moves with usage, so a busy release week or a traffic spike changes the bill without a new contract. Self-hosting replaces those meters with components you rent or own: the servers running Coolify or Dokploy, disk, outbound bandwidth, backup storage for databases and any CDN or web application firewall you add in front. Labor is the line that is easy to miss. Someone must patch the host operating system, update the platform, watch disk and memory, and restore from backup when needed. That cost recurs even when the server bill is flat, so ask who owns the work and how many hours per month it represents. Confirm current Amplify rates on AWS's published pricing before you compare.
Two hosted-management options sit between the extremes. Coolify Cloud charges $5 per month for 2 connected servers and $3 per month for each additional server, with a 20% discount for annual billing, according to Coolify's pricing page. Coolify runs the management instance on its infrastructure while your servers are billed separately, so the fee covers the control plane and not the machines it deploys to. Dokploy's Hobby plan is $4.50 per month per server for one server, one organization and one user. Its Startup plan starts at $15 per month for up to 3 servers with basic RBAC. Dokploy's Enterprise tier, cloud or self-hosted, is quoted by sales and includes SSO/SAML, SCIM, audit logs and an SLA. Check whether the tier you pick covers the users, environments and preview builds you plan to run.
Request written quotes for your own volumes before you choose. For Amplify, pull the last few invoices for build minutes, hosted storage, data served and SSR compute, then project them against your planned release frequency and preview count. For the self-hosted side, size servers against the published minimums: Coolify needs at least 2 CPU cores, 2 GB RAM and 10 GB of free disk, and Dokploy needs at least 2 GB RAM and 30 GB of disk. Ask each vendor to price the enterprise features you need in writing, and confirm the commercial use terms, because production use of Dokploy's source-available components requires a commercial agreement. Include bandwidth, S3-compatible backup storage, CDN and WAF costs, and monthly operations hours, so both columns describe the same workload.
Questions teams ask before replacing Amplify Hosting
How much effort does moving off Amplify Hosting take?
The effort depends mostly on how much of your delivery depends on Amplify-specific behavior, not on the size of the app itself. A static or client-rendered front end that builds with a standard command is usually the simplest case. Server-side rendering, Amplify-managed environment variables, custom build specs, redirects and rewrites, and any Amplify-provisioned backend resources add work because each one must be recreated on the new platform. Ask for a written inventory of build settings, domains, environment variables and server-side routes before agreeing on scope. Note that Coolify and Dokploy both build from Git using Nixpacks, Dockerfiles or Docker Compose, so the build step itself often moves with little change. The cost of operating your own servers is a separate question covered in the cost comparison.
Can our team migrate from Amplify Hosting without outside help?
A team with Docker and Linux experience can often do a small move alone, but the decision should rest on who will own the servers after go-live. Coolify installs with a single script on supported Linux distributions and connects to servers over SSH, which lowers the initial barrier. Dokploy installs Docker Swarm and expects you to plan for cluster behavior, backups and registry use. Both platforms are open source, so no license purchase is needed to start, but patching, monitoring, certificate renewal and restore testing remain your responsibility. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure under a written, fixed scope, and offers retainers for ongoing support. Ask any provider to confirm which of these tasks they will own.
What skills do our engineers and DevOps staff need?
Plan for people who can administer Linux, manage Docker containers, configure DNS and TLS, and read logs. Your application engineers need to understand Git-based build settings, environment variables and how a container starts. Your DevOps or platform staff take on server sizing, firewall rules, backup schedules and upgrades. Coolify's documentation lists minimum requirements of 2 CPU cores, 2 GB RAM and 10 GB of free disk, while Dokploy's installation docs list at least 2 GB of RAM and 30 GB of disk, so confirm the sizing with your provider against your traffic and build load. Ask your team to name one owner for on-call response, because a self-hosted platform has no vendor support queue unless you buy it separately.
Do Coolify and Dokploy support preview deployments and custom domains?
Yes, both platforms document preview deployments and custom domains, but the setup differs. Coolify builds pull or merge requests from GitHub, GitLab, Gitea and Bitbucket and deletes each preview when its request closes or merges. Its default preview URL pattern needs wildcard DNS for your domain, so your DNS provider must support that record. Coolify runs a proxy on each server with Traefik by default or Caddy as an alternative, and both handle HTTPS automatically unless you choose the Custom option. Dokploy also documents preview deployments, and its Traefik-based routing covers custom domains. Confirm the Git provider integration you use, the wildcard DNS setup and the certificate behavior with the platform's current documentation before you commit to a workflow.
How do backups and database restores work on these platforms?
Backups are a separate responsibility you configure, test and pay for in storage. Coolify's scheduled backups cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse, but not Redis, Dragonfly or KeyDB. Its PostgreSQL backups use the pg_dump custom format, run on cron schedules, can be uploaded to S3-compatible storage, and apply retention by count, days or size. Coolify's Import Backup accepts PostgreSQL SQL dumps, custom archives, tar archives and all-database dumps. Dokploy offers automated backups to S3 destinations configured in its settings for its supported databases. Logical dumps restore to a point in time only as fresh as your last run, so set schedules against your recovery objectives, and test restores on a separate server regularly. Ask your provider to document restore steps and who runs them.
Can a self-hosted platform meet our data residency and availability needs?
A self-hosted platform keeps application data on servers you select, which helps with residency, but availability is a design decision you must make. Your choice of cloud region or data center determines where data lives, and the platforms do not change that. Coolify and Dokploy both run on a single server by default, so a single host failure takes applications offline unless you add redundancy. Dokploy's documentation recommends vertical scaling first because horizontal scaling through its Docker Swarm cluster needs more configuration. Confirm with your compliance team which regions, backup locations and access paths are allowed, and ask your provider to document recovery time and recovery point targets that you have tested. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors issue any attestation.
How DeployOpen scopes and delivers an Amplify Hosting replacement
DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For an Amplify Hosting replacement, that means a fixed-scope engagement that moves builds, routing, preview environments and domains onto servers you control.
How we scope
- Inventory every Amplify app, framework version, build setting, environment variable and custom domain before any server is chosen.
- Agree in writing which SSR routes, redirects, preview branches and build pipelines move, and which stay out of scope.
- Confirm server count, sizing, region and where build logs and secrets must reside before work starts.
How we build
- Install Coolify or Dokploy on servers in your environment and connect them to your Git provider over the agreed access model.
- Configure the reverse proxy, TLS certificates, wildcard DNS for preview URLs and the cutover plan for each custom domain.
- Test builds, server-side rendering, preview deployments and database backups in a staging environment before production cutover.
How we hand over
- Deliver written runbooks covering deployment, rollback, backup restore testing and how to add a new application or server.
- Document the license terms of the chosen platform, including which features fall under its commercial terms, so your legal team can review them.
- Walk your platform and operations staff through the running system and record who owns each credential and each server.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped separately from the original engagement.
- Plan platform upgrades, including new major releases such as Coolify v5 when they arrive, as part of the retainer.
- Ask any provider for a quote that lists server costs, setup effort, support hours and who pays for each line, so you can compare fairly.
