VPS for a Node.js API: deployment and sizing checklist

Start with the application runtime and its dependencies

A VPS for a Node.js API needs a compatible environment and an administration owner. Record the runtime requirements, package lockfile, native dependencies, database and workers. Choose a supported Active LTS or Maintenance LTS release compatible with the project, then verify the executable used by the deployed process.

Decide whether the API runs directly on Linux or in a container. A distribution choice does not install your Node.js application or database. Docker preparation is an initial environment choice; application code, runtime compatibility and the working API still need to be implemented and verified after delivery.

Compare Linux VPS environments for your API

Define process supervision, startup and shutdown

Starting the API in an interactive SSH terminal is not a complete production lifecycle. Choose one supervisor: for example, systemd for a direct deployment or the container runtime for containers. Record the executable, working directory, service account and configuration source. Verify startup without your interactive shell environment.

Test a controlled process failure and a planned reboot. Review restart rules and diagnostics so a persistent error does not become an unexplained restart loop. A process running again is not proof that the database is connected or the API is ready. Test graceful termination: stop accepting new work, handle in-flight requests appropriately and close the application’s connections before the supervisor timeout.

Scroll the table horizontally if needed.

Review Docker VPS preparation for a container deployment

Choose RAM and CPU from request behaviour

Measure memory, request latency and errors under a representative mix of API endpoints. Include payload sizes, concurrent database calls and any background job that shares the server. Node.js process.memoryUsage reports RSS and V8 heap information; heapUsed alone does not describe the complete process, its native allocations or the other services running on the VPS.

A V8 old-space limit controls only part of memory use and should not consume the entire host allocation. More vCPUs also do not make a blocked callback in one event loop execute in parallel. Investigate expensive synchronous work, queries and concurrency before interpreting a slow endpoint as a need for a larger server. If you deliberately run multiple processes, measure their combined memory and connection counts.

Size application, database and worker memory in a Docker stack

Check the public proxy and private application boundary

Define which component receives public requests and which endpoint reaches the API internally. When using a reverse proxy, configure the application’s listening address, proxy destination and trust rules deliberately. Do not assume forwarded client or scheme headers are trustworthy from every source. Review request-body limits and timeouts on both sides for the endpoints you actually provide.

Test an authenticated request, an expected validation error, a larger upload if supported and a long-running operation if the application requires one. Check the HTTPS hostname and client behaviour, including browser origin rules where relevant. Keep database and management endpoints outside the intended public route. The Nginx checklist covers host and certificate setup; these checks verify how the API behaves behind it.

If Nginx returns 502, compare its upstream error log with the application log. Check that the API is running and listening at the configured address and port, then test that endpoint from the proxy’s own network context. In separate containers, localhost refers to each container’s own environment; the intended upstream may need its service name instead. Investigate that failed connection before changing the public firewall or choosing a larger VPS.

Validate Nginx host routing, HTTPS and proxy deployment

Keep configuration and credentials scoped to the process

List the environment variables and other configuration the API requires, with a documented owner for each secret. Node.js can read startup variables through process.env, but choosing environment variables does not itself provide encryption, rotation or access control. Keep secret material out of the public website directory, source repository and application responses.

Run the application with the permissions it needs rather than using administrator privileges by default. Verify that the service account can read its intended configuration and write only the required data. Redact tokens and sensitive payloads from logs. Keep the debugging inspector out of the public production path, and review dependency updates through the application’s tested release process.

Include the database, queue and uploads in recovery

Decide whether the database and queue are local or external, and configure connection limits around the chosen process and worker count. Rehearse database unavailability and a worker retry without creating duplicate business actions. An API health endpoint that only confirms a running process may not tell you that the critical dependency needed by users is available.

A recovery set needs the deployable release, required configuration, database data and any uploads or durable job state. Protect credentials while ensuring an authorised operator can reconstruct the service. Test restoration away from production and identify the work lost after the selected backup. Recreating a Node.js process or pulling its image does not restore application records.

Build and test a complete application recovery set

Accept the release using real API checks

Before directing clients to a deployment, check the domain, authentication, permissions, errors and real read/write workflows. Verify startup after reboot, usable logs and a controlled restart. Record the result with the release identifier and tested environment.

Keep rollback separate from database reversal. Returning to the previous application release may be unsafe after an incompatible schema change or newly written records. Plan that decision with the application developer, then review the current VPS resources and quotation against the measured workload. Hosting payment and service delivery remain separate from acceptance of your own API.

• The supported runtime and supervised startup match the application requirements.
• Representative requests and workers fit the measured resource allocation.
• Public routing, authentication and private dependencies have been tested.
• Secrets, data recovery and the database rollback decision have an owner.
• No application-readiness claim depends only on a running process.