Railway to AWS in an hour.
Fully automated.
One command. An agent reads your repository and your railway.json, then deploys into the AWS account you already own - after you approve the plan.
Teams migrating with Qovery may be eligible for AWS migration credits through our ISV Accelerate partnership.
“We migrated our whole staging environment with a single prompt. Production was a one-click clone of staging. Once the tests gave us confidence we moved DNS off Heroku - we have been running production on our own cloud with Qovery ever since.”
“We liked the Heroku experience, and we knew AWS meant skills and effort we did not have spare - that is why we kept putting the migration off. We do not regret doing it with Qovery. Deployments that took me over two hours now take 30 minutes.”
Railway is the best DX in the category. It is also a ceiling.
The canvas, the templates and the deploy speed are genuinely good, and none of that is what teams leave over. They leave because the workload has outgrown what somebody else’s account can be asked to do.
Four regions, all on Railway’s own metal
- California, Virginia, Amsterdam and Singapore. There is no fifth, and no option to run somewhere your customers or your regulator require. Volumes make this sharper: a volume follows the region of the service it is attached to, so moving a stateful service between regions migrates the volume and takes the service down while it copies. Any commercial AWS region, with multi-region and multi-cluster from one control plane. Storage is not welded to that choice.
Private networking inside a project is not a network you own
- Railway gives services encrypted Wireguard tunnels and internal DNS within a project environment, which is the right design for what Railway is. What it is not is a VPC. There is no security group you write, no peering to the database or the VPN or the internal service you already run elsewhere, and no route table. You already own the VPC. Security groups, PrivateLink endpoints, peering and NAT egress are yours to define, and the three fixed egress IPs are stable for allowlisting.
The plan tier caps the workload itself
- Replica count per service, RAM, vCPU and volume size are all bounded by which plan you are on, so scaling becomes a billing conversation before it is an engineering one. Deploying from a private container registry needs Pro. Egress is metered and billed per gigabyte on top of compute, which penalises exactly the data-heavy services that are hardest to move. Compliance commitments and SLAs live at Enterprise. In your own account none of those are tiers: AWS IAM governs access, CloudTrail records the changes, and the capacity ceiling is whatever quota you ask AWS to raise.
Three steps, then the agent does it.
Your side takes about five minutes. Everything after that is automated.
- 01
A CloudFormation stack provisions the network and an EKS cluster in your own account - about twenty minutes, and nothing leaves your boundary. Qovery gets a role you can read, scope down or revoke. Talk to a migration engineer before you connect anything.
- 02
One command teaches your coding agent how to read the repository - a railway.json, a Dockerfile, a Railpack build, a set of variables - and describe the deployment in Qovery’s own terms. Nothing is deployed at this point. You are only giving the agent the vocabulary.
- 03
The agent detects every service, writes a Dockerfile where one is missing, maps your Railway variables to Qovery variables and secrets, and shows you the plan. You approve it before a single resource is created - and your Railway Postgres stays where it is, connected over the network, so you validate against real data before migrating a byte.
- 04Optional
Take this first or last - some teams want it as step zero, before they connect anything. A Qovery staff solution engineer reviews the cluster setup and environment layout with your team, then goes through the practices that keep the estate cheap and quiet: node sizing and Spot policy, autoscaling thresholds, preview-environment lifetimes, secret scoping and how to promote the same artifact between stages.
- network
- your VPC, three fixed egress IPs
- cluster
- EKS, in your region
- access
- a role scoped to Qovery
Works with any coding agent that reads skills. Nothing is deployed at this point.
web Node.js 20 Dockerfile generated worker Node.js 20 detected from railway.json scheduler cron 2 jobs database PostgreSQL 15 Railway Postgres, connected remotely
Nothing has been created yet. You approve the plan first.
- cluster
- node sizing, Spot policy, autoscaling
- workflow
- stages, approval gates, preview TTLs
- access
- secret scoping, roles per environment
From there it is automatic. Your apps come up running and live on AWS, reachable on a public URL - while the Railway stack keeps serving traffic untouched.
You pay AWS directly. And usage stops being the whole bill.
Railway meters RAM, vCPU and egress and bills you for what you used. That is honest, and it is also the only pricing model on offer - there is no commitment to buy, no reserved capacity, and no cheaper class of compute for work that can be interrupted. As AWS’s own customer, all three exist.
Depends on your replica counts, RAM and vCPU footprint, volume storage, egress volume and region. A migration engineer will model your estate against the equivalent AWS shape before you commit to anything.
Three prices AWS will quote you that a usage meter cannot.
Metered pricing is fair but it is flat: every gigabyte-hour costs the same as the last one, forever. An AWS account you own has more than one price for the same compute.
Savings Plans and Reserved Instances
- Commit to a level of compute for one or three years and the same capacity costs materially less than on-demand. Railway has no commitment tier - the meter runs at the published rate whether you have been there a week or three years. Qovery sizes the node groups; the commitment sits in your account and applies across everything running there.
Spot capacity, and a real split between tiers
- Queue workers, cron jobs and preview environments tolerate interruption. Qovery puts those pools on Spot and keeps web services on on-demand nodes. On Railway a replica of a background worker is metered exactly like a replica of your API, because the platform has no cheaper class of capacity to schedule it onto.
Egress you can architect around
- Railway meters network egress per gigabyte on top of compute, which lands hardest on the media, export and data-heavy services that are already the most expensive to run. In your own account, egress is priced against your agreement and reshaped by the tools AWS gives its customers - CloudFront, VPC endpoints, keeping traffic inside the region - rather than being a fixed line on someone else’s invoice.
Our control plane. Your account, your bill.
Qovery sits above the infrastructure and never owns it. Every cluster, database and bucket is provisioned inside the AWS account you already hold - AWS invoices you directly.
- We do not take a cut of your AWS spend. A flat subscription, whether your bill is $2k or $200k.
- We push it the other way: idle nodes, oversized requests and preview environments left running get flagged so you stop paying for them.
- Railway runs all of this on its own metal. Qovery runs it in yours.
Not sure which AWS services fit your workload? A solution engineer will map it with you.
CONTROL PLANEStop paying Qovery and the stack keeps running - the manifests and qovery/qovery Terraform are already in your account.
Your first service on AWS,
live within the hour.
Any commercial AWS region - not a list of four - with multi-region and multi-cluster from one control plane. Nothing you do here touches your existing Railway project until you decide to move the domain.
Qovery is an AWS ISV Accelerate partner, available on AWS Marketplace. Spend transacts through your existing AWS agreement and counts toward an Enterprise Discount Program commitment.
View on AWS Marketplace →Railway to AWS
Something not covered here? Talk to a migration engineer - they have done this on estates larger than yours.