# How to migrate from Railway to your own AWS account > A step-by-step guide to moving an app off Railway: export env vars and data, redeploy the same app on Ownkube Compute, then connect your own AWS with no rewrite and cut over DNS. - **Published:** 2026-09-02 - **Author:** Ownkube team - **Category:** How-To - **Tags:** railway, migration, aws, own-cloud, heroku-alternative - **Canonical URL:** https://ownkube.io/blog/migrate-from-railway-to-your-own-aws - **Cover:** https://ownkube.io/blog/migrate-from-railway-to-your-own-aws.png --- Moving an app off Railway into an AWS account you own sounds like a rewrite, and on most platforms it is. On Ownkube it is two smaller steps that you can take on different days: redeploy the same app on Ownkube Compute first (no cloud account needed), then [connect your own AWS and move the app there with no code changes](/blog/move-app-to-your-own-aws). This guide walks the whole path, from exporting your Railway config to cutting over DNS. **TL;DR** - Decide why you are moving: a customer requirement, compliance, AWS credits, or wanting to keep the app after leaving the platform. - Export your Railway environment variables and take a fresh dump of any managed data (Postgres, volumes). - Redeploy the same container or repo on Ownkube Compute in seconds, no cloud account, and verify it on a temporary hostname. - Optionally connect your own AWS (Starter free, or Production at $5/vCPU + $1/GiB) and move the same app there with no rewrite. - Cut over DNS once the new deployment is healthy, then decommission the Railway service. ## When and why to move You do not have to move just because you can. Move when one of these is true: - **A customer's security team asks where the app runs.** "In our own AWS account" is an answer you can give on Ownkube. On Railway it is not, because the app runs on Railway's infrastructure only. - **Compliance or data-residency** requires the app in an account and region you control. - **You have AWS credits** (Activate or otherwise) you want to apply. On your own cluster there is no platform markup on AWS compute, and Activate credits apply in full. - **You want the app to outlive the platform.** Portability means you can disconnect and your apps keep running. If none of these apply and you are happy on Railway, staying is fine. If the postpaid meter or the credit that does not roll over is the actual pain, you may only need the first half of this guide (Ownkube Compute), which our [Railway alternative post](/blog/railway-alternative-2026) covers as a standalone move. ## Step 1: Export your Railway environment variables Pull the variables from the Railway service you are moving. From the [Railway CLI](https://docs.railway.com/): ```bash # Print the linked service's variables railway variables # Or dump them into a local .env you can re-import railway variables --kv > railway.env ``` Review `railway.env` and drop anything Railway-specific (internal service references, Railway-provided database URLs you will replace). Keep application secrets, third-party API keys, and feature flags. ## Step 2: Take a fresh dump of your data If your app uses a Railway-managed Postgres, take a logical dump before you touch anything. Use the connection string from the Railway dashboard or CLI. ```bash # Dump the Railway Postgres to a local file pg_dump "$RAILWAY_DATABASE_URL" --no-owner --no-privileges -Fc -f railway-db.dump ``` For volumes or uploaded files, copy them down locally or sync them to S3 now, so you have a clean snapshot that is not moving under you during the cutover. ## Step 3: Redeploy the same app on Ownkube Compute This is where the "no rewrite" starts. Ownkube Compute deploys the same container or git repo you already run, with no cloud account, no config, and no card to start. If you deploy from a repo, point Ownkube at it; if you ship a container, give it the image. ```bash # Deploy the current directory (git-push or Dockerfile/image both work) okctl deploy ``` Import the environment variables you exported, then provision a managed Postgres and restore the dump into it: ```bash # Set the app's env vars from the file you cleaned up okctl env set --from-file railway.env # Restore the dump into your new Ownkube-managed Postgres pg_restore --no-owner --no-privileges -d "$OWNKUBE_DATABASE_URL" railway-db.dump ``` Ownkube gives you automatic TLS and an auto-allocated hostname, so you can verify the app end to end on that temporary URL before any DNS change. The managed Postgres runs on a database box from $4/mo plus $0.15 per GB of storage with backups included; add a Valkey cache (from $2/mo) if your app used one. [Metered or a flat box is your choice per deployment](/blog/metered-vs-reserved-pricing), and unused wallet credit rolls over and never expires, so a quiet month is banked rather than burned. At this point you have a working copy of the app on Ownkube-managed compute. Many teams stop here, because it already fixes the postpaid surprise bill. If you need the app in your own AWS, continue. ## Step 4 (optional): Connect your own AWS account The same app you just verified moves into an AWS account you own with no code change. Connect the account, and Ownkube runs the workload there while its logs, metrics, and health checks come with it (the observability follows the app, so you are not flying blind after the move). Our [connect your AWS account guide](/blog/connect-your-aws-account) covers the linking step. Pricing on your own cloud: - **Starter** is free on one AWS instance. You pay AWS directly for the instance ([from about $30/mo](https://aws.amazon.com/ec2/pricing/)), with no platform fee. - **Production** is $5 per vCPU per month plus $1 per GiB of RAM per month, with no markup on AWS compute and AWS Activate credits applied in full. Because it is the same app definition, there is no rewrite: you are changing where it runs, not what it is. If Fly.io rather than Railway is your starting point, the [Fly.io alternative post](/blog/fly-io-alternative-own-aws) walks the own-AWS path from that side. ## Step 5: Cut over DNS and decommission Railway Once the new deployment (on Compute or in your own AWS) is healthy and you have watched it under real traffic on its temporary hostname: 1. Add your custom domain to the Ownkube app (subdomain and apex are both supported) and let TLS provision. 2. Lower the TTL on your DNS records a few hours ahead of the switch so propagation is quick. 3. Point the DNS record at the Ownkube endpoint. 4. Watch logs and metrics until traffic has fully shifted and the Railway service goes quiet. 5. Take a final data dump from Railway as a safety copy, then delete the Railway service so it stops billing. Keep the Railway service paused rather than deleted for a day or two if you want a fast rollback path, then remove it once you are confident. ## FAQ ### Do I have to rewrite my app to move off Railway? No. Ownkube deploys the same container or repo you already run, so redeploying on Ownkube Compute and later moving into your own AWS are configuration steps, not a rewrite. ### Can I move my Railway Postgres data? Yes. Take a logical dump with `pg_dump` from your Railway database, then restore it with `pg_restore` into a managed Postgres on Ownkube. Ownkube's Postgres is single-instance and private in-region today; multi-instance and point-in-time recovery are on the roadmap. ### Do I need an AWS account to leave Railway? No. You can redeploy on Ownkube Compute with no cloud account at all. Connecting your own AWS is an optional later step for when a customer, compliance, or your own credits require it. ### How much does running in my own AWS cost? Starter is free on one AWS instance (you pay AWS for the instance, from about $30/mo). Production is $5 per vCPU per month plus $1 per GiB of RAM per month, with no markup on AWS compute and AWS Activate credits applied in full. ### Will I lose my logs and metrics when I move to my own AWS? No. When the app runs in your own AWS, its logs, metrics, and health checks come with it, so you keep the same observability you had on managed compute. ## Where Ownkube fits Migrating off Railway is two steps you control: redeploy the same app on Ownkube Compute to fix the billing model today, then connect your own AWS with no rewrite when you actually need it. You keep the app portable, the credit you do not spend rolls over, and the observability follows the workload wherever it runs. [Deploy your first app](https://app.ownkube.io/login).