Where Should a Next.js App Run? Vercel, Docker or Your Own Servers

"Where should we host this?" is one of those questions that sounds like infrastructure and is really about people. A Next.js application will run happily on a managed platform, in a container, or on a server you look after yourself. The framework does not much care. What differs is who patches it at three in the morning, who notices when the cache misbehaves and what happens to your bill when traffic spikes.

This article is a framework, not a recommendation of a vendor. We do not quote hosting prices here because they change frequently and depend on your traffic. We cite the official documentation for every claim about what Next.js supports.

The options, in plain terms

Next.js deployment options as described in the official documentation

Option	Feature support	You are responsible for	Typical fit
Managed platform with a verified adapter	Full, tested by the Next.js team against the compatibility suite	Your code, configuration and spend controls	Teams that want the least operational work
Other platform integrations	Varies. The docs say these are not verified by the Next.js team and compatibility may vary	Checking that the features you use actually work there	Existing commitments to a particular provider
Node.js server (VPS or platform as a service)	All features	Operating system, runtime, process management, proxy, patching, backups	Steady workloads and small teams comfortable with servers
Docker container	All features	Image builds, base-image patching, orchestration, scaling, observability	Teams already running containers, or who need portability
Static export	Limited: server features are unsupported	Only the files you publish	Brochure sites with no server-side needs

Two points deserve a second look. First, "full feature support" on a Node.js server or in a container is real, but it assumes you configure the server for your environment. Second, the adapter model matters for the long term. Vercel's March 2026 post on running Next.js across platforms describes a stable Adapter API arriving with 16.2, which is a sign the framework is being designed to be portable rather than tied to one host.

Six questions that decide it

1. Who patches it? A framework such as Next.js ships security fixes several times a year. On a managed platform you still upgrade the dependency, but the platform handles much of the surrounding infrastructure. On your own servers you also own the operating system, the container base image and the proxy. Our web application maintenance checklist lists what that involves.
2. Which features do you use? Image optimisation, incremental static regeneration, Server Actions, streaming and caching behave differently depending on where they run. List them before you choose.
3. What does your traffic look like? Spiky, unpredictable traffic favours platforms that scale for you. Flat, predictable traffic favours fixed-cost servers. We have not verified any cost comparison, so test with your own numbers.
4. Where must the data live? If you have data-residency or contractual constraints, you need to know exactly which regions processing and storage use. Ask the provider in writing.
5. Who is on call? Self-hosting is a rota, not a one-off setup. If nobody can respond to an incident, the cheaper option is not cheaper.
6. How would you leave? Keep your build reproducible, your data exportable and your use of platform-only features deliberate. Portability is a design choice made early, as we describe in modernising legacy systems without a rewrite.

What self-hosting makes you responsible for

The official self-hosting guide is blunt about the extra work. These are the main points it raises.

• Put a reverse proxy in front. The guide recommends a reverse proxy such as nginx rather than exposing the Next.js server directly, to handle malformed requests, slow connection attacks, payload limits and rate limiting.
• Plan for image optimisation. On glibc-based Linux systems the guide notes that image optimisation may need extra configuration to avoid excessive memory use.
• Treat caching as a design topic. A single instance with persistent local disk works automatically. Multiple instances, ephemeral compute or a CDN in front need the cache configured deliberately, including a shared cache handler and coordination of cache tags for App Router deployments.
• Share the Server Functions key. All instances must use the same encryption key, set through NEXT_SERVER_ACTIONS_ENCRYPTION_KEY, or you will see "Failed to find Server Action" errors.
• Manage version skew. During rolling deployments, a configured deployment identifier lets Next.js detect and handle clients on old assets.
• Shut down gracefully. The guide recommends a drain period of 10 to 30 seconds so in-flight requests and background work can finish.

A container makes some of this easier to repeat. Docker's official guide shows a multi-stage build using the standalone output, which produces a self-contained server with only the files it needs, and runs it as a non-root user. This is an illustrative configuration fragment, not a complete deployment:

// next.config.ts (illustrative)
import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  output: "standalone",
};

export default nextConfig;

The Next.js documentation also notes that a single Docker image can be promoted through environments with different environment variable values, which is a good habit whichever host you choose.

Security considerations

Hosting changes your attack surface in specific ways, and the 2026 advisories show how.

• Host headers. A July 2026 advisory covers server-side request forgery in Server Actions on custom servers. It says applications are affected when the incoming host header is not fixed to a trusted value, that managed hosting pins the host upstream, and that next start and standalone output do so from version 14.2. If you run a custom server or sit behind a proxy that does not pin the host, validate Host and X-Forwarded-Host yourself.
• Image remote patterns. The September 2026 release fixed a high-severity server-side request forgery in image optimisation that depended on images.remotePatterns configuration. Keep those patterns as narrow as possible.
• Patching discipline. The same releases show why hosting and upgrades are linked. Pair this decision with a patch routine, as explained in our Next.js 16 upgrade checklist.
• Secrets and environments. Keep secrets out of images and repositories, separate production from staging and rotate anything that has been shared.

The cost question, answered honestly

You will find posts online claiming dramatic savings from leaving a managed platform, and others warning that self-hosting costs more than it saves. We could not verify either kind of claim, and they usually leave out something: engineering time, incident risk, egress, or the value of not being on call. A fairer comparison lists, for each option over twelve months:

1. Platform or server charges at your expected traffic, plus a pessimistic case.
2. Engineering hours to build, secure and maintain the setup.
3. Monitoring, logging and backup tooling.
4. Support and incident response, including who covers holidays.
5. The cost of being down for an hour, which only you can estimate.

If the numbers are close, choose the option your team can run well. If they are far apart, make sure you have counted everything on both sides.

When we would suggest each

• Managed platform first for new products, small teams and spiky traffic, with a clear note of which platform-specific features you adopt.
• A container on a managed container service when you want portability without running servers.
• Your own servers when you have a real reason, such as data location, existing infrastructure or very steady high volume, and the people to run them.
• A static export only when the site genuinely has no server-side needs.

None of these is permanent. A sensible path is to start where you can ship, keep the application portable and revisit the decision when your traffic, team or compliance position changes.

How SystemNexa can help

We build and deploy Next.js applications across these options. Our cloud deployment and SaaS modernisation and cloud deployment work covers choosing a host, setting up repeatable builds and moving an existing application with its URLs and redirects intact. You can read more about Next.js development and backend development too.

Conclusion

Hosting is a decision about responsibility. Pick the option whose operational burden matches your team, keep your application portable, and put patching and monitoring in the plan from day one. If you are weighing a move or planning a first deployment, tell us what you are running and we will give you an honest view of the trade-offs.