DockHosting Docs
Deploying

Node.js

Deploy Node.js, Express, NestJS, and Next.js apps — detected automatically.

DockHosting detects a Node.js project from package.json and builds it automatically. This covers plain Node scripts, Express, NestJS, and Next.js.

What DockHosting looks for

  • A package.json at the repository root (or the root directory you've configured, if your app lives in a subfolder of a monorepo)
  • A start script — DockHosting runs npm start (or the equivalent for your package manager) to boot your app after installing dependencies and running build if one is defined
  • Your app listening on the port from the PORT environment variable, bound to 0.0.0.0

If none of that matches your setup — a custom entry point, a non-standard process manager — bring a Dockerfile instead and follow the Docker guide; it always works.

The most common failure: wrong root directory

By a wide margin, the most common Node.js deploy failure is a root directory that doesn't match where package.json actually lives — the build fails looking for a file like servidor.js or the project's real entry point and can't find it.

This happens when:

  • Your app lives in a subfolder (backend/, server/, api/) but the project's root directory is still set to the repository root
  • The entry point referenced in your start script has a typo or was renamed after the script was written

Fix: in your project's settings, set Root directory to the folder that actually contains package.json. If your start script points at a specific file, confirm that file exists at that exact path in your repository.

Environment variables

Node reads process.env.VARIABLE_NAME — set yours in your project's environment variables and they're available at runtime without any extra wiring. See Environment variables.

Databases

Attach a Postgres, MySQL, MongoDB, or Redis instance and the connection string arrives as an environment variable — most Node database clients (pg, mysql2, mongoose, ioredis) accept a connection string directly. See Databases.

Long-running processes

Bots, workers, and queue consumers that never receive HTTP requests — a WhatsApp or Telegram bot, for example — don't fit the Free plan's scale-to-zero model well, since idle detection assumes an app answers HTTP traffic. Pro and Team apps are always-on and never sleep, which is the right fit for anything that needs to stay connected regardless of incoming requests.

On this page