Railway vs. Heroku

At a high level, both Railway and Heroku can be used to deploy your app. Both platforms share many similarities:

• You can deploy your app from a Docker image or by importing your app’s source code from GitHub.
• Services are deployed to a long-running server.
• Connect your GitHub repository for automatic builds and deployments on code pushes.
• Create isolated preview environments for every pull request.
• Support for instant rollbacks.
• Integrated metrics and logs.
• Define Infrastructure-as-Code (IaC).
• Command-line-interface (CLI) to manage resources.
• Integrated build pipeline with the ability to define pre-deploy command.
• Custom domains with fully managed TLS.
• Run arbitrary commands against deployed services (SSH)

That said, there are some differences between the platforms that might make Railway a better fit for you.

Scaling strategies

Heroku

Heroku follows a traditional, instance-based model. Each instance has a set of allocated compute resources (memory and CPU).

In the scenario where your deployed service needs more resources, you can either scale:

• Vertically: you will need to manually upgrade to a large instance size to unlock more compute resources.
• Horizontally: your workload will be distributed across multiple running instances. You can either:
  • Manually specify the machine count.
  • Autoscale by defining a minimum and maximum instance count. The number of running instances will increase/decrease based on a target CPU and/or memory utilization you specify.

The main drawback of this setup is that it requires manual developer intervention. Either by:

• Manually changing instance sizes/running instance count
• Manually adjusting thresholds because you can get into situations where your service scales up for spikes but doesn’t scale down quickly enough, leaving you paying for unused resources.

Beyond scaling, there are other notable limitations. Heroku doesn’t natively support multi-region deployments. To achieve that, you must create separate instances in different regions and set up an external load balancer to route traffic appropriately.

Furthermore, services deployed to the platform do not offer persistent data storage. Any data written to the local filesystem is ephemeral and will be lost upon redeployment, meaning you'll need to integrate with external storage solutions if your application requires data durability.

Railway

Railway automatically manages compute resources for you. Your deployed services can scale up or down based on incoming workload without manual configuration of metrics/thresholds or picking instance sizes. Each plan includes defined CPU and memory limits that apply to your services.

You can scale horizontally by deploying multiple replicas of your service. Railway automatically distributes public traffic randomly across replicas within each region. Each replica runs with the full resource limits of your plan.

For example, if you're on the Pro plan, each replica gets 32 vCPU and 32 GB RAM. So, deploying 3 replicas gives your service a combined capacity of 96 vCPU and 96 GB RAM.

Total resources = number of replicas × maximum compute allocation per replica

Replicas can be placed in different geographical locations for multi-region deployments. The platform automatically routes public traffic to the nearest region, then randomly distributes requests among the available replicas within that region. No need to define compute usage thresholds.

You can also set services to start on a schedule using a crontab expression. This lets you run scripts at specific times and only pay for the time they’re running.

Pricing

Heroku

Heroku follows a traditional, instance-based pricing. You select the amount of compute resources you need from a list of instance sizes where each one has a fixed monthly price.

While this model gives you predictable pricing, the main drawback is you end up in one of two situations:

• Under-provisioning: your deployed service doesn’t have enough compute resources which will lead to failed requests.
• Over-provisioning: your deployed service will have extra unused resources that you’re overpaying for every month.

Enabling horizontal autoscaling can help with optimizing costs, but the trade-off will be needing to figure out the right amount of thresholds instead.

Additionally, Heroku runs on AWS, so the unit economics of the business need to be high to offset the cost of the underlying infrastructure. Those extra costs are then passed down to you as the user, so you end up paying extra for:

• Unlocking additional features (e.g. private networking is a paid enterprise add-on)
• Pay extra for resources (e.g., bandwidth, memory, CPU and storage).

Railway

Railway automatically scales your infrastructure up or down based on workload demands, adapting in real time without any manual intervention. This makes it possible to offer a usage-based pricing model that depends on active compute time and the amount of resources it consumes. You only pay for what your deployed services use.

Active compute time x compute size (memory and CPU)

You don’t need to think about instance sizes or manually configure them. All deployed services scale automatically.

If you spin up multiple replicas for a given service, you’ll only be charged for the active compute time for each replica.

Finally, Railway’s infrastructure runs on hardware that’s owned and operated in data centers across the globe. This means you’re not going to be overcharged for resources.

Dashboard experience

Heroku

However, Heroku’s unit of deployment is the app, and each app is deployed independently. If you have a different infrastructure components (e.g. API, frontend, background workers, etc.) they will be treated as independent entities. There is no top‑level “project” object that groups related apps.

Additionally, Heroku does not support shared environment variables across apps. Each deployed app has its own isolated set of variables, making it harder to manage secrets or config values shared across multiple services.

Finally, Heroku lacks support for wildcard domains, a common feature for multi-tenant or custom-subdomain applications. You’ll need to manually configure each subdomain, which adds operational overhead.

Railway

Railway’s dashboard offers a real-time collaborative canvas where you can view all of your running services and databases at a glance. You can group the different infrastructure components and visualize how they’re related to one other.

You can also share environment variables between services, streamlining config management across complex projects with multiple components.

Additionally, Railway supports wildcard domains out-of-the-box. You can easily configure a wildcard domain at the project level to dynamically handle multiple subdomains.

Finally, Railway offers a template directory that makes it easy to self-host open-source projects with just a few clicks. If you publish a template and others deploy it in their projects, you’ll earn a 50% kickback of their usage costs.

Check out all templates at railway.com/deploy

Summary

Migrate from Heroku to Railway

To get started, create an account on Railway. You can sign up for free and receive $5 in credits to try out the platform.

Deploying your app

1. “Choose Deploy from GitHub repo”, connect your GitHub account, and select the repo you would like to deploy

1. If your project is using any environment variables or secrets:
   1. Click on the deployed service
   2. Navigate to the “Variables” tab
   3. Add a new variable by clicking the “New Variable” button. Alternatively, you can import a .env file by clicking “Raw Editor” and adding all variables at once.

1. To make your project accessible over the internet, you will need to configure a domain:
   1. From the project’s canvas, click on the service you would like to configure
   2. Navigate to the “Settings” tab
   3. Go to the “Networking” section
   4. You can either:
      1. Generate a Railway service domain: this will make your app available under a .up.railway.app domain
      2. Add a custom domain: follow the DNS configuration steps

Need help or have questions?

If you need help along the way, the Railway Discord and Help Station are great resources to get support from the team and community.

Working with a larger workload or have specific requirements? Book a call with the Railway team to explore how we can best support your project.