Deploying a Next.js app without a Vercel account
Next.js is built to run on Vercel, which is a fine default until the bill starts tracking function invocations and edge requests instead of a flat number you can actually predict. The framework itself doesn’t require that — a next build followed by next start is just a Node process, which means it runs the same way anywhere a Node process can run, including on a server you own.
What actually happens on push
There’s no Next.js-specific configuration to write. Railyard reads package.json, detects the build script, and for a Next.js dependency specifically runs next build before starting the app with next start — the same detection that handles Nuxt and SvelteKit too, since the pattern (framework declares a build step, framework provides its own start command) is shared across all three. The packager — npm, pnpm, yarn or bun — is picked up from whichever lockfile is already in the repo, not guessed.
railyard create my-app https://github.com/me/my-appor paste the same Git URL into the dashboard once GitHub’s connected. Either way, every push after the first one rebuilds and redeploys automatically — the same git push workflow Vercel popularized, running against infrastructure that isn’t metered per request.
The one decision worth making deliberately: static or server
A Next.js app that uses output: "export" (or never touches a server-only feature — no API routes, no server actions, no ISR) produces pure static output. That’s a meaningfully different, cheaper thing to run than a server-rendered app, and Railyard treats it as one: a static export is served with no Node process behind it at all, while anything using server-side rendering, API routes or server actions keeps the full next start process alive. Knowing which kind of app is actually being shipped — before worrying about hosting cost — is the useful first question, not an afterthought.
Environment variables work the same way they do locally
process.env.WHATEVER reads whatever’s set under Variables, or via railyard env:set my-app KEY=VALUE from the CLI — the same build artifact runs unchanged from a preview branch through production, so a staging deploy is never running a different bundle than what ships. A database add-on resolves to ${{postgres.RAILYARD_PRIVATE_URL}}, scoped per environment automatically.
Background work doesn’t need a second app
If the app needs a queue worker alongside the web process — emails, webhooks, anything that shouldn’t block a request — that’s a second script in the same package.json, not a second repo or a second deploy: npm run worker is picked up as its own scalable process type next to web, sharing one build.
See the full Node.js reference: Node.js docs, Deploying from a repository.