Railway or Dokploy: which fits your team's operating model
If your bill for Railway is hard to forecast or your data must stay in a location you choose, the decision comes down to who operates the platform. Railway fits teams that want managed regions, little operations time, and usage-based billing they can accept. Railway charges a plan fee plus per-second CPU, memory, storage and egress, so cost moves with traffic and resource use. You keep the platform vendor responsible for hosts, upgrades and most incidents, and you trade predictability and location control for that convenience. Confirm the current regions and rates on Railway's own pricing page before you model spend, because usage rates change and a forecast built on last quarter's numbers can drift.
Dokploy fits teams that want servers the organization controls, backups it configures, and a team that owns patching. Dokploy installs on servers you rent or host, and its installer sets up Docker Swarm with Traefik on ports 80 and 443 and the web interface on port 3000. It deploys Postgres, MySQL, MariaDB, MongoDB and Redis, and it can send automated database backups to S3 destinations you configure. Your cost becomes the server bill plus the time your engineers spend on upgrades, monitoring and restores. Check the host requirements in Dokploy's installation docs (at least 2 GB of RAM and 30 GB of disk) against the workloads you plan to run, and confirm which supported operating system versions your standard image uses. The decision turns on three questions. First, data location: if the database and backups must sit in a specific jurisdiction, you need a host and S3 target there, which Railway's managed regions may not offer for your case. Second, who carries incidents: with Dokploy, the on-call rota, restore tests and security response belong to you or your contracted partner. Third, which tier features you need: Dokploy's core is open source, but SSO with OIDC or SAML, SCIM, audit logs and custom roles sit in proprietary code under a commercial agreement, and Startup and Enterprise plans carry the team controls and SLA. List those features now and check them against the current pricing page before you choose.
Which option fits each scenario
This table maps common situations to the option that usually fits better and the condition that drives the choice. Read each row against your own constraints, since the conditions, not the team size alone, decide the fit. The main takeaway is that Dokploy shifts patching, backups and incident response onto your team, so it suits teams that want control over servers and data location.
| Scenario | Better fit | Condition that drives it |
|---|---|---|
| A small team shipping one web app with a managed database | Railway | You want usage billing and no server administration, and you accept that the platform runs the infrastructure. |
| A team with a data residency rule requiring a specific country or provider | Dokploy on servers you choose | The rule must name the location of servers, databases and backups, and you need to confirm the regions Railway offers against that rule. |
| A team needing SSO with SAML or OIDC, SCIM and audit logs | Confirm with both vendors | Dokploy's SSO, SCIM, audit logs and custom roles sit in source-available code under a commercial agreement, so check the Dokploy pricing tier and license terms before planning. |
| A team with a spiky workload and variable traffic | Railway | Usage billing per second for CPU, memory and egress suits spiky demand, while a Dokploy server is paid whether or not it is busy. |
| A team that already runs and patches its own servers | Dokploy | Your operators already own patching, monitoring and backups, so Dokploy adds a deployment layer without a new operating model. |
| A team that needs Docker Swarm clusters or remote build servers | Dokploy | Dokploy documents Swarm-based clusters and remote servers, and you must plan the registry and scaling configuration yourself. |
| A team that must keep source code and deploy tooling inside its own network | Dokploy on servers you control | Self-hosting keeps control in your environment, but you also own access reviews, logging and recovery. |
How Dokploy's build types compare with Railway's build path
Railway builds services with its own Railpack or Dockerfile path, while Dokploy lets you pick the build type per application on your own server. The choice affects whether your build output stays the same when you move, so each card below names a build type, when it matters, and what to verify with a test deploy.
Nixpacks as the default
Nixpacks is Dokploy's default build type, so a new application gets it unless you change the setting. It detects the language and produces an image without a Dockerfile, which suits a quick move from Railway when your service has no custom system packages. Check that detected start commands, Node or Python versions and environment variables match what Railway built. Compare the image output of one test deploy rather than assuming the defaults line up.
Railpack for a Railway-like path
Railpack is the build type closest in spirit to what Railway uses, so teams already on Railway often expect the same detection behavior. Confirm which Railpack version Dokploy ships on your server, because detection rules change between releases. Run a test deploy of your own app and compare the build logs, the installed runtime and the start command against your current Railway deployment before you cut over.
Dockerfile as source of truth
A Dockerfile is the strongest choice when you need the build to be reproducible outside any platform. It keeps base images, system packages and build steps in your repository, so a move between Railway and Dokploy changes only where the image runs. Check that build arguments and secrets are passed the same way, and that the final image runs as the process Railway started, including any pre-deploy steps you previously defined.
Heroku and Paketo buildpacks
Heroku Buildpacks and Paketo Buildpacks suit teams with a standard stack who want buildpack-maintained base images and fewer custom build files. Heroku Buildpacks default to Heroku 24 in Dokploy, so confirm the stack version matches your runtime needs. Paketo buildpacks are maintained by the Paketo project, so review which runtime versions they pin and test a deploy of your application to confirm the output.
Static sites on NGINX
The Static build type serves prebuilt files from an NGINX container, which fits frontends that Railway would otherwise serve as static output. Check that redirects, cache headers and single-page app fallback rules are written into the NGINX configuration, because Railway's routing behavior may not carry over unchanged. Compare the served pages from a test deploy against the live Railway site, including 404 handling and asset paths.
Capabilities side by side
This table compares how Railway's managed service and Dokploy on servers you rent handle builds, databases, clustering, team access and operations. Read the Dokploy column as documented behavior, and confirm Railway's current feature set on Railway's own documentation before deciding. The main takeaway is that Dokploy moves patching, backups and incident response to your team, and its enterprise access features sit under a commercial license.
| Capability | Railway | Dokploy on your servers |
|---|---|---|
| Build types | Managed builds from Git. Confirm supported builders in Railway's docs | Nixpacks (default), Railpack, Dockerfile, Heroku and Paketo buildpacks, static sites on NGINX |
| Databases and S3 backups | Managed database services. Confirm backup options and retention in Railway's docs | Postgres, MySQL, MariaDB, MongoDB and Redis, with automated backups to S3 destinations you configure |
| Clustering and registry | Platform-managed. No cluster or image registry for you to run | Docker Swarm managers and workers. A Docker registry is needed to distribute images. Scale vertically first |
| Remote build servers | Managed build infrastructure. Confirm options in Railway's docs | Remote servers are documented. Confirm your build-server layout in Dokploy's remote servers docs |
| Preview deployments | Confirm current pull request environment support in Railway's docs | Preview deployments are documented. Confirm the setup against your Git provider |
| Team roles and SSO | Confirm roles and SSO availability on Railway's plan page | Basic RBAC on Startup. SSO/SAML, SCIM, audit logs and custom roles on Enterprise, under a source-available license |
| Pricing model | Plan fee plus per-second usage for CPU, memory, storage and egress | Hobby at $4.50 per server per month, Startup from $15 per month for up to 3 servers (Dokploy pricing page), Enterprise by quote |
| Patching and incident response | Platform operator runs the infrastructure. Confirm support and SLA terms in your contract | Your team patches the host OS, Docker and Dokploy. Enterprise lists an SLA on contact-sales terms |
What Dokploy's open-core license allows and restricts
Dokploy is open core, and the license split decides what your team can run without a commercial agreement. The core outside the proprietary directories is Apache License 2.0, which permits use, modification and redistribution under standard terms. The code inside the /proprietary directories falls under the Dokploy Source Available License 1.0, which allows production use only under a commercial agreement with Dokploy. The split is set out in the repository's LICENSE.MD file, and the proprietary terms are in its companion license file.
The proprietary code covers the features most enterprise buyers ask for: SSO with OIDC and SAML, SCIM provisioning, audit logs, custom roles and license key handling. If your team needs any of these, treat them as commercial features with a contract attached, not as Apache 2.0 software you can keep running indefinitely at no cost. Confirm with Dokploy which edition or agreement covers production use of each feature you plan to depend on, and whether a self-hosted Enterprise deployment is priced separately. Also check which identity and audit controls you would otherwise need to build around Dokploy if that agreement is not signed.
The terms also forbid commercial resale or redistribution of Dokploy as a service without explicit consent from the Dokploy team, which matters if you plan to host apps for customers or other business units under a charge. Internal use by your own organization is the scenario the core terms describe most directly, but the boundary between internal and external use is a legal question. Have counsel review the license files, the terms and conditions, and any order form before you build a service model on Dokploy.
Data location, hosting models and compliance implications
Moving from Railway to Dokploy changes where data sits, who runs the servers and which controls you must evidence yourself. The cards below cover each of these in turn so you can map them to your own regulatory and contractual obligations before you choose a path.
Where data and builds run
On Railway, builds and running services execute on the provider's infrastructure in the regions it offers, and you have limited say over the exact facility. With Dokploy, the application, its databases and the Traefik proxy run on servers you rent, and builds run on the host or on remote build servers you add. Confirm which country each server is in, where the Docker registry stores images, and whether build logs or source snapshots leave that environment during deployment.
Who holds the servers
Railway's operations team runs the underlying platform, so hardware, host patching and platform availability are the provider's duty under its terms. With Dokploy, you or your hosting provider own the machines, the operating system, Docker and the Dokploy upgrade cycle. Your contract with that hosting provider should state who applies security updates, who restores a failed host and how long incidents may take to escalate. Write these responsibilities into a runbook before cutover.
Identity and access by edition
Dokploy's Hobby plan is listed for one user and one organization, and Startup adds up to three servers with basic role-based access control. SSO with OIDC and SAML, and SCIM provisioning, are listed on the Enterprise tier at contact-sales pricing. Check whether your identity provider is the source of truth for administrator accounts, and confirm which Railway plan includes SSO and SCIM so the comparison covers the same control set on both sides.
Logs and audit trails
Dokploy's audit logs sit in the proprietary part of its repository, so they are not part of the Apache 2.0 core. If your evidence plan depends on administrator action logs, plan for the commercial tier or record deployments, configuration changes and access in your own system. Container stdout, Traefik access logs and host authentication logs stay on your servers unless you ship them. Set a retention period that matches your policy and test that you can search those logs during an investigation.
Licensing limits on hosting
Dokploy's core is Apache 2.0, but code in the proprietary directories is governed by the Dokploy Source Available License, which permits production use only under a commercial agreement. The terms also forbid commercial resale or redistribution of Dokploy as a service without consent. Your legal team should confirm whether running Dokploy for internal teams, for a client, or inside a product falls within those limits before you rely on its enterprise features.
Compliance evidence you produce
Moving to self-hosting makes your team the source of evidence for access reviews, backup restore tests, patch records, change approvals and network configuration. Railway's own compliance documents cover its platform, but they do not cover your Dokploy servers. DeployOpen can plan, configure and document these controls and prepare evidence for an assessment. It does not issue audit reports, attestations or certifications, which independent auditors and certification bodies provide.
What Railway's usage billing and rented servers each cost you to run
Railway's bill is a plan fee plus per-second charges for CPU, memory, storage and egress on each service, so the monthly total moves with traffic, the size of persistent volumes and the number of services you leave running. Ask Railway for the current rates that apply to your plan, then price your own service list rather than a sample app. Recurring cost comes from every running service, including staging copies, background workers and databases. Egress needs particular attention for apps that serve large files or media, and storing backups as volumes inside the platform adds storage that keeps billing after the data is no longer needed.
Dokploy's core is free and open source under Apache 2.0 outside its proprietary directories, so the software carries no license fee for the core features. The published paid options are 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 at contact-sales pricing with SSO/SAML, SCIM, audit logs and an SLA. Check current Dokploy pricing directly before budgeting. Your largest recurring line is the rented servers, since Dokploy needs at least 2 GB of RAM and 30 GB of disk, and clusters add nodes. S3 storage for database backups is billed by your storage provider, and production use of the proprietary features requires a commercial agreement with Dokploy.
One-time costs are the migration, server build, hardening, restore tests for backups and the cutover of domains and data. Recurring costs are servers, S3 storage, any Dokploy tier you choose, monitoring, operating system and Dokploy upgrades, and on-call time for incidents that Railway would otherwise handle. Staff time is often the largest line and the hardest to see on an invoice, so estimate hours for patching, backup verification and after-hours response with your own team. When you request a quote from any implementation partner, ask for a written scope that lists server sizes, backup retention, monitoring, support hours and upgrades as separate items, so you can compare the total with your current Railway usage for the same services.
What moving from Railway to Dokploy involves
The sequence moves each Railway service, volume and database onto a Dokploy server you run, with backups verified before any domain changes hands. The end state is a working copy of the stack with a tested way back and a clear list of Railway resources to retire.
Inventory services, volumes and databases
List every Railway service, its build source, start and pre-deploy commands, environment variables, cron jobs, attached volumes, custom domains and database plugins. Record which items hold state, since Railway's configuration does not carry data across. Confirm with your team which services are production, which are staging and who owns each one. The output is a written inventory that another engineer could use to rebuild the stack without access to the Railway dashboard.
Choose a build type for each service
Dokploy offers Nixpacks (the default), Railpack, Dockerfile, Heroku Buildpacks, Paketo Buildpacks and static sites served from an NGINX container. Match each service to the option that reproduces its current build most closely, and prefer a Dockerfile where the existing build depends on platform-specific behavior. Check which build type your Railway services use today, because a different builder can change image contents and runtime behavior. The output is a per-service build decision you can review before anything is deployed.
Rebuild services on a Dokploy staging server
Create the applications on a staging Dokploy server, with the server sized to Dokploy's documented minimums of 2 GB of RAM and 30 GB of disk, or more if your workloads need it. Set environment variables from the inventory, not from copies of Railway's dashboard values, and confirm that the build runs from a clean state. Your team, not DeployOpen by default, runs these steps unless the written scope says otherwise. The output is a staging deployment for each service that starts and passes its health checks.
Export and restore databases with backups verified
Export each Railway database and volume, then restore it into a Dokploy database service. Dokploy deploys Postgres, MySQL, MariaDB, MongoDB and Redis and can send automated backups to S3 destinations configured in its settings, so confirm that an S3 target exists and that a restore from it works. Coolify's guidance for teams leaving managed platforms notes that a rollback can redeploy an application image but does not restore databases or persistent files, so treat a verified backup as the only recovery point for data. The output is a restored database whose row counts and schema match the source, plus a tested backup restore.
Test the staging stack end to end
Run application tests, smoke tests and any scheduled jobs against the restored staging data. Check authentication, outbound email, webhooks and third-party callbacks, since these often use Railway-issued hostnames or IP assumptions. Confirm logs, restarts and resource limits behave as expected under realistic load for your environment. The output is a signed-off test record with known failures listed and owned.
Cut over domains and TLS
Lower DNS record TTLs ahead of the change, point each production domain at the Dokploy server, and confirm that Traefik issues and serves certificates for every hostname. Dokploy's installer uses ports 80 and 443 for Traefik, so confirm that these ports are open and that no other service holds them. Freeze writes to the Railway database during the final data sync, then repeat the restore if needed. The output is production traffic served from Dokploy with valid certificates on every domain.
Retire Railway resources after a settling period
Keep the Railway services and their data for a period your team agrees in advance, so that a rollback path remains available. Once the period ends and no traffic or jobs reach Railway, remove services, volumes and databases, and cancel plan billing. Confirm with your finance team which Railway charges end when services are deleted and which continue. The output is a closed Railway account, a documented decommission record and a retained archive of final backups.
What buyers ask before choosing Dokploy over Railway
How much effort does it take to self-host Dokploy instead of Railway?
Expect a server setup and a learning curve, not a single install. Dokploy's installer sets up Docker Swarm, uses ports 80 and 443 for Traefik and port 3000 for the web interface, and needs at least 2 GB of RAM and 30 GB of disk according to Dokploy's installation docs. Effort then depends on how many services you move, how many databases need backups, and whether your team already runs Linux servers, Docker and TLS certificates. Railway handles those layers for you, so the difference is the work you take on. Confirm sizing for your own workload before you pick a server plan, because the minimum is a floor, not a recommendation.
Can a small team run Dokploy alone after the move?
A small team can run it, but only if someone owns the servers, backups and upgrades. Dokploy's documented path covers deploying apps from Git, Dockerfiles or buildpacks, deploying Postgres, MySQL, MariaDB, MongoDB and Redis, and sending database backups to S3 destinations you configure. Each of those is a recurring task: checking that backups restore, applying operating system patches, updating Dokploy and watching disk and memory. Name a primary and a backup owner before cutover, and write down the restore test you will run each month. If nobody has time for that work, the ownership question matters more than the software.
What does outside help cover, and what does it need from our team?
Outside help is scoped in writing before work starts, so the deliverables and the client inputs are both listed in that document. DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted platforms in your own cloud accounts or data centers. Ongoing support and upgrades are available as retainers. From your side, expect to provide server access, DNS control, a list of services and their dependencies, access to the current Railway environment variables and a sign-off owner for cutover. A quote follows from that scope, and DeployOpen does not publish a price list.
How long does a move from Railway to Dokploy take, and what drives it?
The timeline depends on the service inventory, not on Dokploy alone. The main drivers are the number of services, the size of each database and volume, how many domains must cut over, and whether builds need a Dockerfile, Nixpacks, Railpack or buildpack configuration changes. Stateful services take longest because the data must be dumped, moved and verified. Moving a service that uses a Railway volume between regions also means downtime, so plan a maintenance window. No duration is promised here. Ask for a timeline in the written scope that lists each service and its cutover step.
Do we need Dokploy's Enterprise features such as SSO, SCIM and audit logs?
Only if your policy requires them. Dokploy's core is under Apache 2.0 outside its /proprietary directories, but the enterprise features in those directories, including SSO with OIDC and SAML, SCIM, audit logs, custom roles and license key handling, fall under the Dokploy Source Available License 1.0. That license allows production use only under a commercial agreement with Dokploy. Dokploy's pricing page lists Enterprise at contact-sales pricing with SSO/SAML, SCIM, audit logs and an SLA. Ask Dokploy for the current terms in writing, and have your legal and security teams review the license files before you depend on any of those features.
Who handles incidents and patching on rented servers?
You do, unless a separate written agreement assigns that work to someone else. On Railway, the provider runs the platform underneath your services. On rented servers, the operating system, Docker, Dokploy, the reverse proxy and each database are your responsibility to patch, monitor and restore. Dokploy's own documentation covers installation and operation, but it does not take over your incident response. Define who gets paged, what counts as an incident, how you restore from S3 backups and who communicates with users. Outside support can cover some of that through a retainer, which should be stated in the scope.
Is Dokploy's Docker Swarm cluster a good replacement for Railway's scaling?
Dokploy clusters use Docker Swarm manager and worker nodes and need a Docker registry to distribute images. Dokploy's docs recommend vertical scaling first because horizontal scaling needs more configuration. That makes it suitable when a larger single server or a few remote build servers will do, but it is not an automatic equivalent to a managed autoscaler. Confirm your traffic pattern, failover needs and registry hosting before you assume parity. Test a node failure on a non-production cluster so you know how your services behave.
How DeployOpen helps you evaluate, implement and run Dokploy
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For Railway vs Dokploy, we start with the written scope of your services, databases, servers and licensing questions, then build and document the environment you choose.
How we scope
- Inventory your Railway services, databases, volumes, domains and monthly usage before choosing a server layout
- Confirm which Dokploy features you need, including whether SSO, SCIM, audit logs or custom roles fall under the proprietary license
- Agree deliverables, timelines and responsibilities in writing before work starts, since most engagements are fixed-scope
How we build
- Set up Dokploy on rented servers that meet its documented RAM, disk and supported operating system requirements
- Configure build types, S3 backup destinations and database backups, then test restores rather than assuming backups work
- Document Docker Swarm or remote build server choices, reverse proxy settings and any security testing performed before cutover
How we hand over
- Deliver runbooks for deployments, rollbacks, backup restores, server patching and Dokploy upgrades
- Walk your platform and security teams through access controls, secrets handling and incident contacts
- Provide compliance-ready documentation and evidence for your own auditors, noting that DeployOpen does not issue audit reports or certifications
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover
- Retainer scope covers patching, Dokploy version upgrades, backup verification and incident response agreed in advance
- Ask for a written quote that lists which operating responsibilities stay with your team and which move to DeployOpen
