Deployment, CI/CD and Production Operations
Learn how to prepare, build, deploy, scale, monitor, and maintain Next.js applications in production environments.
)
Production Build
The production build is different from development mode. It performs optimizations, creates deployable output, and exposes issues that may not appear during development.
Always run a production build before deployment. Type errors, invalid imports, unsupported runtime APIs, and environment problems can surface during this stage.
npm run build
npm run start- Test the production build before deploying.
- Do not assume development mode represents production behavior.
- Validate required environment variables during deployment.
Deployment Models
Next.js can be deployed using managed platforms, containers, or infrastructure you operate yourself. The correct model depends on traffic patterns, compliance requirements, networking, operational expertise, and cost.
Managed platforms can simplify caching, builds, previews, and deployment. Container-based deployment can provide greater control over runtime and infrastructure.
The application architecture should not depend unnecessarily on one deployment environment unless that dependency provides meaningful value.
- Deployment strategy should match operational requirements.
- Managed hosting reduces infrastructure responsibility.
- Container deployment can provide greater infrastructure control.
CI/CD for Next.js
Continuous integration should automatically validate code before it reaches production. A typical pipeline may run formatting checks, linting, type checking, unit tests, integration tests, and a production build.
Continuous deployment can then promote validated builds through staging and production environments.
The exact pipeline should reflect application risk. A financial application should generally have stronger release controls than a small personal website.
npm ci
npm run lint
npm run typecheck
npm test
npm run build- Automate quality checks before deployment.
- Build artifacts should be reproducible.
- Use stronger release controls for higher-risk systems.
Scaling Next.js Applications
Scaling is not simply adding more application servers. You must understand which parts of the application are stateless, where sessions live, how caches behave, how database connections are managed, and which workloads can become bottlenecks.
A horizontally scaled application should avoid storing important user state only in process memory unless that behavior is intentionally local.
Database connection management becomes especially important when many server instances can start simultaneously.
- Design application servers to be horizontally scalable when required.
- Do not depend on process-local state for shared application state.
- Database and cache architecture often becomes the real scaling bottleneck.
Database Migrations and Rollbacks
Application deployment and database schema changes must be coordinated carefully. A deployment can fail even when the application code is correct if the database migration is incompatible with the currently running version.
Prefer backwards-compatible schema changes when possible. For example, add a new column before deploying code that requires it, then remove the old column only after the old code is no longer running.
Rollback planning is essential because application rollback does not automatically reverse database changes.
- Database changes can outlive application deployments.
- Prefer backwards-compatible migration strategies.
- A code rollback does not necessarily mean a database rollback.