Which self-hosted PaaS fits your team: Coolify vs Dokploy vs Dokku
Choose Coolify if you want a dashboard-driven platform under Apache-2.0 that manages several servers over SSH. Choose Dokku if you want a single-server, git push PaaS under MIT with buildpacks and plugins. Choose Dokploy if your team accepts source-available enterprise features, because its SSO, SCIM and audit logs sit under a separate license that allows production use only under a commercial agreement. The choice depends on three things: the license terms your legal team will accept, how many servers you will run, and who will operate the platform day to day. Coolify's self-hosted edition is free with all features, and its Coolify Cloud option charges per server while your apps still run on your own machines. Dokku trades multi-server reach for simplicity, and its k3s scheduler still needs a Docker registry and leaves only the initial server as the git push target.
Start by listing your servers and your operators. Coolify needs at least 2 CPU cores, 2 GB RAM and 10 GB of free disk on each Linux host, and it runs one coolify-proxy container per server, so someone must own its routing and certificates. Dokploy needs at least 2 GB of RAM and 30 GB of disk, and its installer sets up Docker Swarm, so a Swarm cluster becomes part of your operating model. Dokku's default docker-local scheduler runs on one host with 1 GB of RAM. Before you commit, check the license file for each Dokploy feature you need, confirm which backup targets your databases require (Coolify and Dokku both support S3-compatible storage for some engines), and confirm with each vendor whether your use case falls inside its terms. Read the Coolify documentation and the Dokku documentation to compare the install steps against your own build pipeline.
Which platform fits which scenario
This table maps five common situations to the platform that fits each one, with the license, server model or scheduler fact that drives the answer. Read each row against your own server count, team shape and whether you need Dokploy's enterprise features without a commercial agreement. The main takeaway is that server model and license terms usually decide the choice before feature lists do.
| Scenario | Best fit | Why |
|---|---|---|
| Solo developer deploying a few apps on one VPS | Dokku or Coolify | Dokku is MIT-licensed and deploys with git push on a single server, while Coolify adds a web dashboard, one-click database services and scheduled backups for PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse. |
| Small team running apps across several servers | Coolify | Coolify connects to each server over SSH and deploys to them under Apache-2.0, and its Coolify Cloud option is priced per server if you prefer not to host the dashboard yourself. |
| Internal platform team wanting a git push workflow | Dokku, with Coolify as the alternative for a dashboard | Dokku's default scheduler runs containers on the Dokku host, and its k3s scheduler is multi-server but only the initial server is the git push target, so confirm that model fits your release process. |
| Team needing SSO, SCIM and audit logs without a commercial agreement | Coolify or Dokku, not Dokploy | Dokploy's SSO with OIDC and SAML, SCIM, audit logs and custom roles sit in source-available /proprietary code that allows production use only under a commercial agreement, so confirm licensing with Dokploy before you depend on them. |
| Team planning to resell hosting to customers | Confirm with each vendor before choosing | Dokploy's terms forbid commercial resale or redistribution as a service without explicit consent, and the Coolify and Dokku licenses should be read by counsel against your resale model before you commit. |
What each license allows and what is paid
Coolify is licensed under Apache-2.0, according to its GitHub repository, and the self-hosted edition is described on its pricing page as free forever with all features and no limitations or restrictions. Nothing in the self-hosted build is withheld behind a paid tier, so the licensing question for most teams is about the Apache-2.0 terms themselves rather than an enterprise feature gate. The paid option is Coolify Cloud, where the control plane runs on Coolify's managed infrastructure while your apps still run on your own servers.
- Self-hosted edition: Free under Apache-2.0, with the full feature set listed on the pricing page.
- Coolify Cloud pricing: $5 per month for 2 connected servers plus $3 per month for each additional server, with a 20% discount for annual billing.
- What the cloud fee buys: Hosting of the Coolify instance itself, not compute for your workloads, which stay on the servers you bring.
- Recurring versus one-time cost: Self-hosting has no license fee, so cost is the server, your staff time and any support contract you choose to sign.
Confirm the current terms on Coolify's pricing page and GitHub repository before a procurement review, and ask whether any future edition changes what the Apache-2.0 build includes.
Dokploy is open core. Its LICENSE.MD applies the Apache License 2.0 to code outside the /proprietary directories, while code inside them falls under the Dokploy Source Available License 1.0. That license allows production use only under a commercial agreement with Dokploy. The proprietary code includes SSO with OIDC and SAML, SCIM, audit logs, custom roles and license key handling, so the identity and audit features many regulated teams ask about are not Apache-2.0 licensed. Separately, its terms forbid commercial resale or redistribution of Dokploy as a service without explicit consent.
- Open-source core: Apache 2.0 for code outside /proprietary, as stated in the LICENSE.MD file.
- Source-available enterprise code: SSO with OIDC and SAML, SCIM, audit logs and custom roles fall under the Dokploy Source Available License 1.0.
- Resale restriction: Commercial resale or redistribution as a service needs explicit consent from the Dokploy team.
- Paid tiers: Hobby at $4.50 per month per server (1 server, 1 organization, 1 user), Startup from $15 per month with up to 3 servers and basic RBAC, and Enterprise, cloud or self-hosted, with SSO/SAML, SCIM, audit logs and an SLA at contact-sales pricing.
Before you rely on any proprietary feature, read LICENSE_PROPRIETARY.md and the terms file with counsel, and confirm in writing whether your internal use and any client-facing use need an agreement.
Dokku is MIT licensed, and the LICENSE file in the dokku/dokku repository carries a 2014 copyright by Jeff Lindsay. The core platform, including its builders, schedulers and plugin model, is available under that permissive grant. Dokku also links to Dokku Pro at pro.dokku.com, a separate offering whose terms were not part of the research for this page, so the licensing and cost of any paid option must be confirmed directly with the vendor.
- Core platform: MIT, with the copyright notice in the LICENSE file of the dokku/dokku repository.
- Official plugins: Plugins such as dokku-postgres are separate projects, so check the license of each plugin you install.
- Dokku Pro: Linked from the project site, but its license, features and pricing are not confirmed here.
- Recurring cost: The software itself has no license fee, so spend goes to the host, staff time and any paid support you arrange.
Ask Dokku Pro for its written terms and confirm the license of every plugin and builder in your stack, including the Heroku buildpack and Cloud Native Buildpacks components, before you standardize on them.
How each platform connects to servers and builds apps
Coolify, Dokploy and Dokku make different assumptions about where your servers sit and how code reaches them, and those assumptions decide how much of the setup you own. Coolify connects to each server over SSH, prepares it to run Docker workloads and then deploys from a Git repository, Dockerfile, Docker Compose file or prebuilt image, with one coolify-proxy container per server handling routing. Dokploy's installer sets up Docker Swarm, uses ports 80 and 443 for Traefik and port 3000 for its web interface, so the first decision is whether your network policy allows that port layout on each node. Dokku takes the opposite shape: it runs on a single host and reacts to git push to a dokku remote. Before you pick one, confirm which of these models your change control and firewall rules can accept, since moving an app later means rebuilding its deployment path.
On build methods, Coolify offers Nixpacks, Railpack (beta), Static, Dockerfile and Docker Compose, plus a Docker Image option that skips the build stage entirely. Dokploy defaults to Nixpacks and also offers Railpack, Dockerfile, Heroku Buildpacks (Heroku 24 by default), Paketo Buildpacks and Static sites served from an NGINX container. Dokku supports herokuish (the v2a buildpack specification), Cloud Native Buildpacks, a Dockerfile, and Nixpacks and Railpack builders selected by nixpacks.toml or railpack.json files. The Cloud Native Buildpacks builder defaults to a stack based on heroku/builder:24 and needs the pack CLI installed separately on the host, a dependency that is easy to miss in a server build script. Test your actual repositories against the builder you intend to standardize on, because a build that works under one pack type may need a different Dockerfile or buildpack setting under another.
The practical check is to map each application's language, runtime and build step to a builder before you commit. A team with mostly Dockerfile-based services gets the same result on all three platforms, while a team relying on Procfiles or Heroku-style buildpacks will find Dokku closest to its existing workflow. Confirm with each vendor which builder versions are current, since Railpack is labeled beta on Coolify and the Dokku and Dokploy documentation describe builder defaults that can change between releases.
Databases, backups, multi-server and previews side by side
This table compares licensing, current versions, host requirements, databases, backups, multi-server layout and preview deployments across Coolify, Dokploy and Dokku. Read each row against your own data stores and server count, and treat cells that say to confirm as open questions for the vendor. Coolify covers the widest set of databases with scheduled backups, while Dokku's default setup is a single server with plugin-based datastores.
| Capability | Coolify | Dokploy | Dokku |
|---|---|---|---|
| License | Apache-2.0 for the self-hosted edition, free with all features and no limitations | Apache 2.0 outside /proprietary folders; SSO, SCIM and audit logs fall under source-available terms | MIT licensed, with a 2014 copyright in the LICENSE file |
| Current version | v4.4.6, released October 9, 2026 | v0.30.8, released September 29, 2026 | v0.38.31, released September 27, 2026; still versioned 0.x |
| Minimum host | At least 2 CPU cores, 2 GB RAM and 10 GB free disk; Linux only, amd64 or arm64 | At least 2 GB RAM and 30 GB disk; confirm the CPU minimum in Dokploy's installation docs | 1 GB RAM for the default docker scheduler; Ubuntu 22.04 to 26.04 or Debian 11 or later |
| Databases deployed | PostgreSQL, MySQL, MariaDB, MongoDB, Redis, Dragonfly, KeyDB and ClickHouse | PostgreSQL, MySQL, MariaDB, MongoDB and Redis | None by default; official plugins add Postgres, MySQL, MariaDB, Redis, Mongo, ClickHouse and others |
| Scheduled backups | Yes for PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse; not Redis, Dragonfly or KeyDB | Automated backups are offered; confirm per-engine coverage in Dokploy's database docs | Plugin-based; the Postgres plugin runs one-off or scheduled backups |
| Backup format and S3 support | PostgreSQL uses pg_dump custom format; S3-compatible upload, cron schedules and retention by count, days or size | Backups go to S3 destinations set in settings; confirm dump formats and retention options | Postgres plugin exports and imports databases and backs up to S3-compatible storage; confirm formats in the plugin README |
| Multi-server model | Connects to each server over SSH and deploys to it; each server runs one coolify-proxy container | Docker Swarm manager and worker nodes; needs a Docker registry; vertical scaling is recommended first | K3s scheduler builds a multi-server cluster and needs a registry; only the initial server is the git push target |
| Preview deployments | Pull or merge requests from GitHub, GitLab, Gitea and Bitbucket; needs wildcard DNS; deleted on close or merge | Confirm supported Git providers, URL pattern and cleanup behavior in Dokploy's preview deployment docs | Confirm preview support and provider options in Dokku's documentation before planning around them |
What drives the running cost of each platform
The license fee is only part of what each platform costs to run. Server count, host sizing, paid tiers, backup storage, DNS and the staff time to keep a fast-moving release current all shape the total. The cards below separate what is paid to a vendor from what your own team pays for, and what to put in a written scope before comparing numbers.
Server count and host sizing
Coolify requires at least 2 CPU cores, 2 GB RAM and 10 GB of free disk for its own host, and each managed server runs a coolify-proxy container. Dokploy requires at least 2 GB of RAM and 30 GB of disk, and Dokku needs 1 GB of RAM for the default Docker scheduler on a single server. Multiply these minimums by the number of hosts you plan to run, then add headroom for your own workloads. Ask any vendor or partner to price the hosts you actually intend to run, not the minimums.
Per-server fees for hosted control planes
Coolify Cloud charges $5 per month for 2 connected servers plus $3 per month for each additional server, with a 20% discount for annual billing, and you still pay your own servers. Dokploy's Hobby plan is $4.50 per month per server for one server, and its Startup plan starts at $15 per month for up to 3 servers. These fees recur every month, so they grow with fleet size. Compare the total across the number of servers you expect in 12 months.
Dokploy enterprise contact-sales pricing
Dokploy's SSO with OIDC and SAML, SCIM, audit logs and an SLA sit in its Enterprise tier, which is priced on request for cloud or self-hosted use. Those features live in the source-available /proprietary directory, so a production deployment that needs them requires a commercial agreement. No public figure is listed, so the cost is set by a sales conversation. Ask for the quote in writing and confirm which features, support terms and server counts it covers before you rely on it.
Backup storage and wildcard DNS
Coolify's scheduled PostgreSQL backups can go to S3-compatible storage, and Dokploy and Dokku also send backups to S3 destinations, so the storage bill is yours in every case. Retention settings by count, days or size decide how fast that bill grows. Coolify's default preview URLs use {{pr_id}}.{{domain}}, which requires wildcard DNS, and that record and its certificate handling are part of your ongoing setup. Ask who owns the bucket, the retention policy and the DNS zone.
Staff time for fast-moving releases
Dokploy is at v0.30.8 and Dokku at v0.38.31, both still in the 0.x series, and Coolify's v4.0.0 is recent, with v5 previewed for scalability. Each platform needs a planned upgrade window, a test of your builds and databases after each release, and a rollback path. These hours recur for as long as the platform runs, whether your team or a partner does the work. Ask any partner for a written scope that states who patches, how often and what happens during an upgrade failure.
How database backups and restores differ across the three
The first decision is which databases each platform will back up for you, because the answer differs and the gaps are easy to miss. Coolify schedules backups for PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse, but not for Redis, Dragonfly or KeyDB. Its PostgreSQL backups use the pg_dump custom format, can be uploaded to S3-compatible storage, run on cron schedules and apply retention by count, days or size. Coolify's Import Backup also accepts PostgreSQL SQL dumps, custom archives, tar archives and all-database dumps, which helps when you move data in from another host. Dokploy offers automated backups to S3 destinations configured in its settings for the databases it deploys, which are Postgres, MySQL, MariaDB, MongoDB and Redis. Confirm in its database documentation exactly which engines and retention options are covered before you rely on them for a given database. Dokku has no managed datastores by default. Backups come from the official plugins, such as dokku-postgres, which runs one-off or scheduled backups to S3-compatible storage and exports and imports databases with postgres:export and postgres:import.
A scheduled backup job is not the same as a recoverable backup. On all three platforms, restore testing stays with your team. Run a restore into a separate host at a set interval, check row counts and application behavior, and record how long it took. Confirm that dumps are copied off the host that runs the database, since a copy kept only on the same server does not protect against losing that server. Set retention in one place that your auditors can read, and make sure it matches the recovery point your business has agreed to. Check whether your backup credentials and bucket policies protect against deletion by a compromised host. For Redis, Dragonfly and KeyDB on Coolify, or Redis on Dokploy if you rely on it as a store of record, plan a separate export or snapshot process and test it the same way.
The operational difference shows up at restore time. Coolify's Import Backup gives you more formats to work with, which helps during migrations, but you still need to confirm that the dump format matches the target version. Dokploy's restore path depends on how its S3 destination is configured, so rehearse it against your own bucket. Dokku's plugin restore runs through the plugin's import command on the host, so the person on call needs shell access and the plugin's documentation at hand. Before you choose, write down the database engines you run, the recovery point and recovery time you need, where copies must live, and who runs the restore test. Ask each vendor or plugin maintainer to confirm those specifics in writing for your version.
How to switch between the three later
This sequence moves an application and its data from one of these platforms to another with a tested restore and a controlled cutover, so the old host can be retired without losing data or breaking routes. Switching cost depends on how much configuration each platform keeps in its own store and which build method each app uses.
Inventory apps, build methods and configuration
Before moving anything, list every app, its build method, its environment variables, its domains, its scheduled jobs and its attached databases on the current platform. Note which build type each app uses, because Coolify's Nixpacks, Railpack, Static, Dockerfile, Docker Compose and Docker Image methods, Dokploy's build types and Dokku's herokuish, Cloud Native Buildpacks, Dockerfile and Nixpacks or Railpack builders do not map one to one. The inventory is done when every app has a row in a shared document that the team has reviewed and signed off.
Export app configuration and secrets
Export the configuration each platform holds for each app, including environment variables, domain mappings and deployment settings, and store secret values in your secrets manager rather than in a file that travels with the migration. Platform-held configuration is the main source of switching cost, so record anything that exists only in the dashboard or in the platform's database. The export is complete when a second engineer can rebuild each app's settings from your records alone.
Dump and verify each database
Take a dump of each database from the current platform using its native tooling or the platform's backup feature, then confirm the file format is one the target can import. Coolify's PostgreSQL backups use the pg_dump custom format, Dokku's dokku-postgres plugin exports and imports with its own commands, and Dokploy's backups go to S3 destinations configured in its settings, so check each format before you rely on it. Redis, Dragonfly and KeyDB data in Coolify is not covered by its scheduled backups, so plan a separate export for those. The step is done when every dump has a recorded checksum and a stored copy outside the old host.
Test restores on the new platform
Stand up the target platform on a separate server and restore each database and deploy each app from its build method there, without pointing production traffic at it. Run the application's health checks and a representative set of functional tests against the restored copy, and record any build failures, missing variables or database version differences. Confirm the target platform's minimum server requirements before provisioning, since the three platforms set different floors for RAM, disk and operating systems. The step is done when each app runs on the new platform with restored data and the team has a written list of the fixes it needed.
Map build types and environment variables
Translate each app's build definition to the target's equivalent, such as a Procfile or app.json for Dokku, a Nixpacks or Dockerfile setting in Coolify, or a build type selection in Dokploy, and adjust any buildpack-specific assumptions. Recheck variable names and scopes, because a variable that resolves at build time on one platform may need to move to runtime on another. Apps built with a Dockerfile usually carry over with the fewest changes, while buildpack-based apps are where most differences appear. The step is done when a rebuild from the same commit on the target produces an image or artifact the team has tested.
Move DNS and TLS during a planned window
Lower the time-to-live on DNS records ahead of the cutover, point each domain at the new platform, and confirm that certificates are issued for every hostname. Check how the target handles HTTPS, since Coolify uses Traefik or Caddy by default, Dokploy runs Traefik on ports 80 and 443, and Dokku's proxy is configured through its own proxy management. Keep the old host running and reachable during the window so you can roll back by reverting DNS. The step is done when every hostname resolves to the new platform, serves a valid certificate and passes the checks from the inventory.
Retire the old host after verification
After the new platform has served production traffic through an agreed observation period, remove scheduled jobs and webhooks that still point at the old host, revoke deploy keys and API tokens it used, and confirm that no preview or Git integration still triggers builds there. Keep the final database dumps and the configuration export in your retention store for the period your own policy requires, then decommission the server and its backups. The step is done when the old host has no active routes, credentials or schedules and the archive has been checked for restorability.
Questions teams ask before choosing a self-hosted PaaS
Which self-hosted PaaS is free to run in production?
Coolify and Dokku are both free to run in production, while Dokploy is free only for its Apache-2.0 code. Coolify is licensed under Apache-2.0, and its pricing page describes the self-hosted edition as free forever with all features and no limitations. Dokku is MIT licensed. Dokploy applies Apache License 2.0 to code outside its /proprietary directories, but code inside them falls under the Dokploy Source Available License 1.0, which allows production use only under a commercial agreement. Those directories include SSO, SCIM, audit logs and custom roles, so a team that needs those features in production should read the Dokploy license terms and confirm commercial terms before choosing it.
What do the paid Dokploy and Coolify Cloud tiers add?
The paid tiers mainly add a hosted control plane and, for Dokploy, enterprise identity and audit features. Coolify Cloud costs $5 per month for 2 connected servers plus $3 per month for each additional server, with a 20% discount for annual billing. Customers bring their own servers, while the Coolify instance runs on Coolify's managed infrastructure. Dokploy lists Hobby at $4.50 per month per server for 1 server, 1 organization and 1 user, and Startup from $15 per month with up to 3 servers and basic RBAC. Its Enterprise tier, cloud or self-hosted, adds SSO/SAML, SCIM, audit logs and an SLA at contact-sales pricing. Confirm whether the Dokploy list prices apply to your deployment model, and ask what happens to your data and upgrades if you leave a paid tier.
How much ongoing work does each platform need to run and upgrade?
Ongoing work depends on how many servers you run, how many datastores you host and how often you upgrade the control plane. Coolify installs with a single script and needs at least 2 CPU cores, 2 GB RAM and 10 GB of free disk. It runs one coolify-proxy container on each server, so every added server adds a proxy to keep current. Dokploy needs at least 2 GB RAM and 30 GB of disk, its installer sets up Docker Swarm, and clusters need a Docker registry to distribute images. Dokku runs on a single server with 1 GB RAM for the default Docker scheduler, but it is still versioned 0.x, and each plugin you add, such as Postgres, is another component to update and back up. Ask each vendor for its upgrade notes and deprecation policy, and schedule a test upgrade on a staging copy before production.
Can one developer run Dokku or Coolify alone?
Often yes for a small fleet, but the answer depends on how many servers, apps and stateful services sit behind the platform, and whether one person can cover patching and restores. Dokku suits a single developer well because it runs on one server, deploys with git push to a dokku remote and creates apps on the fly. Its operating surface is the host, the Dokku install and the plugins you choose. Coolify also works for one person managing a handful of servers, since its dashboard connects to each server over SSH. Each added server and each database, however, adds monitoring, certificate and backup duties. Ask who holds the SSH keys, who receives alerts, who owns restores and who covers an outage. If one person cannot answer all of those, plan a second operator before launch.
How should database backups be tested before relying on them?
Test restores on a separate host from the backup files, and do not treat a successful backup job as proof of recoverability. Coolify runs scheduled backups for PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse, and its PostgreSQL backups use the pg_dump custom format with S3-compatible upload and retention by count, days or size. It does not schedule backups for Redis, Dragonfly or KeyDB. Dokku's dokku-postgres plugin exports and imports databases and runs one-off or scheduled backups to S3-compatible storage. Dokploy offers automated backups to S3 destinations configured in its settings, so confirm which of its database types each covers. Build a restore drill: pick a backup, restore it into an isolated environment, run the application's checks, record the elapsed time and data loss window, and repeat on a schedule. Also confirm that retention keeps a restore point old enough for your recovery needs.
How can a team add SSO to Dokploy without a commercial agreement?
Under the supplied license terms, you cannot use Dokploy's proprietary SSO code in production without a commercial agreement, so the practical options are the Enterprise tier, a written question to Dokploy about whether any other arrangement exists, or a different platform whose identity features you have verified. Dokploy's OIDC and SAML SSO, SCIM, audit logs and custom roles sit in the proprietary directories. Do not copy that code into Apache-2.0 sections or remove license notices to work around the terms, since that breaks the license. Coolify is Apache-2.0 and its pricing page lists all self-hosted features without restriction, but the supplied facts do not confirm its SSO support, so verify it in Coolify's documentation before you rely on it. Server access controls, such as SSH key management and reverse proxy restrictions, remain your responsibility on any of these platforms.
Can a team resell hosting built on these platforms?
Dokploy's terms forbid it without consent, while Coolify and Dokku carry permissive licenses, but any resale plan needs a license review before launch. Dokploy's terms call its core free and open source but state that commercial resale or redistribution of Dokploy as a service is forbidden without explicit consent from the Dokploy team. Coolify's repository is Apache-2.0 and Dokku's is MIT, and both are commonly read as permitting this use, subject to their notice requirements. Coolify Cloud is Coolify's own hosted service, and the supplied facts do not describe a reseller program for it. Have counsel review each license and the notices you must ship before selling hosting to customers. Resale also adds support, uptime and data handling obligations that belong in your customer contracts and cost model.
What should a fixed-scope quote from a partner include?
A fixed-scope quote should list the scope, deliverables, exclusions, acceptance steps and timelines, all agreed in writing before work starts. DeployOpen works this way for most engagements, and a quote follows from the written scope, since it does not publish a price list. Ask the partner to state:
- Which platforms, versions, licenses and license conditions are in scope
- Server count, sizing and who provisions and patches the hosts
- Backup targets, the restore test method and how often restores are tested
- The upgrade and rollback plan, including staging tests and who runs them
- Documentation, handover and hardening steps, with named deliverables
- Whether support or a retainer is needed after go-live, and its terms
Also ask what is excluded, such as licensing decisions or legal review of resale terms, and what your team must supply.
How DeployOpen helps you choose and run a self-hosted PaaS
DeployOpen plans, implements, customizes, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Coolify vs Dokploy vs Dokku, we start by confirming which license terms, build methods and database backup needs matter for your team before any platform is installed.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We confirm which license limits matter for your use, including source-available enterprise features and resale terms.
- We map your applications, databases, backup targets and preview needs to the platform that fits them.
How we build
- We prepare servers to the platform's documented minimums, including RAM, disk and supported operating systems.
- We configure build methods, database backups to S3-compatible storage and restore tests for your data stores.
- We test preview deployment DNS, routing and TLS and verify multi-server access over SSH where you need it.
How we hand over
- You receive documentation of the configuration, access model, backup schedules and the operational tasks your team owns.
- We walk your platform team through deployments, restores, upgrades and rollback steps in your own environment.
- We document which features depend on a paid edition or commercial agreement, so ownership decisions are recorded.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover platform upgrades, backup verification and security testing of the apps you deploy.
- Quotes follow from the written scope, so ask us to itemize one-time setup against recurring support work.
