# 9 Railway Alternatives in 2026, Compared by Operator > Render, Fly.io, Northflank, Coolify, Clever Cloud, Scalingo, Upsun and Runsite compared for Railway users: who operates each, how it bills, what migrating costs. 1. [Home](/) 2. [Blog](/blog) 3. 9 Railway Alternatives in 2026 — and What You're Actually Detaching From DeploymentAugust 13, 202614 min read # 9 Railway Alternatives in 2026 — and What You're Actually Detaching From Nine platforms that replace Railway, compared by who operates them and how they bill — plus the four things inside your project that decide how hard the move is. ## The short version How hard leaving Railway is has nothing to do with which platform tops which table. Four things inside your project decide it: variables that are references rather than values, databases living inside the project boundary, a build produced without a Dockerfile, and whatever sits on an attached volume. Take those apart first, in that order. [Teo Marquardt](/about#author)· Updated September 13, 2026· Facts last checked September 13, 2026 The short version, before the reasoning. Render is the closest like-for-like move. Fly.io suits an application that has to sit near users in several regions. Northflank is the one to look at if you want production controls or your own cloud account underneath. Coolify and Dokploy on European hardware produce the smallest invoice, in exchange for owning the server. Clever Cloud, Scalingo and Upsun are the three run by companies incorporated in the EU, which is the group that changes the answer when a customer asks whose law governs their data. Runsite, which publishes this page, keeps the data in the EU but is operated by an individual rather than a company, so it answers that question differently. Each is described below, with the property that separates it from the others. The longer version is that which of those nine is right for you depends less on the platform than on what your Railway project is holding onto — and that part is measurable before you choose anything. This is the third list of Railway alternatives you have opened this morning, and by now the pattern is visible: each one is written by a platform, and each one comes first in its own ranking. The tables disagree about who wins and agree about the format, which is a feature matrix comparing things you will not care about in a month. None of them answers the question you actually have. You are not choosing a platform in the abstract. You have a project on Railway that works, and the thing standing between you and any of these names is the amount of unpicking nobody has quantified for you. Two adjacent questions are deliberately out of scope here. If you want two named managed platforms held against each other, that is done in [Render vs Railway](/blog/render-vs-railway). If the real question is whether the platform layer should run on a server you administer, the ledger for that is in [self-hosted PaaS versus managed](/blog/coolify-vs-managed-paas). What follows assumes you are leaving and want to know what leaving costs. ## Nine Railway alternatives in 2026, and who each one is for The column most comparison tables leave out is the one that decides whether a migration solves the problem that prompted it. A platform is operated by a company, that company is registered somewhere, and where it is registered is what determines whose law reaches your customers’ data — not which region you picked from a dropdown. The table sorts on that, then on how each platform bills, because those are the two properties that do not change between the day you read this and the day you deploy. | Platform | Where the operator is registered | How it bills | Best for | | ------------------- | --------------------------------------------------------------------------------------- | ------------------------------------------------------ | --------------------------------------------------------------------------- | | Render | [United States](https://render.com/terms) (Render Services, Inc.) | Fixed instance tiers, prorated by the second | The closest thing to a like-for-like move | | Fly.io | [United States](https://fly.io/legal/terms-of-service/) (Fly.io, Inc.) | Per-second, machines can stop when idle | An app that must run close to users in several regions | | Northflank | [United Kingdom](https://northflank.com/legal/terms) (Northflank Ltd) | Per-second usage; can run in your own cloud account | Production controls, and teams that want to keep the infrastructure account | | Coolify | [Open source, Apache-2.0](https://github.com/coollabsio/coolify); you rent the server | Your server bill, nothing else | The smallest invoice, if you are willing to own the operations | | Dokploy | [Open core, mostly Apache-2.0](https://github.com/Dokploy/dokploy); you rent the server | Your server bill, nothing else | A lighter self-hosted control plane than Coolify | | Clever Cloud | [France](https://clever.cloud/legal-notice/) (Clever Cloud SAS, Nantes) | Per-second, scales with load | A French operator with a broad managed-service catalogue | | Scalingo | [France](https://scalingo.com/legal-notice) (Scalingo SAS, Strasbourg) | Per-minute for most products, fixed container sizes | Regulated workloads that need a French operator named on paper | | Upsun (Platform.sh) | [France](https://upsun.com/trust-center/legal/impressum/) (Platform.sh SAS, Paris) | Per-project fee, plus resources and per-user licences | Larger teams running many environments per project | | Runsite | [Not incorporated](/compliance): sole operator, EU infrastructure | Fixed plan sizes, billed hourly from a prepaid balance | Small teams that want EU-only data and a bill that does not move | Nine alternatives to Railway. Each operator column links to that company's own terms or legal notice; billing was checked against its pricing page on 13 September 2026\. Prices move; operators and billing shapes rarely do. ### 1\. Render — the closest like-for-like move Render is where most people leaving Railway end up, and the reason is that almost nothing about the workflow changes: connect a repository, get a build, get a URL, add a managed Postgres next to it. What does change is the billing model. Railway meters what you consume; Render [sells instance types at a fixed monthly price](https://render.com/pricing), prorated to the second, so the number on the invoice stops depending on how busy a bad week was. If the reason you are leaving is that the bill moved without warning, that swap alone addresses it. Its free tier [spins a web service down after 15 minutes without traffic](https://render.com/docs/free) and takes about a minute to wake it, and a free Render Postgres database expires 30 days after creation. Both are worth knowing before you put a demo link on it; the mechanics are in [why free-tier apps fall asleep](/blog/cold-starts). The head-to-head is in [Render vs Railway](/blog/render-vs-railway). The property the move does not change: the contract is with Render Services, Inc. in San Francisco, and [its Frankfurt region](https://render.com/docs/regions) operated by a US company is still operated by a US company. ### 2\. Fly.io — when the app has to be near the user Fly.io runs containers in many regions and [prices every Machine per second](https://fly.io/docs/about/pricing/), and its proxy can [stop idle Machines and start them again on the next request](https://fly.io/docs/launch/autostop-autostart/). That makes it structurally different from a platform that rents you an always-on instance, though a stopped Machine is not free: its root filesystem is still billed. That fits an application whose latency budget is spent on the network rather than in the database — a chat backend, an API with users on three continents, anything where the round trip is the cost. It fits less well if what you wanted was fewer moving parts, because you are now reasoning about where each machine is and what happens when one region is unhealthy. The database story has changed shape. Fly now sells [Managed Postgres](https://fly.io/docs/mpg/), which lists version upgrades and migration tooling as still in development, and the older Fly Postgres is labelled [unmanaged, with no support offered for it](https://fly.io/docs/postgres/). Tables written a year ago tend to describe the second as if it were the first. Also a US operator: the terms are with Fly.io, Inc. ### 3\. Northflank — production controls, and the option to keep your own cloud account Northflank sits a step further toward a real production platform than Railway aims to: pipelines, preview environments, more explicit control over how a release rolls out, and the option to [run the whole thing inside a cloud account you own](https://northflank.com/docs/v1/application/bring-your-own-cloud/use-other-cloud-providers-with-northflank) on AWS, Google Cloud or Azure, where Northflank manages a Kubernetes cluster for you. That last part is the reason it appears on shortlists that also contain much heavier things, because it lets a small team keep the commercial relationship with the infrastructure provider while outsourcing the control plane. The operator is [Northflank Ltd, company number 11918540](https://find-and-update.company-information.service.gov.uk/company/11918540), registered in London, which after Brexit means the United Kingdom rather than the EU. That matters to a procurement questionnaire even though the UK holds an adequacy decision, [renewed in December 2025 and due to expire on 27 December 2031](https://eur-lex.europa.eu/eli/dec%5Fimpl/2025/2574/oj/eng). A decision with an expiry date is worth understanding before you assume it settles the jurisdiction question. What adequacy is and how durable it is are covered in [Schrems II and EU data transfers](/blog/schrems-ii-data-transfers). ### 4\. Coolify — the smallest invoice, if you own the server Coolify is not a hosting company. It is an [open-source control plane under the Apache-2.0 licence](https://github.com/coollabsio/coolify) that you install on a machine you rent, and it gives you a git-push workflow, a dashboard and managed-looking databases on hardware you are administering yourself. On European infrastructure from Hetzner, Scaleway, OVHcloud, Exoscale or UpCloud, the monthly cost of running several services drops by an order of magnitude compared with any managed platform in this table. The exchange is that the operating system, the Docker disk, the reverse proxy, the certificates, the backups and the upgrades of Coolify itself become yours, and if it all runs on one box you have one failure domain. That exchange is priced out honestly, hour by hour, in [what self-hosting a PaaS actually costs](/blog/coolify-vs-managed-paas). ### 5\. Dokploy — a lighter control plane on the same idea Dokploy occupies the same slot as Coolify with a smaller surface: install it on a server, point it at a repository, get deployments and a UI. One licensing detail separates it. [Most of the repository is Apache-2.0](https://github.com/Dokploy/dokploy), but code in its proprietary folders is under a source-available licence that requires a commercial agreement for production use, so check which features you are relying on. [Dokku](https://github.com/dokku/dokku) and [Kamal](https://github.com/basecamp/kamal), both MIT-licensed, sit nearby, further toward the command line and further from a dashboard. Which of the four you pick matters much less than the decision they share, which is that you are taking on the box. If you are weighing this group at all, read the ledger for Coolify above and apply it here. The numbers are the same, and the deciding question is still how you value an evening spent on a certificate that did not renew. ### 6\. Clever Cloud — a French operator with a wide catalogue Clever Cloud is a French company, [Clever Cloud SAS, registered in Nantes](https://clever.cloud/legal-notice/), running a managed platform with a broad service catalogue: application runtimes, Docker deployments, managed databases, object storage and observability. Compute is [billed by the second](https://www.clever.cloud/pricing/), so the cost tracks load rather than a fixed instance size; storage and traffic are billed by volume. It is the option to look at when you want the breadth of a large managed platform and an operating company inside the EU at the same time, which is a combination the ranked listicles rarely surface because they sort on feature count rather than on who signs the contract. ### 7\. Scalingo — when the operator has to survive a compliance review Scalingo is French, managed, and the one on this list built most deliberately around being able to answer a procurement questionnaire: a European operating company ([Scalingo SAS, Strasbourg](https://scalingo.com/legal-notice)), European infrastructure underneath, and [ISO 27001:2022 and HDS certification](https://doc.scalingo.com/security/overview/compliance) for buyers who have to document where regulated data sits. Most products are [billed by the minute](https://doc.scalingo.com/platform/billing/process). If your blocker is not the price and not the feature set but a security review that keeps coming back with questions about subprocessors, this is the shape of answer that closes it. What such a review actually asks for is set out in [GDPR data residency](/blog/gdpr-data-residency). ### 8\. Upsun — many environments per project Upsun is the current product from [Platform.sh SAS, registered in Paris](https://upsun.com/trust-center/legal/impressum/), and its distinguishing idea is that an environment is cheap and clonable: by default [a new environment inherits the data and services of its parent](https://developer.upsun.com/docs/environments), databases included, which is a different mental model from a preview deployment that shares the production database. That suits a team with several people working on the same application at once and a real review process, and it is more machinery than a solo project needs. [Billing has four parts](https://developer.upsun.com/docs/administration/pricing): a monthly fee per project, CPU, memory and disk by usage, a licence fee per user, and paid add-ons. That reads differently from every other row in the table and is worth modelling before you commit. ### 9\. Runsite: EU-only infrastructure and a bill that does not move Ours, and stated with its limits so you can discount it accordingly. Runsite is not a registered company. It is operated by an individual developer, running [web services on EU infrastructure](/services/web-services) from €3/mo, with [managed PostgreSQL](/services/postgresql) from €3/mo and [managed Redis](/services/redis) from €5/mo alongside. You pick a fixed plan size and it is billed by the hour from a prepaid balance, rather than metered on the CPU and memory you actually touch. That is worse than Railway for an application that idles most of the day, better for one that does not, and predictable either way. There is one region, in Germany: against a platform advertising a dozen, that is a short list, and if you need to serve Singapore from Singapore it is the wrong answer. What the single region buys is that containers, variables, build artifacts and logs stay in the EU with no replication out. A signed [data processing agreement](/blog/what-is-a-data-processing-agreement-dpa) comes with every account, and every subprocessor is named with its legal entity on the [compliance page](/compliance), including the two outside the EEA. There is no import tool; the checklist further down is work you do yourself. The column that actually decides it Three of these nine are run by companies outside the EU, same as Railway. Two are software you operate yourself, three are EU companies, and one (ours) has no company behind it at all. That is not a criticism of any of them (Render and Fly.io are good at things Railway is not), but it does mean that moving from Railway to another US or UK operator changes your billing model and leaves the jurisdiction question exactly where it was, whichever region you deploy into. If nobody has asked you whose law applies to your customers’ data, that column is free to ignore. If somebody has, it is the only column that matters. ## Why people leave Railway Three reasons recur, and they arrive at different stages. The first is that the bill moves. On top of a plan fee, Railway [charges for the RAM, CPU, egress and volume storage a service actually uses](https://docs.railway.com/pricing/plans): $10 per GB of RAM and $20 per vCPU per month, prorated. That is honest, and it also means a retry loop, a worker draining a queue that keeps refilling, or a job that was meant to run nightly can be billed as legitimate work and noticed at the end of the month. The second is the free allowance running out. New accounts get [a one-time $5 trial for up to 30 days](https://docs.railway.com/pricing/free-trial), after which the Free plan carries $1 of credit a month, and for people who have been around a while there is also the memory of a free tier that changed shape once already. The third arrives latest: a ceiling you meet while growing, whether that is the shape of the pricing at scale or the operational surface you want around a production service. None of that is an indictment. Railway does something genuinely well, which is making an architecture legible as a graph rather than as a list of unrelated dashboard entries, and shortening the distance from a repository to a running application about as far as anyone has managed. The reasons above are reasons to leave, not evidence that staying is a mistake. If none of them describes your situation, the rest of this page is not trying to move you. ## What you're actually detaching Every list of alternatives makes the same silent assumption: that your application is a container you can pick up and set down somewhere else. On Railway it usually is not. What you have is a project, and a project is a graph: services that know about each other, data that lives inside the same boundary as the code, and a build nobody wrote down. The four things below are what that graph costs to take apart. None of them appears in a feature matrix, and all of them surface in the first hour, not the last. ### The variables that are links, not values Services on Railway can [reference each other's variables](https://docs.railway.com/variables/reference) with a `${{ Service.VARIABLE }}` template, so the connection string your application reads is a reference that gets resolved at deploy time rather than a literal you typed. This is a good feature and it is why the graph is convenient to build. It also means that exporting your environment gives you a page of pointers rather than a page of values, and that the resolution happens inside the platform you are leaving. The first symptom is an application that starts on the new host and cannot find its database, and the fix is to work out by hand what each reference was actually pointing at. text ``` # What the graph looks like from inside the project DATABASE_URL = ${{ Postgres.DATABASE_URL }} <- resolved by the platform REDIS_URL = ${{ Redis.REDIS_URL }} <- resolved by the platform API_BASE = ${{ api.RAILWAY_PUBLIC_DOMAIN }} <- resolved by the platform # What every other platform expects you to hand it DATABASE_URL = postgresql://user:pass@host:5432/dbname REDIS_URL = redis://user:pass@host:6379 API_BASE = https://api.example.com # The gap between those two blocks is manual work, # and it is discovered at the moment the app fails to boot. ``` ### The databases that live inside the project Postgres and Redis on Railway are [deployed from templates as services](https://docs.railway.com/databases/postgresql) sitting next to the application inside the same project, rather than as an external endpoint your application happens to point at. Railway's own docs are direct about what that means: [the database templates are unmanaged](https://docs.railway.com/databases), and backups, disaster recovery and tuning are yours. So moving them is the difference between changing a connection string and performing a migration. Leaving means getting the data out, finding it somewhere to live, and verifying that what came out goes back in, which for anything with real rows in it is the longest single task in the move. It is also the one people schedule last, because the application is the visible part and the database is not. If you are moving to [managed PostgreSQL hosted in the EU](/services/postgresql) or anywhere else, the restore is the step worth rehearsing before the day you need it. ### The build you never wrote When there is no Dockerfile, Railway builds an image from your source with [Railpack](https://docs.railway.com/builds/railpack), which replaced Nixpacks, detecting the stack and assembling the image for you. [A Dockerfile in the repository is used instead](https://docs.railway.com/builds) if one exists. The convenience is real and the consequence is quiet: there may be no build definition in your repository, which means there is no artifact you own and no description of how the running thing was produced. Why that matters beyond this one migration is worked through in [how git push to deploy actually works](/blog/git-push-to-deploy). The artifact is the part that makes a deploy reproducible, and a build that exists only inside a vendor's pipeline is a build you cannot take with you. ### The volume that doesn't come with you If your service has attached storage, whatever is in it is not part of the repository and not part of the database dump. Uploaded files, generated assets, a SQLite file somebody added early and forgot about: these move only if you move them deliberately. Railway's volume backups will not do it for you, because [a backup can only be restored into the same project and environment](https://docs.railway.com/volumes/backups), and the docs describe no way to download one. [Each service gets a single volume](https://docs.railway.com/volumes/reference), which at least bounds the search. No comparison table has a row for this, and it is the item most likely to be discovered after the switchover instead of before. Moving that content to [object storage with no egress charges](/services/s3-storage) is worth doing whether or not you change platforms, because it turns a machine-shaped dependency into an addressable one. ## The checklist to run before you pick anything The useful order is the opposite of the obvious one. Rather than choosing a destination and then discovering what does not travel, reduce what ties you to the current platform first. Every item below can be done today, on Railway, without deciding anything about where you are going. * **Write a Dockerfile and build the image locally.** If it builds on your machine and runs, you own the build. This single step converts a platform-detected application into a portable one, and it is the item that unblocks every other option including staying. * **Flatten the variable graph into a plain file.** Go through every reference and write down the value it resolves to. Do it while the platform is still there to tell you, rather than at two in the morning while an application refuses to boot. * **Take a database dump and restore it somewhere else.** Not just take it. Restore it, into a throwaway instance, and point something at it. A dump you have never restored is a hypothesis. * **Move volume contents into object storage.** Anything written to attached disk is the least portable thing you own. Once files are addressed by URL, the service becomes stateless and the move becomes a deploy rather than an operation. * **Deploy once from a clean clone.** Fresh checkout, no local state, no manual steps you have forgotten you perform. Whatever fails here is exactly what would have failed on the new platform, discovered on a day when nothing depends on it. The point of doing this first None of these five steps requires you to have chosen a destination, and none is wasted if you decide to stay. What they buy is optionality: after them, the difference between platforms is a comparison you can actually make, because the cost of being wrong has dropped from a weekend to an afternoon. Migrations get frightening in proportion to how much of the system lives somewhere you cannot inspect. ## Which of the nine, by the constraint that is actually binding Once the project is portable, the nine sort themselves into three groups, and which group you want is decided by which constraint is actually binding. The mistake worth avoiding is picking by preference — the platform with the nicest dashboard, the one a friend mentioned — and discovering later that it does not address the thing that made you move in the first place. | What is actually binding | The group that addresses it | What changes | What does not | | ---------------------------------- | ------------------------------------- | ---------------------------------------------------- | ---------------------------------------------------------- | | The bill is unpredictable | Another managed platform, US-operated | Billing shape, interface, the region list | Whose law governs your customers' data | | The invoice is simply too large | Run the platform layer yourself | Monthly cost, and how much of the operations you own | That somebody has to be awake when it breaks | | A customer asked whose law applies | A European operating company | The sentence you send to a security review | The amount of migration work, which is the same either way | Sorted by the constraint rather than by rank. The last column is the one that tends to go unread. The first group is the lateral move, and it is the most common one. Render, Fly.io and the other US-operated managed platforms will change how you are billed and how the dashboard feels, and several of them are genuinely better than Railway at specific things. What that move does not touch is jurisdiction, since a US company operating a Frankfurt region remains a US company. That trade is examined in detail in [Render vs Railway](/blog/render-vs-railway), including the case where the migration is motivated by something the migration does not change. One caveat if Vercel is on your shortlist: it is a different shape of platform rather than a peer of these, and what that costs a full-stack application is worked through in [Vercel alternatives for full-stack apps](/blog/vercel-alternatives). The second group is running the platform layer on infrastructure you rent, with Coolify, Dokploy, Dokku or Kamal on European hardware from Hetzner, Scaleway, OVHcloud, Exoscale or UpCloud. The invoice drops and the operating system, the Docker disk, the proxy and the backups become yours. That exchange is priced honestly in [what self-hosting a PaaS actually costs](/blog/coolify-vs-managed-paas), which is the right page for the open-source and self-hosted end of this question. The third group is European managed platforms, where the operating company is itself in the EU: Clever Cloud, Scalingo and Upsun among them. Runsite keeps data EU-only on the same terms but is operated by an individual rather than a company, which is a different answer to the entity question and worth knowing before you cite it in a questionnaire. This is the only group that changes the answer you give when a customer asks whose law governs their data, and it is also the group nobody puts in a ranked list, since the lists sort by feature count rather than by operator. What "European" can legitimately mean, and which of its meanings survives a procurement questionnaire, is set out in [choosing a European Heroku alternative](/blog/european-heroku-alternative). ## What the move actually costs With the checklist done, the move itself is smaller than it looks and lands in a predictable order. The application is the easy part: a Dockerfile you already wrote, a repository connection, a first deploy that either works or tells you what is missing. The variables need care but not much time. What takes real time is the data, and the schedule should be built backwards from it. The failures worth planning for are the ones that come from the graph rather than from the new platform. A reference that resolved to something you never looked at. A service that talked to another over an internal address that no longer exists. A cron or worker that was configured in a dashboard rather than in the repository, and therefore does not exist in your clone at all. Each is small on its own, and each is the kind of thing that turns a two-hour job into an evening because it is invisible until something calls it. Plan the move backwards from the database Everything else can be redone in minutes if it goes wrong; the data cannot. Decide first how the dump is taken, how long the restore runs, and what happens to writes that arrive during it. If the answer to the last one is a short maintenance window, that is fine, as long as it is a decision you made and not one you discovered. ## How Runsite handles it For the European group, concretely, and starting with what will not help you. There is no import tool. Runsite does not read your Railway project, does not convert a variable graph, and does not migrate a database for you; the checklist above is work you do yourself regardless of where you land. The second thing is pricing shape: Runsite charges fixed monthly plans rather than metering consumption, so an application that idles most of the day may well cost less on a consumption meter than it does here. [Web services on EU infrastructure](/services/web-services) start at €3/mo for the entry Nano plan at 0.1 vCPU and 256 MB and run up to 8 vCPU and 16 GB on Business Plus. The third limitation is regions: there is one, in Germany. Against a platform advertising a dozen, that is a short list, and if you need to serve Singapore from Singapore it is the wrong answer. What the single region buys is the sentence in the third row of the table above. Your containers, environment variables, build artifacts and logs stay inside the EU, there is no replication to non-EU regions, and a signed [GDPR data processing agreement](/blog/what-is-a-data-processing-agreement-dpa) comes with every account. The processor named in it is an individual, not a company, and the [compliance page](/compliance) says so right next to the subprocessor list. The parts that make the checklist pay off are ordinary. Your Dockerfile is used when you supply one, and the stack is detected for Next.js, Django, Rails, FastAPI and others when you do not. Connect a repository on GitHub, GitLab or Bitbucket and a webhook builds on every push; releases are rolling behind a configurable health check, a failed check returns to the previous healthy version, and from the Standard plan (€12/mo) every pull request gets an environment on its own URL. A typical deploy takes around 30 seconds, and manual rollbacks with deploy history are on the Pro plan (€25/mo). Even on the entry Nano plan, active applications do not cold-start; a service sleeps only after 14 days idle. Alongside it sit [managed PostgreSQL hosted in the EU](/services/postgresql) from €3/mo and [managed Redis for caches and job queues](/services/redis) from €5/mo, which is where the two services that currently live inside your Railway project would go. Setup details are in the [Runsite docs](https://docs.runsite.app). ## The short version The ranked lists are answering a question you do not have. What decides how hard leaving Railway is has nothing to do with which platform tops which table, and everything to do with four things inside your current project: variables that are references rather than values, databases that live inside the project boundary, a build that was produced without a Dockerfile, and whatever is sitting on an attached volume. Take those apart first, in that order, and the destination becomes a choice instead of a commitment. Then pick the group by the constraint that is actually binding. Another US-operated platform if the billing model is the problem, your own server if the invoice is, a European operating company if somebody has started asking whose law applies to your customers' data. The last one is the only question the other two cannot answer, and it is far cheaper to settle before a migration than after. Deploying one service on [a European platform that builds from your own Dockerfile](/services/web-services) is a short way to find out whether the checklist actually made you portable. Related service ## Web Services on Runsite Deploy from a single git push and keep active apps warm — no cold starts, hosted entirely in the EU with a signed GDPR DPA on every plan. [Explore Web Services](/services/web-services) [Back to all articles](/blog) FAQ ## Frequently Asked Questions Common questions about this service. ### Which is better, Railway or Render? Neither is better in general; they fail in different directions. Railway meters what you actually consume, which is honest and means a retry loop or a worker draining a queue can be billed as legitimate work and noticed at the end of the month. Render sells fixed instance tiers, so the invoice stops moving but you pay for capacity an idle app is not using. If your complaint about Railway is that the bill surprised you, Render addresses it directly. If your complaint is that the platform ran out of room as you grew, both platforms sit in roughly the same class and the move will not fix it. And if the reason you are looking is that somebody asked whose law applies to your customers' data, the answer is unchanged: Railway Corporation and Render Services, Inc. are both based in San Francisco, and a Frankfurt region operated by a US company remains operated by a US company. The full comparison, including free tiers and regions, is in the Runsite article Render vs Railway. ### What is the best European alternative to Railway? Three platforms in common use are operated by companies established in the EU: Clever Cloud (France), Scalingo (France), and Upsun, which is Platform.sh SAS in Paris. Which is best depends on what you are optimising for. Clever Cloud has the broadest managed-service catalogue of the three. Scalingo is built most deliberately around surviving a compliance review. Upsun suits teams that want a full clonable environment per branch. Runsite, which publishes this page, bills fixed monthly plans rather than metering consumption and runs a single region in Germany; it is operated by an individual developer rather than a registered company, so if the question is specifically which EU legal entity you are contracting with, the three above answer it and this one does not. Note that Northflank, which appears on many European shortlists, is registered in London. That is the United Kingdom rather than the EU, which is a different answer to give a procurement questionnaire even under the UK adequacy decision the Commission renewed in December 2025, valid until 27 December 2031. ### Is there a free alternative to Railway? Several platforms offer a free tier, but the useful question is not whether one exists. What matters is what that tier does to an idle application. Most of them stop the container after a period without traffic, which means the next visitor waits for it to start again, and that visitor is usually the one you cared about: someone following a demo link, or a webhook that fires twice a week. The mechanics of that wait are covered in the Runsite article on cold starts and why free-tier apps fall asleep. Two other things are worth checking on any free plan. What happens when the monthly allowance runs out, since the service may suspend instead of degrading, and what happens to the free database, which on most platforms expires well before the free application does. For comparison, Railway's own trial is a one-time $5 for up to 30 days, followed by $1 of monthly credit on its Free plan. Runsite has no free web tier: the entry Nano plan runs one web service at 0.1 vCPU and 256 MB for €3/mo, covered by the €5 starting credit, active applications do not cold-start, and a service sleeps only after 14 days idle. ### What is the best open-source alternative to Railway? The open-source options are self-hosted control planes, not hosted platforms, which makes them a different kind of thing rather than a cheaper version of the same thing. Coolify is the most widely used, with Dokploy, Dokku and Kamal covering nearby ground, and all of them run on infrastructure you rent, which in Europe usually means Hetzner, Scaleway, OVHcloud, Exoscale or UpCloud. What you gain is a much smaller invoice and full control of the box. What you take on is the operating system, the Docker disk, the reverse proxy, the certificates, the backups and the upgrades of the control plane itself, plus a single failure domain if everything runs on one server. Whether that exchange is worth it depends on how you value your own time, and it is priced out in full in the Runsite comparison of Coolify against a managed platform. ### How do I migrate off Railway? Do the portability work before you choose a destination, because all of it is useful regardless of where you end up. Write a Dockerfile and confirm the image builds and runs locally, which turns a platform-detected application into one you own. Flatten the environment: Railway services can reference each other's variables through \`${{ Service.VARIABLE }}\` templates, so what you have is a graph of pointers rather than a list of values, and each one needs resolving into a literal while the platform is still there to tell you what it meant. Take a database dump and actually restore it somewhere, since an untested dump is a hypothesis rather than a backup. Move anything on an attached volume into object storage, which is the least portable thing you own. Then deploy once from a clean clone to find the manual steps you have forgotten you perform. After that the move itself is mostly the database, and the schedule should be planned backwards from how long the restore takes. ### Is there a European alternative to Railway? Yes, and it is a different question from whether a platform offers a European region. Clever Cloud, Scalingo and Upsun are examples of platforms whose operating company is itself established in the EU, which is the property that determines whose law applies to your customers' data. Runsite, which publishes this page, runs EU-only infrastructure but is operated by an individual rather than a registered company, so it is not an example of that particular property. Railway Corporation is a US company based in San Francisco, and so are most of the platforms that appear in alternatives listicles, which means moving between them changes your billing model and leaves the jurisdiction question exactly where it was, whichever region you deploy into. Two checks separate the two situations: which legal entity appears in the terms you are agreeing to and where it is registered, and who the subprocessors are and where they sit. Both live in the terms or the DPA, not on the pricing page. The fuller version of that test, including the three different things "European" is used to mean, is in the Runsite guide to choosing a European Heroku alternative. Keep reading ## Related articles [Deployment12 min readRender vs Railway: Pricing, Free Tiers, and the Question Neither AnswersEvery comparison argues per-second billing against fixed instances. That axis is real, and it is not the one that decides where your data lives.Aug 12, 2026Read](/blog/render-vs-railway)[Deployment13 min readCoolify and Self-Hosted PaaS vs Managed: What You're Taking OnWhat you actually take on when the PaaS layer runs on your own server: the maintenance ledger, the one box that holds everything, and when it stops paying off.Aug 10, 2026Read](/blog/coolify-vs-managed-paas)[Deployment14 min readVPS vs PaaS Cost: What a €5 Server Actually Costs YouThe price gap between a raw VPS and a managed platform is smaller than the pricing pages suggest. This itemises both sides: the hidden line items, the jobs, and who the processor is.Aug 19, 2026Read](/blog/vps-vs-paas-cost) ## Your app deserves to be online €5 of credit on signup. Deploy in under a minute. No credit card needed. [Start deploying](https://dashboard.runsite.app/login)[View documentation](https://docs.runsite.app) --- Source: https://runsite.app/blog/railway-alternatives