What do you like best about Railway?
The part I rely on most is the connection between a GitHub repo and a running service. Point Railway at a repository and it detects the stack, builds it, and hands me a live URL with no Dockerfile and no YAML pipeline in sight. We ship Node and Next.js front ends, a couple of Python services, and the occasional Go worker, and I have not had to hand-write a build config for any of them. When I do need to override the build, the Dockerfile route is there and it behaves, but the default path covers most of what my team ships. The first deploy of a new service is measured in minutes, and that number has not crept up as the projects have gotten messier.
The project canvas is where this stops being a single-app host and becomes somewhere I run a whole backend. Each service is a node on the canvas, I wire them together, and the private networking between them means my API talks to its database over an internal address rather than across the public internet. Adding a service is a click, and the new box appears next to everything it depends on, so the layout reads like the architecture instead of a list of unrelated deployments. For a small product with an API, a worker, a database, and a cache, having all of it visible in one place is most of why I stayed.
Managed databases attached inside the same project removed a whole class of setup I used to dread. Postgres, Redis, MySQL, and Mongo are each a one-click add, they come up with their connection details already wired into the environment, and I am not juggling a separate database host or copying connection strings between dashboards. Most of what we run sits on Postgres with a Redis instance alongside it, and standing that pair up next to the app it serves takes the time it takes to click twice. It is not a database product that will satisfy a dedicated DBA, but for the workloads a small team actually runs, it is exactly enough.
Pull request environments changed how we review work, and that is the feature I would fight to keep. Open a PR and Railway spins up an isolated deployment of that branch with its own URL, so a reviewer clicks a link and sees the change running rather than trying to picture it from a diff. Alongside that, the staging and production environments keep in-progress work away from anything live, and rollback is a couple of clicks back to a known-good deploy when something ships wrong. The "works on my machine" conversation has mostly stopped happening, because there is a real environment to point at.
Logs and metrics being there by default is the kind of thing I only appreciated after working somewhere they were not. Build logs stream in real time while a deploy runs, so I watch a failure happen rather than digging for it after the fact, and CPU, memory, and network usage sit on the same dashboard without my having to stand up Prometheus or Grafana to see them. For a team my size, that built-in visibility is the difference between catching a runaway service the same afternoon and finding out from a bill. It is not a full observability suite, and I would not pretend it replaces one for a large estate, but it answers the daily question of what a service is doing right now.
The template marketplace is a quieter strength that has saved me real afternoons. When I needed a Metabase instance for some internal reporting, it was a two-minute deploy with the service and its networking already configured, and the same held for a Ghost blog and a couple of other off-the-shelf tools I did not want to host by hand. I am not using templates for our core apps, those come from our own repos, but for the supporting pieces around a project they turn a half-day of setup into a click and a short wait.
The CLI and API matter more than they look like they should. The command-line tool lets me drive deploys and pull logs without leaving the terminal, and the API means I can fold Railway into the automation we already run rather than treating it as a separate place I have to visit. Background workers and cron jobs run as ordinary services on the platform too, so a scheduled task lives next to the app it supports instead of in some other scheduler. None of this is loud, and that is the point.
One last thing worth naming is the runtime model. Services run as long-lived containers on Railway's own hardware rather than as serverless functions, so there are no cold starts and the latency stays consistent from one request to the next, which matters for an API somebody is waiting on. Billing is metered by the second against the resources a service actually uses, and the included usage credit on each plan covers most of what a small project consumes. The pricing is legible in a way a lot of cloud billing is not, and I will come back to where that gets less comfortable. Review collected by and hosted on G2.com.
What do you dislike about Railway?
The thing I keep running into as the team grows is access control. The permissions model is coarse, and what I want is the kind of fine-grained, project-level roles that let me give a contractor access to one project without handing them the keys to everything in the workspace. Right now my defense is discipline, separating sensitive work into its own workspace and being careful about who gets a seat, but that is a workaround for a control the platform should provide. Proper role-based access with an audit trail of who changed what is the single feature I am waiting on before I would put a larger team on it.
Reliability is the area I watch most closely. Over the past several months the platform has had a run of incidents that touched builds, edge networking, and regional connectivity rather than one isolated outage, including a spell where builds paused for a whole region, and that pattern is enough that I do not put my most critical single-region workload on it without thinking first. To be balanced about it, the incidents have been communicated openly and the team is visibly responsive, which counts for a lot, and for our internal tools and non-critical services it has not been a problem in practice. For anything truly customer-facing I keep the status page close and design on the assumption that any single platform can have a bad day. Took me one bad afternoon to internalize that, honestly.
There is no built-in edge protection to speak of, no WAF and no real DDoS mitigation, and the public networking is not very customizable if you want to sit something in front of your service. For a backend exposed to the open internet that is a gap, and the way I have closed it is to put Cloudflare in front and let it handle the edge concerns Railway does not. That works, but it means Railway is the backend home and something else is the front door, and I would rather have at least a basic protective layer available natively.
The flip side of the legible pricing is that it does not go to zero when traffic does. A container that sits idle still bills for the resources it is holding, only staging environments scale down on their own, and every service in a project, the app, the database, the worker, the cache, carries its own usage. The base subscription is small and predictable, but the real bill is the usage on top of it, and a project with a few always-on services and a database adds up faster than the headline number suggests. My habit now is to set usage limits as a hard cap and check the usage dashboard before I scale anything, which keeps the surprises away, but a team arriving from a serverless platform should expect the bill not to behave the way they are used to.
The last point is reach. There are only a handful of regions today, so a user far from where a service runs pays for that distance in latency, and the answer for a global audience is again to pair Railway with a CDN rather than to lean on the platform alone. The region list is expanding and this matters less for a regional product than a worldwide one, but next to the big clouds the geographic footprint is still small, and it is the straightforward answer to what is missing if you serve users everywhere. Review collected by and hosted on G2.com.
