How to launch a Node.js app on the cloud: step-by-step guide (2026)

Before you deploy: make the app cloud-ready

Most deployment problems are decided before you touch a server. Three habits make a Node.js app easy to host anywhere. First, read the port from the environment: process.env.PORT, never a hard-coded 3000 — the platform assigns a port and puts its web server in front. Second, keep secrets and settings in environment variables, not in the code: database URLs, API keys, JWT secrets. Third, make the start command explicit in package.json, so “npm start” runs the right file.

Commit your package-lock.json so the server installs exactly the versions you tested, and never commit node_modules or .env files.

• const port = process.env.PORT || 3000;
• Secrets in environment variables, not in Git
• A start script in package.json
• package-lock.json committed, node_modules ignored

Step 1 — Choose a plan with enough memory

Node.js apps are limited mainly by memory. On Cloud Ninza each plan has a hard memory ceiling for the whole account: Starter (₹2,388 a year) gives 256 MB RAM for 1 app, Growth (₹3,588) gives 512 MB for 2 apps, Business (₹7,188) gives 1 GB for 3 apps, and Pro (₹11,988) gives 2 GB for 5 apps. Prices are before GST.

A small Express API fits on Starter. A full-stack app with a separate frontend and API needs two apps — Growth or above. Anything that builds a large frontend on the server, such as Next.js, is happier on Business. You can move up later and pay only the difference.

Step 2 — Create the app and pick a version

Open Create an app, choose Node.js, select the version — 18, 20, 22, 24 or 26 — and the plan, enter your domain and pay. The app is created automatically: a folder for your code, a private settings file for environment variables, and a placeholder page that answers until your code arrives. You can change the Node.js version later on the App settings page; it applies on the next restart.

Step 3 — Get your code onto the server

There are three ways, and you can mix them. The simplest: zip your project (without node_modules), open the File manager, upload the zip into your app folder and extract it. For developers: switch on SSH on the SSH and SFTP page, add your public key, and use rsync, scp or Git from the terminal. For teams: connect GitHub, GitLab or Bitbucket on the Git page.

Git deployment is the one to grow into. Each push to your branch builds a fresh release, checks that the app answers, and only then makes it live — if the new version fails its health check, the previous release stays live automatically. You can roll back to any earlier release with one click.

Step 4 — App settings: install, build, start

Open App settings. Choose a framework preset — Express or any Node.js server, Next.js, NestJS, Nuxt, SvelteKit, Remix, a static React or Vue build, or “use my package.json start script” — and the install, build and start commands are filled in for you. Adjust them if your project is different; what runs is what you save.

Add your environment variables: paste a whole .env file and the dashboard turns it into rows, or add them one by one. Values are stored privately and never shown back in full. Click Deploy to install dependencies and run the build; the output streams live, so you see errors as they happen.

Step 5 — Connect a database

Create a MySQL/MariaDB or PostgreSQL database on the Databases page — it gets a username, a password you choose and runs on the same server, reached at localhost. For MongoDB, use MongoDB Atlas: add the server IP 151.185.41.197/32 under Network Access in your Atlas project, then put the connection string in an environment variable. External Redis (Redis Cloud, Upstash) works the same way; there is no Redis server on the hosting plans.

Connection strings for external databases can also be saved on the Databases page, tested from the server, and attached to the app as an environment variable in one step.

Step 6 — Domain, SSL and going live

Add A records for @ and www at your DNS provider, pointing to the server IP shown on the Domains page. Free SSL is issued automatically once they resolve, and HTTPS is switched on. WebSockets work through the same domain — Socket.IO and ws both run over HTTPS — so real-time features need no extra setup. Keep a heartbeat on long-lived connections; Socket.IO does this by default.

From then on, use Logs to read your app's output and errors, Restart to apply changes, and the activity log to see who changed what.

What you get with Cloud Ninza Node.js hosting

A Node.js platform that behaves like a cloud console, without running a server yourself:

• Node.js 18, 20, 22, 24 and 26, switchable per app
• Framework presets: Express, Next.js, NestJS, Nuxt, SvelteKit, Remix, static builds
• Git deployments with build, health check and automatic rollback
• Environment variables, live deploy output, logs and one-click restart
• App restarts automatically if it crashes; it never sleeps
• Browser terminal and key-only SSH; file manager with zip extract
• MySQL/MariaDB and PostgreSQL databases; MongoDB Atlas and external Redis by connection string
• Free SSL issued and renewed automatically; WebSockets supported
• Servers in India, isolated accounts with a hard memory limit

Troubleshooting the first deploy

The page shows the placeholder: the start command did not start your app — check Logs. “EADDRINUSE” or nothing listening: the app ignores process.env.PORT. Out of memory during the build: build on your computer or in CI and upload the result, or move to a plan with more memory. Cannot reach MongoDB Atlas: the server IP is missing from Atlas Network Access.

A production checklist for Node.js apps

Before you share the link, run through a short checklist. Set NODE_ENV=production in your environment variables: Express and many libraries switch to faster, quieter behaviour. Log to the console rather than to files — the platform captures console output and shows it in Logs, so you never fill the disk with log files. Handle errors so one bad request cannot crash the process, and let the platform restart the app if it does crash. Put a simple /health route in place for deploy checks and uptime monitors.

Watch memory. Every plan has a hard memory ceiling for the whole account, so a slow leak shows up as restarts in Logs. If you see them, check for caches that never empty, very large in-memory arrays, or a dependency known to leak — and move up a plan only once you know the app needs the room.

• NODE_ENV=production
• Console logging, read in Logs
• A /health route
• Graceful error handling and automatic restarts
• Memory watched against the plan's limit

Zero-downtime releases with Git

With Git connected, a deploy never edits the live folder. Each push is built into its own release folder, the new version is started and checked, and only then does the live link switch to it. Visitors keep using the previous version until the new one has proved it answers; if it does not, nothing changes for them and you get the log by email. Release history lets you return to any recent build with one click, which turns a bad Friday deploy into a thirty-second fix.

Key takeaways

The short version, for anyone skimming:

• Listen on process.env.PORT and keep secrets in environment variables.
• Size the plan by memory: Starter 256 MB, up to 2 GB on Pro.
• Deploy by zip, SSH or Git; Git gives health checks and automatic rollback.
• Use presets for Express, Next.js, NestJS and more; add env vars before deploying.
• Cloud Ninza Node.js hosting starts at ₹2,388 a year before GST.