You can deploy a Node.js app on Render in under ten minutes if your project is on GitHub. Connect your repo, set your build and start commands, add environment variables, and you are live on an onrender.com URL with auto-deploys on every push.
That part is straightforward. What is not straightforward is what happens after you go live.
Render’s free tier sleeps your Node.js app after 15 minutes of inactivity. Cold starts take 30 to 60 seconds. Your free PostgreSQL database gets permanently deleted at day 91. File uploads vanish on every redeploy. WebSocket connections drop. And when something breaks in production, you cannot access a shell on the free plan to debug it.
This guide covers the complete deployment process for Node.js, Express, and Next.js on Render, and then covers every production limitation you will hit so you can make an informed decision before you commit. If you want to skip the manual setup entirely, Kuberns deploys your Node.js app in one click with its Agentic AI engine, no cold starts, and no infrastructure configuration required.
What Do You Need Before Deploying a Node.js App on Render?
Before you create a Render account or touch the dashboard, four things need to be in place. Missing any of them is the reason most first deploys fail.
A package.json with a Valid Start Script
Render looks for a start script in your package.json to know how to run your app. Without it, the deploy succeeds but the service immediately crashes because Render has no idea what command to execute.
Your package.json needs this at minimum:
{
"scripts": {
"start": "node index.js"
}
}
Replace index.js with whatever your entry file is. If you use TypeScript and compile to dist, it should be node dist/index.js. If you use a framework with its own start command like Next.js, it should be next start.
Your App Reading PORT from process.env.PORT
Render assigns a dynamic port to your container and routes external traffic to it. If your app hardcodes a port number, Render cannot route traffic to it and the service returns a 502 even though it appears to be running.
Change every app.listen(3000) to this:
const port = process.env.PORT || 3000;
app.listen(port);
This one change makes your app compatible with Render, Railway, Fly.io, Kuberns, and every other managed platform.
Code Pushed to a GitHub Repository
Render deploys directly from GitHub. Your code needs to be in a repository that Render can access, either public or private with Render authorized. Every push to your connected branch triggers an automatic redeploy.
Make sure your .env file is in .gitignore and never committed. Environment variables go in the Render dashboard, not in your repository.
A Free Render Account Connected to GitHub
Sign up at render.com and connect your GitHub account during onboarding. Render needs read access to your repositories to pull code on every deploy. The free tier requires no credit card.
**_
Before you start, understand how Render GitHub integration works and where it breaks for real projects so you are not caught off guard when auto-deploys stop triggering.
_**
How to Deploy a Node.js, Express, and Next.js App on Render
The deployment steps are the same for Node.js, Express, and Next.js. The differences are in the build command, start command, and a few framework-specific settings covered at the end of this section.
Step 1: Create a New Web Service on Render
Log in to your Render dashboard at dashboard.render.com. Click New and select Web Service from the dropdown. Render will ask you to connect a repository.
Step 2: Connect Your GitHub Repository
Select the GitHub account that contains your project. Render shows your available repositories. Choose the correct one and select the branch you want to deploy from, typically main.
If your repository does not appear, click Configure GitHub App to grant Render access to additional repos.
Step 3: Configure Build and Start Commands for Node.js, Express, and Next.js
This is where most developers make mistakes. The build command installs your dependencies. The start command runs your app. These are different things.
For a Node.js or Express app:
For a Next.js SSR app:
For a Next.js static export:
Add output: 'export' to your next.config.js, then:
For static exports, use Render’s Static Site service type instead of Web Service.
Step 4: Add Environment Variables Including NODE_ENV and PORT
In the Environment section of your web service configuration, add every variable your app needs. At minimum:
- NODE_ENV set to production
- Any API keys your app reads from process.env
- Your database URL if your app connects to a database
Do not add PORT manually. Render injects the PORT variable automatically. Your app just needs to read it with process.env.PORT.
Step 5: Deploy and Access Your Live URL
Click Create Web Service. Render pulls your code, runs the build command, and starts the app. The first deploy takes two to four minutes. Once complete, your app is live at https://your-app-name.onrender.com.
Every subsequent push to your connected branch triggers an automatic redeploy. If the build fails, Render keeps the previous version running.
Express-Specific Config and Common Mistakes to Avoid on Render
The most common Express mistake is using nodemon as the start command in production. Nodemon watches for file changes and restarts the server on every save. In a production container there are no file changes. Nodemon adds overhead and occasionally causes unexpected restarts. Your start command should always use node directly, not nodemon.
The second most common mistake is not setting NODE_ENV to production. Without it, Express serves detailed error messages to users, installs dev dependencies, and skips performance optimizations that frameworks enable in production mode.
The third is a missing or incorrect start script in package.json. If Render cannot find a start script, it falls back to node index.js. If your entry file is named server.js or app.js, the deploy will succeed but the service will crash immediately.
Next.js on Render: Static Export vs SSR, Build Command, and Output Directory
Next.js has two deployment modes on Render and choosing the wrong one is a common source of failed deploys.
If your app uses getServerSideProps, API routes, or server components, you need SSR mode. Use the Web Service type with npm run build as the build command and npm start as the start command. Next.js starts its own Node.js server on the PORT provided by Render.
If your app is fully static (no server-side data fetching, no API routes), use static export mode. Add output: ‘export’ to next.config.js, set the build command to npm run build, and point the publish directory to out. Use the Static Site service type on Render for this.
For Next.js, all environment variables prefixed with NEXT_PUBLIC_ must be present at build time, not just at runtime. Add them in Render before the build runs or they will be undefined in your client-side code.
**_
If your Node.js app needs a database, read the full breakdown of Render PostgreSQL setup, pricing, and the limits developers actually hit before you provision one.
_**
Why Developers Run Into Problems After Deploying Node.js on Render
The deployment works. The service goes live. Then real usage reveals a set of limitations that Render’s documentation mentions briefly but does not emphasize. Here is every issue you will hit and what it costs to work around it.
The Free Tier Sleeps After 15 Minutes and Takes 30 to 60 Seconds to Wake Up
Render’s free web services spin down after 15 minutes of no incoming traffic. The container is stopped entirely. When the next request arrives, Render restarts the container from scratch. For a Node.js app that needs to initialize a database connection pool, load environment variables, and start an HTTP server, this cold start takes 30 to 60 seconds.
For any app with real users, a 30 to 60 second wait on the first request after any quiet period is not acceptable. Users see a timeout or a blank page. API clients time out. Scheduled jobs that hit your service fail.
The only fix on Render is upgrading to a paid plan starting at $7 per month per service. There is no configuration option to keep free services awake.
There Is No Persistent Filesystem for File Uploads
Render web services run in ephemeral containers. Any file written to the local filesystem during runtime is deleted when the container restarts or redeploys. This includes user-uploaded images, documents, CSV exports, and anything written with fs.writeFile.
Node.js apps that use Multer, Formidable, or any filesystem-based upload library will silently lose all uploaded files on every redeploy. If you restart the service manually, the files are gone.
The fix is to route all uploads directly to an external object storage service like AWS S3 or Cloudflare R2 and store only the URL in your database. This adds significant setup complexity that has nothing to do with your application logic.
The Free PostgreSQL Database Deletes All Your Data After 90 Days
Render offers a free PostgreSQL database alongside your web service. What is buried in the documentation is that free PostgreSQL instances are permanently deleted after 90 days, along with every row of data in them.
Render’s own documentation explicitly states that free databases are not for production use. If you build on the free database without knowing this, you lose everything at day 91 with no recovery option.
Upgrading to a paid PostgreSQL plan costs an additional $7 per month on top of your web service cost.
WebSocket Connections Drop on the Free Tier
Node.js apps that use Socket.io, ws, or any WebSocket library rely on persistent connections. On Render’s free tier, the service sleeps after inactivity. Sleeping a service closes all open connections without warning. Any client maintaining a WebSocket connection to your Node.js app will be disconnected when the service spins down.
Even on paid plans, Render’s load balancer has specific WebSocket timeout configurations that require additional setup for long-lived connections.
Scaling Beyond One Instance Requires a Paid Plan
The free tier gives you one instance of your Node.js app. If your app receives concurrent traffic that exceeds what a single 0.1 CPU, 512 MB RAM container can handle, there is no horizontal scaling available on free. You need a paid plan to add more instances, and Render does not autoscale automatically on lower paid tiers.
Build Failures Are Hard to Debug Without Shell Access on Free
When a Node.js build fails on Render’s free tier, your debugging tools are limited to the build logs in the dashboard. You cannot SSH into the container, run commands interactively, or inspect the filesystem state after a failed deploy.
Debugging native dependency issues, migration failures, or environment-specific errors that only reproduce on Linux containers requires either paid shell access or a slow cycle of pushing code changes and reading logs.
**_
The costs add up fast once you move off the free tier. See the full Render pricing breakdown with real numbers for what Node.js apps actually cost in 2026 before you scale.
_**
Deploy a Node.js App on Kuberns in One Click
Kuberns is an Agentic AI cloud deployment platform built on AWS. It is designed specifically for developers who want their Node.js app running in production without spending hours on infrastructure configuration.
When you connect your Node.js repository to Kuberns, the Agentic AI engine scans your codebase, detects your framework, runtime version, and dependencies, and configures the entire production environment automatically. No Procfile. No render.yaml. No Dockerfile required.
What Kuberns handles automatically that Render requires you to configure manually:
- Stack detection: Kuberns identifies Node.js, Express, or Next.js from your repository without any configuration file
- PORT binding: no need to set process.env.PORT manually or worry about port mismatches
- SSL certificates: automatic HTTPS on your kuberns.app subdomain and any custom domain you connect
- Managed PostgreSQL: provisioned with one click, connection string injected into your environment automatically
- Persistent storage: file uploads are handled with built-in persistent storage, no S3 setup required
- Auto-restart on crash: if your Node.js process throws an unhandled error and exits, Kuberns restarts it immediately
- GitHub auto-redeploy: every push to your connected branch deploys automatically, same as Render
No cold starts. No sleep. No 90-day database expiry.
Kuberns runs on Kubernetes under the hood with zero cold starts on any plan. Your Node.js app is always running, always responsive. The first request from any user takes the same time as the thousandth.
Deploy in three steps:
- Connect your GitHub repo to Kuberns
- Add your environment variables in the dashboard
- Click Deploy and get your live HTTPS URL Kuberns provides approximately $14 in free credits for your first 30 days, enough to run a full Node.js app in production while you validate it.
**_
See the full list of best Render alternatives for developers and teams in 2026 if you want to compare platforms before switching.
_**
Conclusion
Render is a capable platform for deploying Node.js apps and the setup process is genuinely fast. For side projects, prototypes, and internal tools where a 30-second cold start is acceptable and you do not need persistent storage, it gets the job done.
For production Node.js apps serving real users, the free tier limitations add up quickly. Cold starts, the 90-day database expiry, no persistent filesystem, and limited debugging access are not edge cases. They are things every developer hits within the first few weeks of going live.
Kuberns solves every one of these problems by default. Connect your repo, add your environment variables, and deploy. The Agentic AI handles the rest.
Top comments (0)