Explainer

Serverless Next.js hosting without an account.

Serverless hosting is the model where you deploy code instead of servers: the platform runs your app on demand, scales it to zero when nobody is visiting, and bills you for what actually executes. For a Next.js app that means your pages, server components, and route handlers all run on someone else's edge infrastructure. This guide explains how serverless Next.js hosting works, how the major platforms compare, and how x402-hosting applies the model with prepaid USDC payments instead of accounts and subscriptions.

Why Next.js needs serverless hosting at all

Next.js is a full-stack framework. A single project can mix static pages, server-rendered routes, API route handlers, and middleware. On a traditional server you would run the Node process yourself, patch it, and keep it alive. Serverless hosting takes that job over: the platform compiles your app into isolated functions or workers, runs them close to the visitor, and handles the scaling. You get the framework's full feature set without operating a server.

How the major platforms handle it

Most searches for Next.js hosting land on the same handful of platforms, each with its own flavor of serverless:

  • Vercel — made by the Next.js company; serverless functions with a generous free tier and usage-based paid plans.
  • Netlify — serverless functions plus a visual dashboard and build pipeline.
  • AWS Amplify — Next.js SSR routed through AWS Lambda, with all the configuration surface that implies.
  • Cloudflare Workers — V8 isolates at the edge; when paired with OpenNext, a full Next.js app runs as a Worker.

The trade-offs are consistent across all of them: an account is required, pricing is usage-based with tiers and overage math, and the platform login — not you alone — controls the deployment.

The x402-hosting model: serverless, prepaid, wallet-owned

x402-hosting uses the Cloudflare Workers approach: the CLI detects your Next.js version, adds the OpenNext Cloudflare configuration, and builds your app locally. The successful build is published as a Worker, so your app gets the same serverless properties — no server to maintain, automatic scaling, cold starts handled by the platform.

What is different is the commercial model. There is no account and no API key: the CLI builds first, then pays with a wallet over the x402 protocol. The API answers with an HTTP 402 challenge, your wallet pays $0.01 for the upload plus $0.20 per project-day, and the wallet that pays owns the project.

Next.js project→local OpenNext build→Cloudflare Worker→production URL
One command moves a Next.js project from a local directory to a production URL.

Deploying serverless in one command

From the root of any supported Next.js project, run:

$ npx x402-hosting@latest deploy --days 30

Thirty days of serverless hosting costs $6.01 in total: $0.01 for the upload and $6.00 for the days. An active project includes its static assets, 100,000 dynamic requests, and 15 million CPU milliseconds. Supported Next.js versions are 15.5.21 up to (but not including) 16, and 16.2.11 and later.

What serverless means for your bill

Usage-based serverless pricing is unpredictable by design: you pay per request, per gigabyte-second, per build minute, and overages arrive after the fact. Prepaid per-day pricing inverts that. You know the exact cost before the deploy — $0.20 per project-day, quoted in USDC — and there is no overage bill, because the prepaid period is the whole commitment. When you stop renewing, the hosting simply ends; there is no cancel flow to hunt for.

Ownership in a serverless world

  • The wallet that pays the first upload owns the project
  • No platform login exists that could lock you out
  • x402-hosting.json in the repo records the URL, project id, owner wallet, and expiry
  • Rollback to any previous deployment costs $0.01
  • Status and deployment-history reads are free

When is serverless the right choice?

Serverless fits most Next.js projects: landing pages, blogs, docs, MVPs, portfolios, storefronts, and demos all benefit from not operating a server. Where it fits least is sustained heavy compute — long-running jobs belong on dedicated infrastructure regardless of platform. For everything else, the question is not whether to go serverless but who controls the deployment and how you pay for it.

Related guides