Next.js, NestJS and Node.js Deployment

When application deployment fits best

Application deployment is the right service when the code is ready but production hosting is not. This applies to teams that have a working application locally but no clear path to deploying it, teams whose current deployment process involves manual file transfers over SSH, or teams whose application keeps crashing because the process manager, reverse proxy, or environment variables are misconfigured. It is also relevant when a developer has been running the application with a development server in production and needs to move to a production-grade setup with PM2, Nginx, SSL, and proper process recovery. If the application works locally but fails or behaves differently in production, the deployment configuration needs attention.

What a typical deployment engagement looks like

The engagement begins with a review of the application runtime requirements: which Node.js version, which framework, what build steps, and what environment variables are needed. We then prepare the server by installing the required runtime, configuring the build process, and setting up PM2 with appropriate memory limits, restart policies, and log management. The reverse proxy is configured with SSL termination, routing rules for static assets and API routes, and proper headers for security and caching. After deployment, we verify every route, check SSL certificate validity, test application restart behaviour, and validate that environment variables are loaded correctly. The engagement closes with a runbook covering deployment commands, restart procedures, and log locations.

• Runtime review and server environment preparation
• PM2 configuration with restart and log management
• Reverse proxy setup with SSL and routing rules
• Post-deploy validation of routes, SSL, and restarts

Common pitfalls and how they are avoided

The most frequent deployment pitfall is running a development build in production. Next.js development mode, for example, does not optimise output, compiles on the fly, and uses significantly more memory than a production build. We ensure the production build step runs on the server or is included in the CI pipeline so the deployed artifact is optimised. Another common issue is PM2 running out of memory because the max-memory-restart flag is not configured, causing silent crashes. We set memory limits based on the application profile. Reverse proxy misconfiguration is also frequent, where requests for static assets are routed through the Node.js process instead of being served directly, degrading performance. We configure proxy rules to serve static files from the build output directory.

Security and access considerations

Application deployment requires careful handling of secrets and access. Environment variables containing database credentials, API keys, and service tokens should be stored in a .env file outside the web root or injected through a process manager configuration, not committed to the repository. We review the server's SSH access model and ensure the deployment user has only the permissions necessary to restart services and manage files, not full administrative access. The reverse proxy should add security headers including X-Content-Type-Options, X-Frame-Options, and Strict-Transport-Security. We also verify that the application does not expose stack traces, debug information, or internal paths in error responses served to clients.

Operational handover and runbooks

Deployment handover means the team can deploy, restart, and troubleshoot the application independently. The runbook covers how to pull the latest code, run the build step, restart PM2, and verify the deployment. It includes the locations of PM2 logs, the Nginx or Apache configuration files, and the environment variable file. Common troubleshooting scenarios are documented, such as what to do when the application runs out of memory, when SSL renewal fails, or when a deployment produces a blank page. The runbook also includes the command to check PM2 status, view application logs, and restart the process. All documentation is stored alongside the application code or in a location the team already uses.

Monitoring, validation, and rollback planning

After deployment, we validate the application by testing every route type: static pages, API endpoints, dynamic routes with parameters, and asset serving. We check that the SSL certificate is valid and that HTTP requests are redirected to HTTPS. Application restart behaviour is tested by simulating a process crash and verifying that PM2 restarts the process automatically. For rollback, we document how to revert to the previous build by restoring the build artifact and restarting PM2. If database migrations were part of the deployment, rollback steps include how to reverse or skip the migration. The team should have a clear understanding of what to check after every deployment and how to revert if something goes wrong.

Collaboration with your in-house team

Application deployment requires understanding the team's development workflow and release process. We review how the team builds the application locally, what environment variables differ between development and production, and how the team currently manages secrets. If the team uses a CI/CD pipeline, we integrate the deployment steps into that pipeline. If deployment is triggered manually, we ensure the team understands every step and can execute it without external help. We also discuss how the deployment handles feature flags, maintenance mode, and environment-specific configuration, so the team can manage releases for different environments. The objective is a deployment process the team owns and can modify as the application evolves.

What good looks like after deployment

After a successful deployment, the application should start automatically after a server reboot, restart automatically if the process crashes, and serve all routes over a valid SSL connection. The build output should be optimised for production, not running in development mode. Environment variables should be loaded from a secure location, not hardcoded in the application or exposed in version control. The team should be able to deploy a new version by running a documented set of commands that takes under a minute. PM2 logs should be accessible and rotated to prevent disk exhaustion. If the team can deploy, verify, and roll back without external support, the deployment is production-ready.