How to migrate from DigitalOcean App Platform to Coolify
Teams usually start this move after a renewal, a cost review or a data residency requirement that makes a managed platform harder to justify. The short answer is that each App Platform app becomes a container running on servers your team operates, and the work falls into three parts: remapping the app spec to Coolify resources, moving the database, and taking on the operating model that App Platform previously handled for you. Coolify is licensed under Apache-2.0 and its self-hosted edition is free to run, so the recurring cost is the servers, storage, backups and the engineering time to keep them patched.\ \ The work is typically done by the platform or DevOps engineer who already owns the app's deployment, with an application developer checking build and runtime behavior. An outside implementation partner can take the migration as a fixed-scope project, but the team still needs to own DNS, secrets and the on-call response afterward. Effort depends mostly on three things: the number of components in the app spec, the size and write activity of each database, and how much spare operations capacity the team has to run Linux hosts, the Coolify instance and its proxy.
Before you schedule cutover, confirm three things in your own environment. First, check that each component's build can run from a Dockerfile or a supported build pack, and that the target servers meet Coolify's stated minimums for CPU, memory and disk. Second, decide who owns the servers, updates and backups, since Coolify's own guide for teams leaving managed platforms notes that a rollback can redeploy an application image but does not restore databases or persistent files. Third, plan the database cutover window with a tested restore before you touch production DNS, because that step drives how much downtime the switch costs in practice.
Which App Platform features map to Coolify and which need rework
This table maps each App Platform component and setting to its closest Coolify equivalent and marks it clean, needs rework or gap. Read the status column first, then the notes, because a clean mapping still needs a check of your build and runtime settings. Autoscaling and managed high availability are not provided by Coolify as a managed service, so confirm those against your own server design before cutover.
| Component or setting | Coolify equivalent | Status and what to check |
|---|---|---|
| Web services | Application on a server, built from a Git repository, Dockerfile or build pack | Clean. Confirm port, health endpoint and build command match the app spec. |
| Workers | Application without a public domain, or a Docker Compose service | Needs rework. Remove any domain and verify the worker starts without an HTTP port. |
| Jobs (pre-deploy and scheduled) | Scheduled tasks and pre-deployment commands, or a separate cron container | Needs rework. Confirm how each job runs and where its logs and failures appear. |
| Static sites | Static build pack served through the coolify-proxy | Clean. Check the build output directory and any rewrite rules. |
| Managed databases | Coolify-deployed PostgreSQL, MySQL, MariaDB or MongoDB on your server | Needs rework. You now own provisioning, patching, failover and restore testing. |
| Routes and domains | Domains assigned per application, with HTTPS handled by Traefik or Caddy | Needs rework. Plan DNS records and certificate issuance before lowering TTLs. |
| Environment variables | Application environment settings, with build-time and runtime variables set separately | Needs rework. Confirm which variables are needed at build time and mark secrets accordingly. |
| Build settings | Nixpacks, Railpack (beta), Static, Dockerfile or Docker Compose build packs | Needs rework. App Platform buildpacks do not map one to one, so test each build. |
| Health checks | Container health checks and proxy routing behavior | Needs rework. Rebuild the check in the Dockerfile or Compose file and test it on the new server. |
| Autoscaling | No managed autoscaling. Capacity is set by the servers you add | Gap. Coolify does not provide autoscaling as a managed service. Confirm the scaling design against your own requirements. |
| Managed high availability | Operator-designed redundancy across servers, databases and backups | Gap. Coolify does not provide managed high availability. Confirm the design, failover method and recovery targets with your team. |
Reading the App Platform app spec for components and routes
The exported app spec is the inventory for this migration, so start by listing every entry under services, workers, jobs, static_sites and databases. Export each app with doctl apps spec get and work from that file. Each component becomes its own Coolify resource with its own source and build settings. For each one, record the github or git block (repository, branch and source_dir), the dockerfile_path if present, build_command, run_command and http_port. The instance_size_slug has no direct equivalent, because container capacity comes from the server you choose. A component with a Dockerfile maps to the Dockerfile and build pack options in Coolify. A component that relies on buildpack detection maps to Nixpacks or Railpack, and Railpack is still in beta, so test the build before you rely on it. Static sites map to the Static build pack. Workers and jobs need no domain. When several components share one repository and depend on each other, a Docker Compose file may be the clearer target.
Secrets need the most care. The spec can carry encrypted secret values or placeholders, and exported files often end up in laptops, tickets and shared drives. Do not copy any value from the export into Git, a wiki or a chat thread, and do not commit the exported spec to the repository. Keep the file in a restricted location and delete it after cutover. Re-enter each variable in the matching Coolify resource. Separate variables needed only during the image build from runtime variables, and confirm how Coolify flags build-time values for the build pack you chose, so that a value needed only at build time is not left in the running container. Check the envs list for connection strings that App Platform generated for managed databases. Those strings change when the database moves, so set them only after the new database endpoint and credentials exist.
Migration sequence from inventory to decommission
This sequence moves each App Platform app to Coolify in controlled stages, so every component, datastore and domain is verified before any traffic moves. The final state is a Coolify deployment with a documented rollback path and App Platform resources retired only after a retention period.
Inventory apps, components, datastores and domains
Export the App Platform app spec as YAML for each app and list every component: services, workers, jobs, static sites and any development databases. Record the build source, build settings, environment variables, routes, health checks and each attached domain with its current DNS record. Confirm with DigitalOcean which secrets are stored in the spec and which must be re-entered manually. The step is done when a single inventory sheet maps every component to its target Coolify resource and every domain to its owner.
Pilot one low-risk app on Coolify
Choose one internal or low-traffic app and create it in Coolify on a server that meets the documented minimum of 2 CPU cores, 2 GB RAM and 10 GB free disk. Rebuild it from its repository using a Dockerfile where possible, or a Nixpacks build pack when the app has no Dockerfile, and set the environment variables from the inventory. The output is a rebuilt image that deploys, passes its health checks and serves traffic on a test hostname. Use the Docker Image method only if you have already built and tested the image elsewhere.
Restore the database and verify the data
For a PostgreSQL datastore, take a logical dump from App Platform, then restore it into a Coolify-managed PostgreSQL instance using the Import Backup feature or a standard restore command. Compare row counts and run the application's own read and write checks against the restored copy. Plan the cutover of writes through a short maintenance window, since App Platform does not give you a replication source you control. The output is a verified restore, documented with the date, dump size, checksum and the checks that passed.
Run the parallel environment before cutover
Bring up the full Coolify environment with the same app versions and configuration, but keep the production domain pointed at App Platform. Test the application through the Coolify test hostname, including login, background jobs, scheduled tasks, outbound webhooks and file uploads. Confirm TLS certificates are issued by the Coolify proxy, Traefik or Caddy, and that logs and alerts reach your team. The step is complete when a written checklist of functional tests has passed on the parallel stack.
Cut over by DNS change with rollback ready
Lower the TTL on the production DNS record ahead of the change, then repoint the record from App Platform to the Coolify server, for example a CNAME or A record as your DNS provider requires. Freeze writes on the App Platform database, take a final incremental dump, restore it into Coolify and then switch the record. Keep the App Platform app running and the old DNS value written down so you can revert the record if health checks fail. The output is a DNS change record showing the old value, new value, time of change and the person who approved it.
Monitor and confirm the new production state
After the cutover, watch error rates, response times, database connections and certificate status on the Coolify server while the App Platform app remains available. Confirm scheduled database backups are running to S3-compatible storage and that a test restore from them succeeds, because Coolify backups cover PostgreSQL but not every datastore. Record that the rollback window has closed only when the owners agree the service is stable. Do not assume Coolify restores data on rollback, since its guide notes a rollback can redeploy an application image but does not restore databases or persistent files.
Decommission App Platform resources after retention
After the agreed retention period, delete the App Platform apps, their development databases and any dedicated egress IPs, after confirming no DNS records, webhooks or third-party allowlists still point to them. Keep a final export of the app specs and database backups in your own storage for audit purposes. The output is a decommission record listing each deleted resource, the date removed and the evidence that no traffic remained. Ask DigitalOcean to confirm how billing stops for each resource type before deletion.
What data and integrations move, and what you rebuild
App Platform hides much of the plumbing that a Coolify host has to provide itself. Databases, object storage, secrets, Git webhooks and third-party callbacks each need an explicit owner and a tested path before you cut over. The cards below cover what carries over, what needs a new address, and what Coolify's backups do not protect.
Database dumps and restores
Coolify's scheduled backups cover PostgreSQL, MySQL, MariaDB and MongoDB, and its Import Backup accepts PostgreSQL SQL dumps, custom archives, tar archives and all-database dumps. Take a fresh export from App Platform's managed database, restore it into a Coolify-managed database, and compare row counts and key tables before you point the app at it. Confirm the source and target major versions match, since a version mismatch is a common cause of failed restores.
Redis, Dragonfly and KeyDB
Coolify deploys Redis, Dragonfly and KeyDB, but its scheduled backups do not cover them. Decide per workload whether the data is a cache that can be rebuilt or durable state such as queues or sessions. For durable data, plan a separate export and restore step and test it on a staging server before cutover.
Object storage targets
Files uploaded to App Platform's object storage or a third-party bucket do not move with the app image. Copy existing objects to an S3-compatible target that your Coolify backups and application can reach, then update bucket names, endpoints and access keys in the app environment. Check that uploads and signed URLs still work from the new domain.
Environment secrets and config keys
App Platform stores environment variables and encrypted secrets in the app spec, and those values must be re-entered in Coolify's environment settings. Rotate database passwords, API keys and signing secrets during the move rather than copying them unchanged. Confirm which variables are build-time and which are runtime, because build-time values must be set before the image is built.
Git webhooks and preview setup
Repository webhooks pointing at App Platform stop triggering deploys once you disconnect the app, so create the webhook or GitHub App connection in Coolify and remove the old one. Preview deployments in Coolify need wildcard DNS for the default {{pr_id}}.{{domain}} pattern, and Coolify deletes previews when a request is closed or merged. Test one pull request end to end before you rely on it.
Third-party callbacks and allowlists
Payment providers, OAuth identity providers, email webhooks and partner systems hold the old App Platform hostname or a fixed outbound IP. List each callback URL and allowlisted address, then register the new domain with each provider before cutover. If a partner allowlists the outbound IP, ask them about the new address first, because a Coolify server's IP changes when you move hosts.
Moving the database with minimal downtime
Choose the database move by size and tolerance for downtime before you touch the app. For a small PostgreSQL database, a dump and restore during a short maintenance window is the simplest path: take a logical dump, restore it into the PostgreSQL service Coolify deploys on your server, run row counts and application smoke tests, then repoint the connection string. For a larger database, logical replication between the App Platform database and the new server lets you copy changes while the old database keeps serving traffic. The PostgreSQL upgrading documentation notes that logical replication works between different major versions, which allows a major upgrade with only several seconds of downtime. Confirm with your own data volume and write rate that this window is realistic, and confirm that your DigitalOcean database tier and your extensions support logical replication.
Treat a verified backup as a prerequisite for cutover, not a safety net you add afterward. Coolify's rollback can redeploy a retained application image, but it does not restore databases or persistent files. If a cutover goes wrong, the only way back to the data is the backup you took before the switch. Coolify's scheduled backups use the pg_dump custom format, can upload to S3-compatible storage, and apply retention by count, days or size. Run a test restore into a scratch database, record the time it takes, and confirm that the restored schema, sequences and row counts match the source. Keep the source database read-only but intact until the new environment has run long enough to make rollback unlikely to be needed.
Confirm the connection layer and the version you are moving to before the window. If your application opens many short connections, check whether PgBouncer belongs in front of PostgreSQL on the new server, since the connection behavior after cutover can differ from App Platform's. Confirm which PostgreSQL major version you are targeting against the official support windows: at the time of the supplied facts, version 14 is supported only until November 12, 2026, so a new deployment on an older major version starts with a limited support horizon. Check the current versioning policy before you pick a version, and plan the upgrade path so the new server does not begin life on a version that is close to end of support.
What usually goes wrong and how to prevent it
Most failed App Platform to Coolify moves fail in the same few places: configuration that did not carry over, builds that behave differently, data that was never proven restorable, and operations nobody picked up after cutover. Each card names one of these risks and the check that prevents it.
Missing environment variables
App Platform stores environment variables in the app spec, and some are marked as encrypted or scoped to build time or run time. Copying only the visible values into Coolify can leave out secrets, build-only variables or variables referenced by other components. Before cutover, diff the list of keys in the spec against the variables set in each Coolify application, and confirm which ones must be available during the build. Set the build-time flag explicitly where the framework needs it.
Build output differs by build pack
App Platform builds with buildpacks, while Coolify offers Nixpacks, Railpack (beta), Static, Dockerfile and Docker Compose. The same repository can produce different runtimes, start commands or installed system packages. Pin the build method and write a Dockerfile for any app whose build must be reproducible, then compare the running container's start command and exposed port against the App Platform run command before routing traffic.
Unverified database restores
A backup that has never been restored is an assumption. Coolify's scheduled backups for PostgreSQL use the pg_dump custom format, and its Import Backup accepts several dump formats, so the restore path depends on how the dump was taken. Restore the most recent dump into a scratch Coolify database, run row counts and a few application queries against it, and record the time it took. Repeat this immediately before the production cutover.
Redis persistence left unconfigured
Coolify's scheduled backups do not cover Redis, Dragonfly or KeyDB. If App Platform Redis held data that the application treats as durable, such as sessions, queues or rate-limit state, a Coolify Redis service without persistence or a separate backup will lose that data on restart or host failure. Confirm with the application team which keys must survive, enable the persistence settings the service exposes, and plan a separate backup or a rebuild procedure for the rest.
Certificates fail when DNS is not ready
Coolify's proxy, Traefik by default or Caddy, requests TLS certificates automatically, but the request only succeeds once the domain resolves to the new server. Lowering the DNS TTL well before cutover and pointing records at the Coolify server while App Platform still serves traffic lets the certificate issue before users move. Check that the certificate is issued for every hostname in the App Platform routes, including redirects from the apex domain to www, and test each one from outside your network.
Missing wildcard DNS for previews
Preview deployments in Coolify build pull or merge requests at a default {{pr_id}}.{{domain}} address, and that address needs a wildcard DNS record pointing at the server. Without it, every preview build succeeds but no preview URL resolves, and reviewers assume the deployment is broken. Add the wildcard record before enabling previews, confirm the certificate covers the preview hostnames, and make sure the preview cleanup runs when requests close.
Patching and incidents with no owner
App Platform handles the host, its operating system updates and much of the platform's runtime maintenance. After cutover, Coolify's host, the Docker engine, the proxy and every database image become your responsibility. Assign a named owner for host patching, Coolify upgrades, backup monitoring and on-call response before the cutover date, and confirm how a rollback works. Coolify's migration guide notes that a rollback can redeploy an application image but does not restore databases or persistent files, so the backup owner needs to be part of the runbook.
What drives migration cost and duration
This table lists the factors that change how much work a move from App Platform to Coolify takes, and which costs are paid once versus every month. Read each row against your own app spec, database size and team skills to scope the work before asking for a quote. The main takeaway is that the server and its ongoing operations recur, so the cutover is only part of the total cost.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Component count | Each service, worker, job and static site in the app spec needs its own Coolify application, build settings and health checks. | Group related components, remove unused ones and confirm which need public routes before rebuilding. |
| Language and build complexity | Buildpack detection may work for simple apps, while monorepos, custom system packages or multi-stage builds usually need a Dockerfile written and tested by hand. | Start from the existing build output, pin base images and test each build locally before cutover. |
| Database size and engine | Larger PostgreSQL or MySQL datasets take longer to dump, transfer and restore, and each extra engine adds its own backup and restore steps. | Measure data volume early, test a full restore on a copy and plan a replication-based cutover for large datasets. |
| Domains and certificates | Each custom domain must point to the new server, and HTTPS certificates must be issued and verified before traffic moves. | Lower DNS TTL well before cutover and list every domain, subdomain and redirect in advance. |
| Redis and other datastores | Scheduled backups in Coolify do not cover Redis, Dragonfly or KeyDB, so their persistence and recovery need separate design and testing. | Decide whether cached data can be rebuilt, or set up and test a separate backup job for any data that must survive. |
| Team familiarity with Docker and Linux | Teams new to SSH, Docker networking, firewalls and reverse proxies need more time for setup, troubleshooting and documentation. | Schedule a hands-on rehearsal in a staging server and document each step in a runbook. |
| Operations after cutover (recurring) | The server, its operating system, Docker, the proxy, backups, security patches and monitoring become your responsibility, and Coolify's own rollback does not restore databases or files. | Ask for a written operations scope covering patching, backup verification, alerting and who responds to incidents. |
| One-time versus recurring costs | Migration design, rebuilds, testing and cutover are one-time. The server, storage, offsite backup storage and staff time to operate them recur every month. | Ask any quote to split one-time work from the recurring operations and infrastructure lines so both can be compared with App Platform. |
How the migration differs by starting point
A single web service with a managed Postgres database is the simplest case, and it is usually the first migration a team attempts. The sequence is short: provision a server, install Coolify, connect the server, create the application from the Git repository, and point it at a Dockerfile or a build pack. Then create a PostgreSQL resource, restore a dump of the App Platform database, and test the app against the new database before touching DNS.
- Server and install: Coolify runs on a Linux server with at least 2 CPU cores, 2 GB RAM and 10 GB of free disk, and it installs with a single script.
- Environment variables: Copy each value from the App spec by hand, and mark secrets so they are not exposed in build logs.
- Database move: Dump the managed database and restore it with the Import Backup feature, then compare row counts and key tables.
- Domain cutover: Lower the TTL on the existing record ahead of time, then switch the record once the new instance serves traffic and HTTPS certificates are issued.
- Keep the old app running: Leave the App Platform app and its database untouched until the new setup has run through a full business cycle.
Before cutover, confirm that your backup schedule and off-server copy exist, because Coolify does not restore databases or persistent files from a rollback.
An app with separate web services, background workers, scheduled jobs and static components needs a mapping step before any deployment. Each App Platform component becomes its own Coolify resource, and shared settings such as environment variables must be defined once per resource so workers and web processes read the same values. The main risk is an ordering problem, where a worker starts before its queue or database is reachable.
- Component inventory: List every service, worker and job in the App spec, including its build command, run command and internal port.
- Resource mapping: Create one Coolify application per component, and confirm that Coolify's build pack or Dockerfile handles each one.
- Internal connectivity: Replace App Platform service discovery names with the addresses or container names used on your server, and test each connection.
- Scheduled jobs: Recreate cron jobs in the environment that runs them, and disable the App Platform copy first so the job does not run twice.
- Staged cutover: Move workers before the web tier when the queue can drain safely, and check queue depth at each step.
Document the dependency order for each cutover, because a rollback of one component may require a matching rollback of its neighbors.
When the database is large, a dump and restore may keep the application offline for longer than the business accepts. PostgreSQL supports logical replication between different major versions, which lets you copy changes to a new server while the old one keeps serving traffic. The cutover then reduces to a short write pause, and the PostgreSQL upgrading documentation describes this path as allowing major upgrades with only several seconds of downtime. The actual window depends on your write volume, application behavior and checks, so test it with production-like data.
- Target version: Choose a supported PostgreSQL major version for the new server. Version 18 is the newest supported release in the versioning policy, and older releases have published end dates.
- Replication setup: Create a publication on the source and a subscription on the target, and confirm that the target has the required schema first.
- Sequences and schema changes: Logical replication does not carry every object automatically, so review sequences, large object data and DDL changes before cutover.
- Connection pooling: Place PgBouncer in front of the database if many connections change at cutover, and confirm pool settings in advance.
- Verification: Compare checksums or row counts on critical tables, and rehearse the cutover on a copy.
Ask the team who owns the App Platform database today, because the managed service may handle replication settings you will now need to configure yourself.
A team without Linux operations experience can migrate the application code successfully and still find the operating model hardest. On App Platform, the provider applies platform patches, manages underlying hosts and handles much of the availability work. Moving to Coolify transfers those duties to the team, including server updates, Docker maintenance, backups, certificate renewal checks and incident response. Plan this before the first deployment, not after.
- Operating ownership: Name the person or group responsible for server patching, Docker updates, backup verification and on-call response.
- Backup proof: Schedule database backups to S3-compatible storage, and test a restore on a separate server before relying on them.
- Monitoring: Set up alerts for disk space, container restarts and certificate expiry, because no vendor will page you for them.
- Access control: Restrict SSH access and API tokens, and review who can deploy to production.
- Outside help: Decide early whether to use a managed hosting partner, a retainer for upgrades and support, or an internal rota.
Do not start the cutover until the team has rehearsed one full restore and one server rebuild, and check that the operating work matches the staffing you actually have.
Questions buyers ask before moving off App Platform
What drives the effort and cost of moving from App Platform to Coolify?
The main drivers are the number of components in the app spec, how many databases and persistent volumes need moving, how much build configuration has to be rebuilt, and how many domains and environments must cut over. Coolify itself is free to self-host under Apache-2.0, so most of the cost is the servers you run it on, the engineering time to rebuild and test, and the ongoing operation afterward. Coolify Cloud, which runs the Coolify control plane for you, is priced at $5 per month for 2 connected servers plus $3 per month for each additional server, with a 20% discount for annual billing, according to Coolify's pricing page. Ask any partner to quote one-time migration work separately from recurring server and operations costs.
How long does a migration from App Platform to Coolify take?
The duration depends on the drivers, not a fixed number: how many app components and databases exist, whether each app already builds from a Dockerfile, how many domains need DNS changes, and how much data must be copied and verified. Apps with a clean Dockerfile and one database usually move faster than apps with many workers, jobs and custom build steps. Coolify's own guide for teams coming from managed platforms is a useful checklist for scoping, and a fixed-scope written plan sets the timeline before work starts.
What does our team need to supply for the migration?
Expect to provide the current App Platform app spec (YAML), access to the source repositories and container registries, environment variable values and secrets, DNS control for each domain, database access for export, and a named owner who can approve cutover windows. You also need one or more Linux servers that meet Coolify's minimum requirements of at least 2 CPU cores, 2 GB RAM and 10 GB of free disk, on amd64 or arm64. Confirm with your team who holds the secrets, because they are the most common blocker.
Can our own engineers do the migration without outside help?
Yes, if the team has Linux, Docker, DNS and PostgreSQL experience and time to test each app. Coolify installs with a single script and connects to servers over SSH, so the platform itself is approachable. The harder parts are rebuilding build settings, moving database data with a tested dump and restore, reproducing health checks, and setting up backups and monitoring. Teams that want a fixed-scope written plan, implementation and handover can ask DeployOpen to scope that work, and we do not publish prices, so the quote follows from the written scope.
What does Coolify not replace from App Platform?
Coolify does not run your servers, patch the operating system, or take responsibility for uptime, so those duties move to your team or a partner. App Platform handles managed builds and container runtime; with Coolify you own capacity planning, server hardening and incident response. Coolify's database backups cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse but not Redis, Dragonfly or KeyDB, so Redis-backed components need a separate recovery plan. Confirm managed database features, such as failover and point-in-time recovery, against your own requirements before cutover.
How does rollback work if a migrated app fails?
Coolify's guide for teams coming from managed platforms notes that a rollback can redeploy a retained application image, but it does not restore databases or persistent files. That means you can return the application code to a previous image quickly, while data changes made after cutover must be handled separately. Plan rollback before cutover by keeping DNS pointed at App Platform until the new app is verified, retaining the last App Platform database snapshot, and deciding which writes can be replayed. Test this path in a staging environment first.
How do we move the PostgreSQL database with minimal downtime?
The safest pattern is to take a dump, restore it into the Coolify-managed PostgreSQL, verify row counts and application behavior, then cut over with a short write freeze. PostgreSQL logical replication works between different major versions, which can keep downtime to several seconds for a major upgrade, according to the PostgreSQL upgrading documentation. Coolify's Import Backup accepts SQL dumps, custom archives, tar archives and all-database dumps. Confirm the source and target major versions first, since PostgreSQL 14 is supported until November 12, 2026, according to the PostgreSQL versioning policy.
How DeployOpen scopes and runs the migration
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including their cloud accounts, data centers or air-gapped networks. For an App Platform move to Coolify, that means the Coolify host, the servers it manages, the database hosts and the DNS and TLS setup all stay under your control from the first day. Most engagements are fixed-scope, so the work starts only after the scope, deliverables and timeline are agreed in writing. Before that, the scope should name each App Platform app and worker, each database and each domain, and confirm who owns the cloud accounts and DNS zones that change during cutover.
A quote follows from the written scope, so the inputs that move the price are the ones to settle first: the number of apps and components in each app spec, the number of databases and their sizes, whether preview deployments are needed, how many servers Coolify will manage and whether backup storage must be S3-compatible. Ask for each of these to be listed as a line item with its own deliverable, so you can see which parts are one-time work (rebuilding builds, moving data, cutover rehearsal, runbooks) and which costs recur (your servers, backup storage, and any retainer). Your own infrastructure costs are paid to your cloud provider, not to DeployOpen, and the scope should say so explicitly.
Ongoing support, upgrades and continuous testing are available as retainers, which suits teams that want someone to own Coolify upgrades, PostgreSQL minor and major upgrades, backup restore tests and patching after the cutover. Ask whether a retainer covers the Coolify host, the application servers, the database or only advisory work, and what the response expectations are in writing. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, so any independent assessment must be arranged with an auditor or certification body. DeployOpen is not an official partner or reseller of Coolify or any other vendor.
