Deploy Next.js Without a VPS: Railway vs Render vs Droplet
Skip SSH and nginx for a side-project Next.js app. Compare Railway, Render, Vercel and a VPS, then ship from Git after minifying assets in the browser.
You finished the app. Now you need a URL.
A local next dev is not production. Renting a VPS means SSH, a process manager, TLS and a night spent on nginx. For many side projects, all you need is Git going in and HTTPS coming out, which is the job of a Heroku-style PaaS. This guide compares that route (worked example: Railway) with Vercel, Render and a classic Droplet, so you can host a Next.js app without becoming a sysadmin.
When a VPS is overhead you do not need yet
A platform-as-a-service builds from your repo, runs the process, terminates TLS, and restarts on crash. You still own env vars, spend, and whether the app is ready for production. You do not own patching Ubuntu.
Improvements
You still minify and compress assets, keep secrets out of Git and watch Core Web Vitals. With next start, Next.js already compresses responses with gzip by default; for Brotli or a CDN, see our guide to gzip and Brotli on the origin. What a PaaS saves you is writing the nginx block.
SEO Benefits
Ship a Next.js app on Railway from Git
Railway builds your repository with Railpack by default (Nixpacks is also supported) and runs the start script from package.json, so a standard Next.js app needs no extra setup. Connecting a GitHub repository is the simplest route. The referral link above currently adds $20 in credits for you on signup. That is Railway's offer, not a FastMinify coupon, and the amount can change.
1. A repository that builds on its own
Make sure package.json has build and start scripts (next build and next start for a standard app) and that the lockfile is committed. Keep .env out of Git and set the variables in the Railway interface.
2. Create the project from GitHub
In Railway, create a new project, choose deploy from GitHub and pick the repository. The first deploy often fails on a missing environment variable, which is expected. Add DATABASE_URL or your API keys, then redeploy.
3. Generate a domain, then add your own
Use the generated *.up.railway.app URL to confirm the app boots. Attach a custom domain when you care about branding. TLS is issued for you.
4. Watch the first invoice, not the dashboard screenshot
At the time of writing, the Hobby plan costs $5 a month and includes $5 of usage; Pro costs $20 and includes $20. Beyond that, CPU, RAM and network egress are billed on usage, and a stopped service uses neither CPU nor RAM. Read Railway's pricing page before you leave a heavy Node process running around the clock.
Checklist
Use a Dockerfile when Railpack guesses wrong, you need a system package, or the image is already your source of truth. Lint it in the browser before the first deploy with the online Dockerfile linter, which applies a subset of Hadolint-style DL rules and does not run a build. Pair it with the Dockerfile formatter.
Pin the base image
Avoid FROM node:latest (DL3007) and pin a distro tag. Railway builds that Dockerfile when it sits at the repository root.
Listen on PORT
Do not hardcode 3000 in production when the platform injects PORT. next start reads the PORT variable by itself (3000 is only the default), and so does the standalone server.js, so -p $PORT is optional.
Mistakes that break a first PaaS deploy
An ENV AWS_SECRET= line in the Dockerfile or a committed .env file leaks into logs and image layers. Railway variables exist so that the image stays generic.
Keep in mind — Validate the .env syntax with the FastMinify ENV validator, and never paste live tokens into a public text field.
Vercel runs Next.js as serverless functions and routes requests for you. On Railway, you usually run next start as a long-lived Node process, and output: 'standalone' produces a self-contained server folder. Features tied to the Vercel platform, such as Edge Config or cron jobs, do not follow you to another host.
Keep in mind — Run a production build on your laptop before the first PaaS push.
A PaaS does not minify your client-side JS. If you ship an unminified bundle, LCP pays for it. Minify in the build (Next.js does this) and use the online JavaScript minifier for standalone scripts.
Keep in mind — Measure transfer on the generated Railway URL as well as on localhost.
Before you click deploy
FastMinify works in the browser tab, which helps when the repository is not cloned on this machine. Minify leftover CSS, lint the Dockerfile and check Compose if you still run Docker locally.
Railway bills usage beyond the credits included in your plan. A forgotten service that keeps 2 GB of RAM in use is how a side project turns into a surprise invoice. Stop unused services, or enable Serverless to put idle services to sleep (outbound traffic, such as an open database connection, keeps a service awake). A Droplet you forget to destroy is the same kind of mistake on a different dashboard.
PaaS vs Vercel vs a VPS
Vercel is the path of least resistance for a Next.js frontend. A VPS wins when you need a custom kernel, a mail server or SSH access. Railway sits in the middle, with Git deploys, usage-based billing and room for a worker and a database next to the app.
If you need
Start with
Railway is not the only answer
Use this as a map, not a ranking. Prices and free tiers change, so read the vendor's page before you commit.
Vercel
Built by the team behind Next.js, with the most direct support for the App Router, previews and Edge. A weaker fit if you need a long-running worker or a traditional database in the same project without extra vendors.
Pros:
Cons:
Render
Git deploys, web services, Postgres, background workers. Close cousin to Railway. Pick whichever dashboard you already have an account on.
Pros:
Cons:
DigitalOcean Droplet (or App Platform)
A Droplet is a VPS: you install Node, Caddy or nginx and certbot, and the machine is yours. App Platform is DigitalOcean's PaaS. A Droplet suits you if you already work over SSH and want a public IPv4 address you control.
Pros:
Cons:
FastMinify before the first production URL
Next.js production builds minify your app JS. They do not minify a random widget.js you copy into public/, nor a CMS snippet. Use the online JavaScript minifier and the online CSS minifier for those leftovers. When a vendor file turns unreadable in production, the online JavaScript unminifier makes it readable again.
If Railway or any other host builds a Dockerfile, lint it first. If you still use Compose on a laptop, validate Docker Compose online. Check your .env files for duplicate keys before you copy the names into the PaaS interface. All of these tools are listed on the online DevOps tools hub.
Ship the URL, keep the VPS for later
If the job is a Next.js side project plus maybe a worker, a PaaS is less work than a Droplet. Railway is the example we walked through (affiliate link). Vercel remains the default if you only need the Next.js frontend, and a VPS remains the right choice when you want SSH. Either way, minify leftovers and lint Dockerfiles in FastMinify: that part is free and local.
Prep the assets, then deploy wherever you chose
Related Articles
Paste a token and a JWKS to check an RS256, ES256 or HS256 signature in your browser. How kid picks the key, measured errors and the claims to check.
HTTP/2 and HTTP/3 change how files travel, not how big they are. Measured sizes, compile times and bundling tests show what minification still saves.
Convert a Unix epoch to a readable date and back, tell seconds from milliseconds, and avoid time zone, JWT and clock change traps, all in your browser.