Deploy Next.js + Auth.js | Open Source Starter with Redis Sessions
Next.js starter with Auth.js sign-in and Redis-backed sessions
Just deployed
nxnext
Just deployed
Redis
Just deployed
/data
Deploy and Host Next.js with Auth.js on Railway
A Next.js starter with authentication already working: Auth.js for sign-in and sessions, Redis behind an HTTP API for session storage and rate limiting, and an Nx workspace layout ready for a second app or a shared library.
About Hosting Next.js with Auth.js
Three services. The Next.js app builds from a Git repository; Redis stores sessions on a persistent volume; and a small HTTP layer in front of Redis speaks the Upstash REST protocol, so the app talks to it with @upstash/redis and would work unchanged on an edge runtime later.
Session secrets are generated per deployment and the public URL is wired into the auth configuration.
Common Use Cases
- Starting a Next.js product with auth done: Sign-in, sessions and a session store that survives redeploys, on day one.
- Rate limiting and short-lived state: Redis over HTTP, usable from route handlers and from edge runtimes alike.
- A monorepo from the start: The Nx layout means the second app or the shared UI library does not require restructuring the project.
Dependencies for Next.js with Auth.js Hosting
Deployment Dependencies
- The nxnext starter, built from Git
- Auth.js for authentication
- Redis Stack on a Railway volume
- The serverless-redis HTTP layer, Upstash-compatible
Implementation Details
AUTH_SECRET is generated per deployment and signs session cookies; AUTH_URL comes from the public domain. Changing the domain means changing both, plus any OAuth callback URLs at the provider.
The app reaches Redis through UPSTASH_REDIS_URL and UPSTASH_REDIS_TOKEN, which point at the HTTP service. That indirection is deliberate: the same code runs against Upstash, against this deployment, or against a local Redis, with only the URL changing.
RAILWAY_DOCKERFILE_PATH points the build at apps/web/Dockerfile, because in an Nx workspace the deployable app is not at the repository root.
ENABLE_ALPINE_PRIVATE_NETWORKING is set on the Alpine-based services — musl's resolver needs it to see Railway's IPv6 private network at all.
Sign-in providers are not configured out of the box. Add the credentials for whichever provider you want in the Auth.js config and as service variables; the deployment runs without them, but there is nothing to sign in with.
Why Deploy Next.js with Auth.js on Railway?
Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.
By deploying Next.js with Auth.js on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.
Resources: the Next.js server dominates at roughly 200–400 MB; Redis and the HTTP layer are small. On the order of $8–12 a month for the three.
Template Content