The cleanest way to ship a production full-stack TypeScript app in 2026 is a monorepo with a Next.js frontend, a NestJS API, and a PostgreSQL database, deployed on Railway. You get one language end to end, shared types between client and server, a structured and testable backend, and a deploy target that runs your API and database together for a few dollars a month. It looks like a lot of moving parts; with the right structure it's three services and a database you can stand up in an afternoon.
Here's the architecture we reach for, why each piece earns its place, and exactly what it costs.
The reference architecture
Four parts, one repo:
- Next.js (App Router) — the frontend and any edge/server rendering. The current Next.js 16 line.
- NestJS — a structured, modular API: controllers, services, dependency injection, guards. Currently on v11.x, with v12 (ESM-first) on the roadmap for later in 2026.
- PostgreSQL — the database, with Prisma or Drizzle as the type-safe data layer.
- Shared types package — TypeScript interfaces both apps import, so the client and API never drift.
Why split Next.js and NestJS instead of using Next.js route handlers for everything? Because once your backend has real domain logic — jobs, queues, role-based auth, integrations — NestJS's structure pays off in testability and maintainability that ad-hoc API routes don't.
Monorepo setup
Use a monorepo so the frontend, backend, and shared code live and version together:
my-app/
apps/
web/ # Next.js
api/ # NestJS
packages/
shared/ # shared TypeScript types, validation schemas
package.json # pnpm workspaces + Turborepo
Tooling: pnpm workspaces for dependencies and Turborepo (or Nx) for task orchestration and caching. The packages/shared workspace is the quiet hero — define a User or Invoice type once and both apps stay in lockstep.
Deploying to Railway, step by step
Railway treats each app and the database as a service in one project:
- Create a Railway project and connect your Git repo.
- Add the Postgres database — one click; Railway provisions it and injects the connection string.
- Add the API service — point it at
apps/api, set the start command, and reference the database variable. - Add the web service — point it at
apps/web, set the public API URL as an env var. - Run migrations on deploy (Prisma/Drizzle migrate as a release step).
- Add health checks and you're live, with automatic deploys on every push.
Railway also shipped one-click high-availability Postgres (Patroni-based) in early 2026, so you can move from a single instance to a replicated setup without re-architecting.
What Railway actually costs
Railway's usage-based billing confuses people, so here's the plain version (as of June 2026):
| Component | How it's billed | Typical small prod |
|---|---|---|
| Plan base — Hobby | $5/mo (includes $5 usage credit) | $5 |
| Plan base — Pro | $20/mo (includes $20 usage credit) | $20 |
| Compute — RAM | $10 per GB-month | a few $ |
| Compute — CPU | $20 per vCPU-month | a few $ |
| Egress | $0.05 per GB | usually pennies |
A small production app (modest API + Postgres) commonly lands around $5–20/month all-in, because the included plan credit absorbs most early usage. You pay for what you actually run, not idle capacity.
Railway vs Vercel — when to split
Vercel is superb for the Next.js frontend specifically. The trade-off:
- All on Railway — frontend, API, and database in one project. Simplest ops, one bill, easy private networking between API and DB.
- Vercel + Railway — Next.js on Vercel for best-in-class edge/frontend, NestJS + Postgres on Railway. Slightly more setup, but you get Vercel's frontend DX.
For most teams shipping a cohesive product, keeping everything on Railway is the lower-friction choice. Split only when you specifically want Vercel's frontend platform.
Production checklist
- Environment variables managed per service (no secrets in code)
- Database migrations run automatically on deploy
- Health-check endpoints on the API
- Shared types package imported by both apps
- Connection pooling configured for Postgres
- High-availability Postgres for anything business-critical
- CI runs tests before deploy
This is close to our default 2026 stack — the same backbone behind the web apps and data-heavy dashboards we ship.
Frequently asked questions
How much does it cost to host a full-stack app on Railway? A small production app (API + Postgres) typically runs around $5–20/month. Railway charges a plan base (Hobby $5, Pro $20, each including matching usage credit) plus usage: $10/GB-month RAM, $20/vCPU-month CPU, and $0.05/GB egress.
Should I use Next.js and NestJS together, or just Next.js? Use just Next.js for simple apps. Add NestJS when your backend has real domain logic — auth, jobs, queues, integrations — where its modular, testable structure pays off over ad-hoc API routes.
Railway or Vercel for a full-stack app? Railway runs your frontend, API, and database together with simple ops and private networking. Vercel is best for the Next.js frontend specifically. Many teams keep everything on Railway; split to Vercel only for its frontend platform.
What's the latest NestJS version in 2026? NestJS is on the v11.x line in mid-2026, with v12 — moving to ESM and modern tooling — on the roadmap for later in the year.
Want this stack built and deployed for you? It's our default for full-stack apps. Book a free call with our web team.