---
title: "Deploy Node.js HTTP Server — Zero Dependencies"
description: "Bare Node http module server — no Express, no npm install"
category: "Starters"
url: https://railway.com/deploy/node-http-zero-deps
---

# Deploy Node.js HTTP Server — Zero Dependencies

Bare Node http module server — no Express, no npm install

**[Deploy Node.js HTTP Server — Zero Dependencies on Railway](https://railway.com/template/node-http-zero-deps)**

- **Creator:** SilverBanana
- **Category:** Starters
- **Total deploys:** 3

## Template content

### NodeJS https://devicons.railway.com/i/nodejs.svg

- **Source:** railwayapp-templates/http-nodejs

## Documentation

# Deploy and Host a Node.js HTTP Server on Railway

A minimal HTTP server built on Node.js's built-in `http` module — no Express, no framework, no dependencies at all. Just the standard library, a `package.json` with an empty dependency list, and a server that starts instantly.

If you want a clean foundation without inheriting a framework's opinions or its dependency tree, this is it.

---

## What This Template Deploys

| Service | Purpose |
| --- | --- |
| **Node.js HTTP Server** | A single Node process serving HTTP on Railway's assigned port |

One service, one file, zero npm packages. Railway handles TLS, routing, and the public domain.

---

## About Hosting a Node.js HTTP Server

Node ships with a complete HTTP server in its standard library. Most starters wrap it in Express anyway, which brings in a dependency tree, a build step, and a routing abstraction you may not need. For a small API, a webhook receiver, or a health-check endpoint, `http.createServer` is genuinely enough.

Going dependency-free has practical consequences beyond ideology. There is no `npm install` at build time, so deploys are fast. There is no third-party code in your runtime, so there is no supply-chain surface and no dependency audit to keep clean. Cold starts are as quick as Node itself. And the whole server is short enough to read in one sitting, which matters when you're the person maintaining it.

Railway supplies the port through the `PORT` environment variable and terminates TLS in front of the service, so your server binds to `0.0.0.0` on that port and stays plain HTTP internally. Push to your repo and Railway rebuilds and redeploys automatically.

Typical cost: **~$5/month** on Railway's Hobby plan for a single always-on service — and because there are no dependencies to install or framework overhead to run, it uses very little of it.

---

## How It Compares

| | Node `http` (this template) | Express | Fastify | Hono |
| --- | --- | --- | --- | --- |
| Dependencies | 0 | ~30 transitive | ~25 transitive | Minimal |
| Install step | None | `npm install` | `npm install` | `npm install` |
| Routing | Manual | Built-in | Built-in | Built-in |
| Middleware | Manual | Rich ecosystem | Rich ecosystem | Growing |
| Cold start | Fastest | Fast | Fast | Fast |
| Best for | Small APIs, webhooks | General apps | High throughput | Edge runtimes |

Express and Fastify earn their weight once you need routing, middleware, and an ecosystem. Below that threshold, the standard library does the job with nothing to install and nothing to audit.

---

## Deploy in Under 5 Minutes

1. Click **Deploy on Railway** and wait for the build (~30 seconds — there's nothing to install)
2. Open the generated Railway domain to see the server responding
3. Edit the handler to add your own routes and logic
4. Push to your repo — Railway rebuilds and redeploys automatically
5. Add environment variables in the Variables tab as your app needs them

No framework to learn, no build config, no dependency lockfile to maintain.

---

## Common Use Cases

- **Webhook receivers** — accept and process incoming POSTs from Stripe, GitHub, or any service without framework overhead
- **Small JSON APIs** — a handful of endpoints where a full framework would be more setup than the app itself
- **Health checks and status endpoints** — a lightweight always-on service for monitoring other systems
- **Microservices** — a minimal container per service, keeping each one small and independently deployable
- **Learning Node fundamentals** — see how HTTP servers, requests, and responses work without a framework in the way
- **Proxy and redirect services** — simple request forwarding or URL redirection with no extra machinery

---

## Configuration

| Variable | Required | Description |
| --- | --- | --- |
| `PORT` | Auto-injected | Railway assigns the port — the server must bind to it, not a hardcoded value |
| `NODE_ENV` | Optional | Set to `production` to disable development behaviour in any code you add |
| `HOST` | Optional | Bind address (default `0.0.0.0`, required for Railway to route traffic) |

> **Bind to `process.env.PORT`, not a fixed port.** Railway assigns the port at runtime. A server hardcoded to `3000` will not receive traffic. This template reads it correctly — keep that behaviour when you edit the handler.

> **Bind to `0.0.0.0`, not `localhost`.** Binding to `localhost` makes the server unreachable from outside the container.

---

## Dependencies for Node.js HTTP Server Hosting

- Railway account — Hobby plan (~$5/month) runs a single always-on service
- Nothing else. No npm packages, no database, no external services

### Deployment Dependencies

- [Node.js HTTP Module Documentation](https://nodejs.org/api/http.html)
- [Railway Node.js Guide](https://docs.railway.com/guides/nodejs)
- [Railway Variables Documentation](https://docs.railway.com/guides/variables)

### Implementation Details

The service runs a single Node.js process using `http.createServer` from the standard library. `package.json` declares no dependencies, so Railway's build step has nothing to install — builds complete in seconds and the resulting image is small.

The server binds to `process.env.PORT` on `0.0.0.0`, which is what Railway requires to route traffic to the container. Railway terminates TLS at the edge, so the process itself speaks plain HTTP and needs no certificate handling.

Request handling is a single function you extend directly. There is no router, no middleware chain, and no framework lifecycle — you inspect `req.method` and `req.url` and respond. That is more manual than Express, and deliberately so: the tradeoff buys you a runtime with no third-party code in it.

If your app grows past the point where manual routing is comfortable, moving to Express or Fastify is a small change, since the underlying `http` server is what those frameworks wrap anyway.

---

## Frequently Asked Questions

**Why no Express?** For small services, Express adds a dependency tree and a build step to solve a problem the standard library already handles. This template targets the case where you want an HTTP endpoint and nothing else. Add a framework when routing and middleware start earning their keep.

**Does it really have zero dependencies?** Yes. `package.json` lists no dependencies, so there is no `npm install` at build time, no lockfile to maintain, and no third-party code in the runtime.

**Why must I use `process.env.PORT`?** Railway assigns the port at runtime rather than using a fixed one. A server hardcoded to a specific port will start but never receive traffic. This is the most common reason a Node deployment appears to run yet returns nothing.

**Do I get HTTPS?** Yes, automatically. Railway terminates TLS at the edge, so your service speaks plain HTTP internally while being served over HTTPS publicly.

**How do I add routes?** Inspect `req.method` and `req.url` in the request handler and branch accordingly. For a handful of endpoints this stays readable; past that, a router or framework is the better tool.

**Can I add a database later?** Yes. Add a Railway Postgres, MySQL, or Redis service and connect via a reference variable. You'd then add a database driver, which is your first dependency — a deliberate choice rather than an inherited one.

**Is this production-ready?** The server itself is; Node's `http` module is what every framework builds on. Whether it suits your app depends on scope — you're responsible for routing, error handling, and input validation that a framework would supply.

---

## Why Deploy a Node.js HTTP Server 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 a zero-dependency Node.js HTTP server on Railway you get the smallest sensible starting point for a web service — fast builds with nothing to install, automatic HTTPS, push-to-deploy, and a runtime containing only code you wrote. Start minimal, add exactly what you need, and skip the framework until you actually want one.

## Similar templates

- [open-excalidraw](https://railway.com/deploy/open-excalidraw) — Self-hostable collaborative drawing built on Excalidraw
- [caring-vibrancy](https://railway.com/deploy/caring-vibrancy) — Deploy and Host caring-vibrancy with Railway
- [Appsmith](https://railway.com/deploy/appsmith-1) — Low-code platform for internal tools, dashboards, and admin panels.

Open this page in a browser: https://railway.com/deploy/node-http-zero-deps