Node.js hosting has moved well past renting a bare server and configuring it by hand. In 2026 the practical question is not where can I put a Node process, but which platform gives me a git-push deploy, a managed database, HTTPS, and a bill I can predict, without asking me to run my own infrastructure.
This guide covers what to look for in Node.js hosting, how modern deploys actually work, and how to run an Express, NestJS, or Next.js application in production, including what it costs once real traffic arrives.
The short answer: for most teams in 2026, the best Node.js hosting is a platform-as-a-service that deploys straight from GitHub, gives you a managed PostgreSQL database, and bills for the compute you use. Out Plane does this with plans from $9 a month, a 14 day free trial, compute metered by the minute, and automatic HTTPS, so you can host a Node app without touching servers or YAML.
What to Look for in Node.js Hosting
Not all Node.js hosting is the same. Four things separate a platform you can grow on from one you will migrate off in six months.
- Git-push deploys. You connect a repository, push, and the platform builds and ships the new version. No manual
scp, no PM2 config, no reverse-proxy setup. - No cold starts. At least one instance stays up between requests, so the first visitor after a quiet night waits no longer than the hundredth. Platforms that sleep idle apps make your quietest users wait the most.
- A managed database next to your app. Most Node apps need Postgres or Redis. Provisioning one from the same platform, with backups handled for you, removes an entire category of work.
- Predictable pricing. A fixed monthly base with usage metered by the minute, and no surprise minimums, keeps the cost proportional to what your app actually does.
If a host is missing any of these, you will feel it the moment your app has real users.
How Modern Node.js Deploys Work
A modern Node.js host builds your app from source and runs it as a container. The flow is the same whether you use Express, Fastify, NestJS, or a Next.js server:
- Connect your repository. The platform reads your
package.json, detects Node, installs dependencies, and runs your build. - Bind to the right host and port. Your server must listen on
0.0.0.0and the port the platform provides throughprocess.env.PORT. This one line is the most common reason a first deploy fails to receive traffic. - Push to deploy. Each push to your connected branch triggers a new build and a zero-downtime release.
On Out Plane, both Cloud Native Buildpacks and a custom Dockerfile are supported, so a plain Node app deploys with zero configuration, and a more complex setup deploys exactly the way you define it. Buildpacks read your package.json, pick a Node version, install dependencies, and run your build and start scripts. If you already maintain a Dockerfile, the platform uses it verbatim, which is the path to take when you need a specific base image, a native dependency, or a multi-stage build.
Binding to 0.0.0.0 and process.env.PORT
The single most common reason a first Node.js deploy fails is the listen line. Locally, app.listen(3000) binds to localhost, which is fine on your laptop. In a hosted container, requests arrive on a network interface that localhost does not cover, and the platform assigns the port through an environment variable rather than letting you hardcode it. The Node.js documentation defines process.env as the object that exposes these injected values at runtime, and process.env.PORT is where the platform tells your app which port to use.
An Express app should read the port from the environment and bind to every interface:
const express = require('express');
const app = express();
const port = process.env.PORT || 3000;
app.get('/', (req, res) => {
res.send('Hello from Node.js');
});
// Bind to 0.0.0.0, not localhost, and use the injected port.
app.listen(port, '0.0.0.0', () => {
console.log(`Server listening on 0.0.0.0:${port}`);
});The || 3000 fallback keeps the app runnable locally while deferring to process.env.PORT in production. Get this one line right and the platform can route traffic to your server; get it wrong and the deploy will build cleanly but never receive a request.
Hosting Express, NestJS, and Next.js
The three most common ways to ship a Node.js app each deploy the same way but expose the port line a little differently.
Express and Fastify
Minimal frameworks give you the listen call directly, so you control the host and port as shown above. There is no build step for a plain Express API. The platform installs dependencies and runs node index.js or your start script. This is the lightest possible deploy and a good default for REST APIs, webhooks, and background workers.
NestJS
NestJS wraps the HTTP server, so the port lives in main.ts. Pass both the port and the host to listen:
import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';
async function bootstrap() {
const app = await NestFactory.create(AppModule);
await app.listen(process.env.PORT ?? 3000, '0.0.0.0');
}
bootstrap();Because NestJS compiles TypeScript, make sure your build script runs nest build and your start script runs the compiled output (node dist/main). Buildpacks pick this up from package.json automatically.
Next.js
A Next.js app has two shapes. A static or hybrid export can run on a frontend platform, but a Next.js app with server-side rendering, API routes, or middleware is a long-running Node server and belongs on a platform built to keep a process alive. next start already honors process.env.PORT, so no code change is needed. Deploy the repository, set the build command to next build, and the server binds correctly on its own.
The takeaway across all three: the deploy model is identical, and the only variable is where the port line lives.
Best Node.js Hosting Options in 2026
The realistic choices for hosting a Node.js app fall into three groups: platform-as-a-service, raw virtual servers, and frontend-focused platforms.
| Option | Deploy model | Free tier | Managed database | Best for |
|---|---|---|---|---|
| Out Plane (PaaS) | Git push + Docker | 14 day trial, then from $9/mo | PostgreSQL and Redis | Full-stack Node apps that need a database |
| Traditional PaaS | Git push | Trial only, on most | Add-on, billed separately | Simple apps within trial limits |
| Virtual server (VPS) | Manual / SSH | None | Self-managed | Teams that want full control |
| Frontend platforms | Git push | Generous for static | Limited or external | Static sites and serverless functions, not long-running Node servers |
For a long-running Node.js server that holds connections, runs background work, or talks to a database, a platform-as-a-service is usually the best fit. A VPS gives you the most control but hands you the operating system, security patching, and process management. Frontend platforms are excellent for static output but are not built to run a persistent Node process.
Free Node.js Hosting
Free Node.js hosting is real, but the details matter. Many "free" offers are 30-day trials that convert to a monthly minimum, which is not the same as a tier your project can live on.
Out Plane does not run a free tier. Starter and Pro each open with a 14 day free trial, and after that Starter is $9 a month with 3 apps, 1 managed database, 5 domains, and $9 of usage already included in the price. What you never pay extra for is the surrounding work: SSL certificates, custom domains, CI/CD, logs, monitoring, and bandwidth come with every plan. Because at least one instance stays up, a low-traffic Express or NestJS app has no cold starts and answers its first request of the day as fast as its last.
Hosting a Node.js App with a Database
A Node.js API almost always needs somewhere to store data. Rather than running your own database server, you provision a managed one from the same platform.
Out Plane provides managed PostgreSQL with automated backups, point-in-time recovery, read replicas, and connection pooling, plus managed Redis for caching, sessions, and queues. Your app reads the connection string from an environment variable, and compute is metered by the minute, so a quiet service costs less than an always-busy one.
Connecting from Node is a few lines. With the pg driver, read the connection string from the environment rather than committing it to source:
import { Pool } from 'pg';
const pool = new Pool({
connectionString: process.env.DATABASE_URL,
});
export async function getUser(id) {
const { rows } = await pool.query(
'SELECT id, email FROM users WHERE id = $1',
[id],
);
return rows[0];
}The Pool object matters at scale. A managed database limits how many raw connections it will accept, and a pool lets many requests share a small, fixed number of connections instead of opening one per request. When you run several app instances, connection pooling on the database side keeps the total under the limit even as each instance maintains its own pool. Redis follows the same pattern: read the URL from process.env.REDIS_URL and reuse a single client across requests.
For step-by-step language guides, see how to deploy an Express.js application or deploy a NestJS application.
Environment Variables and Secrets
Configuration that changes between local, staging, and production belongs in environment variables, not in your repository. Database URLs, API keys, and third-party tokens are set on the platform and injected into the process at runtime, where your code reads them through process.env. This keeps secrets out of Git and lets you rotate a key without a code change.
Two practical rules keep this clean. First, never commit a .env file with real credentials; keep a .env.example with blank placeholders so teammates know which keys are required. Second, read every secret through process.env and fail fast at startup if a required one is missing, so a misconfigured deploy stops loudly instead of erroring on the first request. On Out Plane you set these values in the console or through the API token and browser terminal, and they are available to every instance of your app without redeploying your image.
Scaling a Node.js App
Node.js runs your JavaScript on a single thread, so a single instance is bounded by one CPU core for compute-heavy work. Scaling a Node app therefore means running more instances, not a bigger single process. There are two axes.
Horizontal scaling adds instances behind a load balancer. Out Plane runs Node apps across multiple instances with automatic load balancing, and you set the instance count yourself up to your plan ceiling: 1 on Starter, 5 on Pro, 10 on Growth. The platform does not add or remove instances for you, so size for your peak and adjust when the metrics say so. For this to work your app must be stateless: store sessions in Redis or Postgres rather than in process memory, so any instance can serve any request. Instances stay up rather than sleeping, so there are no cold starts at any instance count.
Geographic scaling places instances near users. Out Plane does not do this. Every deployment runs in one region, Nuremberg in Germany, which keeps your application and its data inside the EU and makes data residency simple to answer for. For patterns and trade-offs, see horizontal scaling for Node.js.
A common migration path is: start with one instance on Starter, add instances once real traffic arrives, move session and cache state into managed Redis, and add a read replica to your PostgreSQL database when read load grows. Each step is a configuration change, not a rebuild.
How to Choose
If you are hosting a personal project or an early-stage app, start on the smallest plan that fits and keep the option to grow. If you are running a full-stack Node app with a database, choose a platform that provisions both from one place. If you are moving off a platform whose pricing became unpredictable, compare the model directly. A Railway alternative with a fixed monthly base and per-minute compute billing often lowers the bill for low-traffic services.
Ready to deploy? Host your Node.js app on Out Plane and start with a 14 day free trial.
Frequently Asked Questions
What is Node.js hosting?
Node.js hosting is a service that runs your server-side JavaScript application and serves it to users over the internet. Modern Node.js hosting builds your app from a Git repository, runs it as a container, provides a managed database, and handles HTTPS, deploys, and scaling so you never manage a server.
What is the best hosting for a Node.js app?
The best Node.js hosting for most developers is a platform-as-a-service that deploys from GitHub, provides a managed database, and bills for usage. It removes server management while keeping full control of your code. Out Plane offers this with plans from $9 a month, managed PostgreSQL and Redis, and compute metered by the minute.
Is there free hosting for Node.js?
Not on Out Plane. Starter and Pro each begin with a 14 day free trial, and after that Starter is $9 a month with a usage allowance included in the base price. Platforms that do offer a permanent free tier usually put idle apps to sleep. Out Plane keeps at least one instance running instead, so a low-traffic Node.js app has no cold starts.
How do I deploy a Node.js app?
Connect your GitHub repository, make sure your server listens on 0.0.0.0 and process.env.PORT, and push. The platform installs dependencies, builds your app, and releases it with zero downtime. Each subsequent push deploys the new version automatically.
Why does my Node.js app deploy but receive no traffic?
The most common cause is listening on localhost or a hardcoded port. A hosted Node app must bind to 0.0.0.0 and the port provided in process.env.PORT. Fix that one line and the platform can route requests to your server.
Can I host a Node.js app with a database?
Yes. On Out Plane you provision managed PostgreSQL or Redis alongside your app and read the connection string from an environment variable. Backups, point-in-time recovery, read replicas, and connection pooling are handled for you, and compute is metered by the minute.
Do I need a Dockerfile to deploy a Node.js app?
No. Cloud Native Buildpacks read your package.json, choose a Node version, install dependencies, and run your build and start scripts, so a standard Node app deploys with zero configuration. Add a Dockerfile only when you need a specific base image, a native dependency, or a custom multi-stage build. When present, the platform uses it exactly as written.
Can I host a Next.js app that uses server-side rendering?
Yes. A Next.js app with server-side rendering, API routes, or middleware is a long-running Node process and runs well on a platform-as-a-service. next start already reads process.env.PORT, so no code change is needed. Static-only exports can also run on a frontend platform, but a server-rendered Next.js app belongs where a persistent process stays alive.
Does Node.js hosting include a custom domain and HTTPS?
Yes. On Out Plane you point your own domain at the app and HTTPS is provisioned and renewed automatically, so every deploy is served over TLS without you managing certificates. Until you attach a domain, the app is reachable on a generated URL that also serves over HTTPS.
How much does Node.js hosting cost?
Out Plane starts at $9 a month for Starter and $29 for Pro, and each plan opens with a 14 day free trial and includes a monthly usage allowance in the base price. Compute is metered by the minute beyond that allowance, so you pay in proportion to actual usage. For current rates, see /pricing.
