Hosting a Production Next.js + NestJS SaaS on Railway: A Real-World Case Study

Most of this site is about shared hosting and VPS plans for content sites in South Africa and Nigeria. But a growing share of readers are not running WordPress — they are building web applications: a booking tool, a fintech dashboard, a SaaS product. That is a different hosting problem, and the honest answer for many of these builders is that neither shared hosting nor a raw VPS is the right starting point.

This guide walks through a real production example to show where a platform-as-a-service (PaaS) fits. The case study is QuickWills, a digital platform that lets non-Muslim expats in the UAE create legally compliant ADGM wills online. It is a genuine production SaaS — a Next.js frontend and a NestJS + PostgreSQL backend — and both halves run on Railway. We will use its architecture to make the abstract trade-offs concrete.

Shared hosting, VPS, or PaaS?

If you have read our shared vs VPS hosting guide, you know the usual split: shared hosting for small sites, VPS when you outgrow it. A web application adds a third option that sits between them in effort and above them in capability.

• Shared hosting runs PHP and a MySQL database. It is built for WordPress and brochure sites. It generally cannot run a long-lived Node.js process, so a NestJS API server is a non-starter.
• A VPS gives you a bare Linux box. It can run anything — but you install Node, configure a reverse proxy, set up TLS certificates, run the database, wire up a process manager so the app restarts after a crash, and patch the OS every month. That is real, ongoing systems-administration work.
• A PaaS (Railway, Render, Fly.io, and similar) sits on top of cloud infrastructure and hides the server. You connect a Git repository; it builds your app, runs it, gives it a URL and a TLS certificate, and restarts it if it falls over. You never SSH into a machine.

For a solo founder, the PaaS trade is usually worth it. The scarcest resource is your time, and a VPS quietly consumes it — the day a security patch breaks your Nginx config is a day you are not building your product.

Why QuickWills chose a PaaS over a VPS

QuickWills is built and run by a small team, so the calculus is the same one most indie founders face. The application has two deployable pieces:

• A Next.js 14 frontend — the marketing pages plus the authenticated app where users answer questions and build their will.
• A NestJS + PostgreSQL backend — the API that stores user data, handles payments, and generates the final PDF document.

On a VPS, running those two services plus a database reliably means provisioning the box, installing and pinning a Node version, configuring a reverse proxy to route traffic to each service, obtaining and auto-renewing TLS certificates, running Postgres and backing it up, and adding a process manager so everything survives a reboot. None of that is hard in isolation; all of it together is a second job.

On Railway, each of those is a managed service in one project. The frontend and backend are separate deployments that build from the same connected repository, Postgres is a database you add from a menu, and TLS and restarts are handled for you. For a founder who would rather spend the week on will-drafting logic than on systemd units, that is the whole argument.

How Railway's build and deploy model works

The mental shift from a VPS is that you stop thinking about a server and start thinking about a service that builds from your repository.

Railway connects to your Git repo. On every push to the branch you nominate, it builds and deploys automatically. By default it uses Nixpacks, an open-source builder that inspects your code, detects that it is a Node project, and produces a container image without you writing any Dockerfile. For a standard Next.js or NestJS app, this "just works" — Nixpacks installs dependencies, runs your build script, and starts the app.

QuickWills runs both services this way: the Next.js frontend and the NestJS backend are two Railway services in one project, each building from the same repository via Nixpacks, each redeploying on push. There is no Dockerfile to maintain for either — which, as we will see below, is a feature, not a limitation.

Managed Postgres, environment variables, and feature flags

Managed Postgres. On Railway you add a Postgres database as a service and it hands you a connection string. Automated backups, the underlying version, and the disk all sit behind the platform. QuickWills stores all user and will data in a managed Railway Postgres instance, which means the founder never runs pg_dump on a cron job or worries about a full disk at 2am. For a data-sensitive product — and a wills platform is about as sensitive as it gets — offloading database durability to the platform is a meaningful reduction in risk.

Environment variables. Every secret and config value — the database URL, the Stripe keys, the Resend API key — lives in Railway's dashboard as an environment variable, injected into the service at build and run time. This is a genuine security win over a VPS, where secrets often end up in a .env file sitting on the box. QuickWills keeps its Stripe (payments), Resend (transactional email), and database credentials as Railway variables rather than in the repo or on a server.

Feature flags. Railway also lets you toggle behaviour through configuration without redeploying application code. QuickWills uses Railway's feature-flag capability to gate functionality — the kind of switch that lets you turn a half-finished feature on for testing and off for everyone else, without a code change and redeploy for every flip.

What it costs

This is where a PaaS looks expensive next to the VPS prices elsewhere on this site — until you price in your own time.

Railway bills on a usage basis on top of a plan fee. At the time of writing its Hobby plan starts at a low single-digit monthly figure that includes a small allowance of usage, and the Pro plan steps up from there with higher limits; on top of the plan you pay for the compute, memory, and bandwidth your services actually consume. Always check Railway's current pricing before you budget, because these numbers move.

For a low-traffic app that is still finding customers, a PaaS bill is small — often comparable to an entry VPS once you add the database and TLS you would have to run yourself anyway. The number to watch is that usage-based billing rises with traffic, so a sudden spike costs more than a fixed-price VPS would. For most early-stage products, paying a little more to delete server administration entirely is the right trade. If your app becomes consistently busy and cost-sensitive, that is the point to reconsider — the same "have you outgrown it?" question we ask about shared hosting.

The biggest gotcha: custom Dockerfiles and Next.js env injection

The one trap worth calling out specifically catches a lot of Next.js teams on Railway.

Next.js inlines public environment variables at build time. Any variable prefixed NEXT_PUBLIC_ is baked into the client-side JavaScript bundle when the app is built — not read at runtime. For that to work, the variable has to be present during the build.

With Railway's default Nixpacks builder, your dashboard environment variables are available at build time, so NEXT_PUBLIC_* values get inlined correctly and everything works. The moment you switch a service to a custom Dockerfile — usually to customise the build — you change how variables reach the build step. Docker build stages do not automatically see Railway's runtime variables; they have to be passed in explicitly as build arguments. If you forget, the build succeeds, the app deploys, and then the browser bundle has undefined where your public API URL or publishable key should be. Nothing errors in the build logs — it just quietly ships broken client config.

The lesson QuickWills' setup embodies: stay on Nixpacks unless you have a concrete reason not to. The default builder handles environment injection correctly, and avoiding a custom Dockerfile sidesteps the whole class of "works locally, broken in production" bugs around public env vars. If you do need a Dockerfile, remember to declare each public variable as a build ARG and pass it through, or your client bundle will not see it.

When a PaaS is the right call — and when it is not

A PaaS like Railway is the right starting point when you are shipping a real web application (not a content site), you are a solo founder or small team without a dedicated ops person, and you value shipping speed over squeezing out the lowest possible hosting bill. QuickWills fits all three, which is why its Next.js + NestJS + Postgres stack lives on Railway rather than on a hand-configured VPS.

It is the wrong call when a VPS or shared plan already covers you: a WordPress site or brochure page belongs on the shared and VPS hosting we cover for South Africa and Nigeria, not on an app platform. And a large, cost-sensitive, high-traffic application with an ops team may well save money running its own infrastructure. The decision is the same one that runs through our how to choose web hosting guide: match the hosting to what you are actually building, not to what sounds most impressive.

For more on the hosting choices behind this decision, read our shared vs VPS hosting guide and our how to choose web hosting checklist. If you have decided a server is what you want after all, see our picks for the best VPS hosting in South Africa and the best VPS hosting in Nigeria.

Some links on this site are affiliate links. See our disclosure for details.