Node.js runs the backend.

Most of the backends we ship run on Node.js, and the reason is leverage: one language across the whole stack. A developer writing a React component can also write the API route that feeds it, the webhook that processes a payment, and the job that sends the confirmation email, without switching languages, toolchains, or mental models. For API development that means we share validation logic and types across the network boundary, so the contract between client and server is enforced by the compiler rather than by documentation that drifts. We build APIs as Next.js route handlers and SvelteKit endpoints for app-embedded logic, and as standalone services when the backend needs its own deployment. The async I/O model handles many concurrent requests efficiently without threading complexity, and the npm ecosystem supplies battle-tested pieces for the parts we should not be reinventing. We run current Node LTS in production for the stability that matters at that layer.

Not every backend job fits neatly into a request that answers and exits. Plenty of the work we build in Node lives outside that cycle: webhook handlers that process events from Stripe or a CRM, background workers draining a job queue, scheduled tasks, email and PDF generation, and real-time servers holding open connections. We write these as Node services and then place them where they belong. Short, stateless request-response logic stays in serverless functions on the edge, close to the user. Anything that needs to stay alive, hold a connection, or run continuously moves to a persistent container on Railway, where a long-lived Node process is not fighting cold starts or execution-time limits. The single-language advantage carries through here too: the same team, types, and tests cover the API and the workers behind it, so the backend is one coherent system rather than two disconnected halves.