Node.js hosting free of charge for the apps that grew out of localhost: connect the GitHub repository, and SnapDeploy builds a production image, starts the app on its own HTTPS address and redeploys on every push. No Dockerfile needed when package.json has a start script.
Free tier: 4 containers, 512 MB each, 100 hours a month, 10 deploys a day. No credit card. Always-On from $12 a month when the API has to answer 24/7.
Last verified 28 September 2026 against the free-tier docs, the deployment code and each competitor's own documentation.
Most lists of free Node.js hosting still name Heroku's free tier, which ended in November 2022, or Glitch, which stopped hosting apps in July 2025. This table is what each provider's own documentation said on 28 September 2026.
| Host | Free tier for a Node server | RAM / CPU | Sleeps after | Card at sign-up | Cheapest 24/7 |
|---|---|---|---|---|---|
| SnapDeploy | 4 containers, 100 container-hours/month, 10 deploys/day; no expiry | 512 MB / 0.25 vCPU | 15 min idle; ~60 s wake on a browser visit | No | $12/month Always-On Small; $1 Sprint Pack for 24 h |
| Render | 750 instance-hours/month per workspace; 5 GB bandwidth on the Hobby workspace | 512 MB / 0.1 CPU | 15 min without inbound traffic; about a minute to wake | No | $7/month Starter |
| Railway | $5 one-time trial credit for 30 days, then a Free plan with $1/month of credit | 1 GB / shared vCPU on the trial | Credit runs out rather than sleeping | No for the trial; yes for Hobby | $5/month Hobby plus usage |
| Koyeb | 1 free web service, Frankfurt or Washington only | 512 MB / 0.1 vCPU | 1 h idle, scales to zero | Yes, with a $29 pre-authorisation hold | About $1.61/month (256 MB) on a $29/month Pro plan that includes $10 of compute |
| Fly.io | No free tier since October 2024; trial of 2 machine-hours or 7 days, then apps stop | Up to 2 vCPU / 4 GB on the trial | Auto-stop after 5 min on the trial | Yes, to keep anything running | About $1.94/month (256 MB shared) |
| Vercel Hobby | Serverless functions, not a long-running Node server; 100 GB data transfer, 100 deployments/day | Function memory, not a VM | Functions are on demand | Not stated | Non-commercial use only on Hobby |
Sources: render.com/docs/free and render.com/pricing; docs.railway.com free-trial and plans pages; koyeb.com docs and pricing; fly.io free-trial and pricing docs; vercel.com/docs/limits and fair-use guidelines. Free Node.js hosting options change often; the date above is the one that counts.
Read from the build code, not from a brochure. Every step below runs on AWS CodeBuild and the image is pushed to a private registry.
.nvmrc first, then engines.node in package.json. Node 18, 20 and 22 come from the platform's own mirror; other versions from Docker Hub.yarn.lock selects Yarn, a pnpm-lock.yaml selects pnpm, otherwise npm. Dependencies install in a builder stage.build script it runs in the builder: TypeScript compiled with tsc, a Vite front end bundled next to an Express server, a Next.js production build.NODE_ENV=production, PORT set to the container port, and the app running as a non-root user.npm start, yarn start or pnpm start. A TypeScript entry such as node server.ts is rewritten to run through tsx or ts-node when one is in package.json./actuator/health, /health, /healthz, /api/health and /, accepting any 2xx or 3xx, then falls back to a connection check on the port. The URL goes live when it passes; later deploys start the new task beside the old one and switch traffic only after it passes too.The same two rules as on every container host: listen on the port you are given, and listen on all interfaces.
// server.js
const express = require("express");
const app = express();
app.get("/health", (req, res) => res.json({ ok: true }));
app.get("/", (req, res) => res.send("Hello from SnapDeploy"));
const port = process.env.PORT || 3000;
app.listen(port, "0.0.0.0", () => console.log(`listening on ${port}`));
A server bound to 127.0.0.1 passes its own tests and fails every health check in the cloud. This is the most common first-deploy failure in the build logs.
{
"name": "my-api",
"engines": { "node": "20" },
"scripts": { "start": "node server.js" },
"dependencies": { "express": "^4.19.0" }
}
No Dockerfile is required. If you prefer one, it is used as written; a multi-stage example is on the Docker hosting page.
Sign in with email or GitHub, choose Deploy from GitHub, pick the repository and branch, and add environment variables in the dashboard rather than in the code. Values whose names look like secrets are masked; PORT is reserved for the platform. The build log streams live and the API is at https://<name>.containers.snapdeploy.app when the health check passes, usually within a few minutes.
Every push to the linked branch rebuilds and redeploys. Other branches are ignored. A failed build never replaces the running version.
Searches for free nodejs hosting, free node js hosting or free node.js hosting all land on the same handful of names, and the answer is the same for every one of them. A Node process that never exits costs the host money every minute it runs. Every free tier that still exists pays for that by stopping the process when nobody is using it: SnapDeploy after 15 minutes without traffic, Render after 15 minutes without inbound traffic, Koyeb after an hour. The next visitor waits while it starts again, about 60 seconds here.
For a portfolio API, a class project or a prototype someone opens a few times a day, that is fine, and the free tier's 100 container-hours a month go a long way because sleeping time does not count. For anything a mobile app, a front end or a webhook sender depends on, sleep is not fine, and no free tier fixes that. On SnapDeploy the fix is per container: Always-On Small at $12 a month keeps one API awake 24/7 with no deploy limit, while the rest of the account stays free. A $1 Sprint Pack does the same for a single 24-hour window, for a demo or a launch day.
Two things a sleeping free container cannot do: hold a WebSocket open, and answer a cron job or a webhook that arrives while it is asleep, because scripts do not trigger the wake. Both belong on Always-On.
Detection is by dependencies and scripts, so most repositories deploy as they are. The best hosting for Node.js depends less on the framework than on whether the process must stay up, which is the Always-On question above.
Detected as server frameworks and started with the start script. Small (512 MB) is enough for most APIs.
Built with the build script and run as a Node server for server-side rendering. Pages with heavy rendering are happier on Medium (2 GB, 1 vCPU). Static exports are served by nginx instead.
A tsc build runs in the builder stage; a node server.ts start command is rewritten to tsx or ts-node when one is declared.
Treated as a static site: built, then served by nginx. See static and HTML hosting.
Managed PostgreSQL, MySQL, MariaDB, MongoDB, Redis and RabbitMQ add-ons, each with a $1 12-hour trial; or an external database through a connection string in the environment.
Both come with Always-On: your domain with a certificate issued for you, and Socket.IO or raw WebSockets held open.
Yes. SnapDeploy's free tier runs up to 4 containers with 100 container-hours a month and 10 deploys a day, and sign-up needs only an email address or a GitHub account. Render's free web services also need no card. Railway's trial needs no card but its paid plans do; Koyeb and Fly.io require a card before anything runs.
Not on any free tier we checked. Free Node.js hosting sleeps: SnapDeploy after 15 minutes without traffic, Render after 15 minutes, Koyeb after an hour. A Node app that must stay up needs a paid always-on option; on SnapDeploy that is Always-On Small at $12 a month per container, or a $1 Sprint Pack for a single 24-hour window.
Node 18, 20 and 22 come from the platform's own image mirror; other versions are pulled from Docker Hub. The version is read from a .nvmrc file first, then from the engines.node field in package.json.
No. With a package.json that has a start script, the platform generates a two-stage Dockerfile: it installs dependencies with npm, yarn or pnpm depending on the lockfile, runs the build script if there is one, and starts the app with NODE_ENV set to production as a non-root user. Commit your own Dockerfile when you need system packages or a custom base image.
Not strictly. The health check tries /actuator/health, /health, /healthz, /api/health and then /, accepting any 2xx or 3xx response, and finally checks that the port accepts connections. An Express API that answers 404 on / still passes on the connection check. A /health route that returns 200 is still the cleanest choice.
Yes. Next.js is built with its build script and run as a Node server; NestJS, Fastify, Koa and Hapi are detected as server frameworks and started with their start script. A Vite or Create React App project with no server is served as a static site instead.
On Always-On containers, yes. The free edge does not hold a WebSocket open, so a Socket.IO app, a live dashboard or a chat server belongs on Always-On, from $12 a month per container.
Managed PostgreSQL, MySQL, MariaDB, MongoDB, Redis and RabbitMQ are add-ons wired into the container's environment, each with a $1 12-hour trial. An external database such as Neon or MongoDB Atlas works too: put its connection string in the container's environment variables.
Free tier, no credit card, no Dockerfile needed. Always-On from $12 a month when the API must answer 24/7.
Deploy Free TodayThe first managed container PaaS to offer a one-time 24-hour Always-On pass under $5. Unlimited deploys + Always-On for one Small (512 MB) container — including WebSockets & real-time apps. No subscription, no auto-renewal. Stack two for 48 hours.
Need a managed database too? DB Sprint Pack — ₹99 / 12h for Postgres, MySQL, MariaDB, Mongo, Redis, or RabbitMQ.