Next.js Sites

How it works

We don't build your app. You run next build on your own machine or in CI, and upload the result. Each upload becomes a release: we start it next to the one that's live, check that it responds, and only then send traffic to it. If the new release fails its check, the old one keeps serving and you get the error output.

Your app runs on Node 24 by default (22 is also available) with its own container, a per-site CDN cache in front, and the same SSL, custom domains and backups as any other Sitery site.

Prepare your app

Sitery runs Next.js's standalone output, so turn it on in your config:

// next.config.js
module.exports = {
  output: 'standalone',
}

next build then writes a self-contained server to .next/standalone. It leaves two folders out on purpose, and you need to copy them in before uploading:

cp -r .next/static .next/standalone/.next/static
cp -r public .next/standalone/public

Upload the contents of .next/standalone as a .tar.gz, .tgz or .zip, up to 500 MB. The Sitery CLI does all of this for you, so most people never touch these steps.

Native modules have to be built for Linux x64. If you use any, build in CI or a Linux container rather than on a Mac. Image optimization with next/image works out of the box; we provide sharp on the server, so it doesn't matter where you built.

Create a Next.js site

1. In the dashboard, click "Create Site" and choose Next.js as the site type.
2. Pick a Node version. You can change it later; the change takes effect on the next deploy.
3. Leave SFTP on if you plan to upload builds that way.

The site starts with a placeholder page until your first deploy.

Deploying

There are three ways to get a build onto your site:

The Sitery CLI

The quickest route, and the one to use in CI. From your project folder:

npm install -g @sitery/cli
sitery login
sitery deploy --build

See the CLI guide for everything it does.

Upload in the dashboard

Open your site's Deploy tab and drop your archive onto the upload area. Progress and the result show up on the same page.

SFTP

Upload the contents of .next/standalone into the upload folder over SFTP, then click "Deploy from SFTP" on the Deploy tab. The folder is emptied once the deploy succeeds.

What happens during a deploy

1. We unpack your build and check it (for example, native modules built for the wrong platform are rejected with a clear message).
2. The new release starts alongside the live one.
3. We request your health check path (/ unless you change it on the Deploy tab). Any response below 500 within 60 seconds counts as healthy.
4. Traffic switches to the new release, the old one shuts down, and the CDN cache is purged.

One deploy runs at a time per site. To go back to an earlier version, deploy that build again; there's no rollback button during the beta.

Environment variables

Ship your runtime variables inside the build as .env.production (with the CLI: sitery deploy --env-file .env.production). There's no environment editor in the dashboard yet.

Two things to keep in mind. NEXT_PUBLIC_* values are baked into the JavaScript at build time, so they must be set before you build, not after. And we set PORT, HOSTNAME and NODE_OPTIONS ourselves; those override anything in your file.

Your env file is never served to visitors, and we never write its contents to logs.

Caching

The CDN in front of your site follows the Cache-Control headers Next.js sends, so static pages and ISR are cached the way Next.js intends, including s-maxage and stale-while-revalidate. A few rules keep it safe:

• Responses that set a cookie are never cached.
• Requests with an Authorization header, or in draft or preview mode, skip the cache.
• Responses with no caching headers (most route handlers) aren't cached.
• The whole cache is purged on every deploy. You can also purge it with sitery cache purge.

Storing files

Each release starts from a clean copy of your build, so anything written inside the app folder is gone after the next deploy. If your app needs to keep files, write them to /data (also available as process.env.SITERY_DATA_DIR). That folder survives deploys and is included in backups.

Logs

Your app's output (anything it prints, plus errors) is on the Logs tab under "App Logs", or in your terminal with sitery logs --follow. If a deploy fails its health check, the last lines of output are attached to the failed deployment.

Backups

Backups of a Next.js site contain the live release and your /data folder. Restoring one rebuilds that release and switches to it the same way a deploy does, so the site stays up during the restore.

Who can deploy

Workspace owners and admins can deploy and change settings. For teammates who should ship releases but not touch settings, keys or members, give them the Deployer role. Members can see deployments but can't start one.

Not in the beta yet

There's no managed database for Next.js sites, no preview deployments, no deploy-on-push from Git, and no environment variable editor. Bring your own database over a connection string in your env file. If one of these is blocking you, tell us; it helps us decide what comes next.