Technical answer

Next.js Self-Hosting Template Pack

Download a small Next.js 16.2 standalone, Docker, Nginx, systemd, environment, and GitHub Actions template pack with explicit production boundaries.

By HostNextJS Editorial TeamReviewed by HostNextJS Technical Review Published Updated
01Typearticle
02Last reviewed
03Update policyReview every 90 days and within 14 days of material Next.js, Node.js, GitHub Actions, Nginx, or systemd guidance changes.
Direct answer

What to know

  • 01The Docker and systemd examples are alternative runtime paths, not layers to combine blindly.
  • 02The GitHub Actions workflow creates an immutable artifact but intentionally does not receive production SSH credentials.
  • 03Every placeholder, path, domain, resource limit, and recovery step must be reviewed before production use.

This pack starts where framework output ends and stops where infrastructure-specific responsibility begins. It is deliberately small enough to audit and explicit about the work it does not perform.

Pick one runtime path

The Dockerfile builds standalone output in stages and runs server.js as a non-root user. Use it when the deployment system promotes immutable images and the team understands container storage, logs, networking, health checks, and image retention.

The systemd unit runs an unpacked standalone release from /srv/nextjs/current, reads runtime values from /etc/nextjs/production.env, sends SIGTERM, and waits up to 30 seconds. Use it when the server lifecycle is managed directly and release directories provide an atomic promotion and rollback boundary.

Do not place systemd around a separately supervised Docker container merely because both files are available.

Keep Nginx at the network boundary

The Nginx example binds public HTTP and proxies to a loopback-only Next.js listener. It forwards host and protocol context and disables proxy buffering for streamed responses. Replace the example domain and integrate the TLS automation, rate limits, payload limits, access logs, and security policy used by the actual environment.

The template does not expose port 3000 publicly. Provider and guest firewalls should enforce the same boundary.

Build once before deployment

The GitHub Actions workflow installs locked dependencies, runs tests when present, builds once, copies the public and static directories required by standalone output, and uploads a commit-addressed archive. It uses read-only repository permissions and contains no deployment credential.

Promote that exact artifact through a separately reviewed deployment process. Rebuilding on the production server weakens provenance and can produce a different dependency or environment result.

Validate the adapted pack

Replace every placeholder and confirm file ownership. Exercise representative routes, images, streaming, cache behavior, webhooks, jobs, shutdown, restart, logs, alerts, backup restoration, and rollback. For multiple instances, add the shared cache, invalidation, encryption-key, deployment-ID, and version-skew controls described in the compatibility matrix.

Methodology

How this resource was produced

The pack implements the smallest reusable boundary supported by the cited documentation: standalone output, immutable artifact creation, a non-root container, an unbuffered reverse proxy, supervised graceful shutdown, and a credential-free CI build. Provider provisioning, TLS, secrets, data, and rollback remain explicit operator work.

Limitations
  • 01

    The pack assumes an npm project with package-lock.json, a public directory, and a successful npm run build command.

  • 02

    It does not provision infrastructure, configure a firewall, issue TLS, install software, manage secrets, back up data, or perform provider-specific rollback.

  • 03

    Monorepos, native dependencies, custom servers, multi-instance caches, and non-npm package managers need deliberate adaptation.

FAQ

Questions about next.js self-hosting template pack.

No fog. Just the practical details developers need before moving a production app.

Why does the workflow stop before deployment?

Remote deployment is provider, network, identity, secret, and rollback specific. A generic workflow that accepts production SSH credentials would hide important decisions and create a dangerous copy-paste path.

Should I use Docker or systemd?

Use the runtime your team can patch, observe, back up, and recover. Both can run standalone output; neither removes the need for release validation and rollback.

Next step

Turn the resource into a deployment decision.

Check deployment readiness