Deploy a Next.js application

A Next.js application runs on Sevalla as an application: Ingot, Sevalla’s builder, detects Next.js in your Git repository, runs next build, and the web process runs next start, the Next.js server, which supports every Next.js feature. A site that needs no server can instead be exported to static files and published as a static site.

At a glance


Source	A Git repository
Build	Application: Ingot (Node.js 24, npm, `next build`), or the Dockerfile. Static export: `npm run build` on Node.js Latest LTS, publishing `out`
Start command	Application: `next start`, from `scripts.start` in `package.json`, or `node server.js` for a standalone server
Port	Application: the `PORT` environment variable, `8080` by default
Processes	Application: web process
Services	None
Disk	None
Size	Application: H1 for the web process. A static site has no size.

Environment variables

Neither the application nor the static export needs environment variables of its own. Sevalla sets PORT to the application’s web process port. Variables that start with NEXT_PUBLIC_ must be available during the build: see Use environment variables.

Before you begin

A Sevalla company with a payment method, and a GitHub, GitLab or Bitbucket account for the repository. See Git providers.
Node.js 24 or later on your computer.

Create the project

Create a project with the default options (TypeScript, Tailwind CSS, ESLint and the App Router):

npx create-next-app@latest storefront --yes
cd storefront

The project comes with a .gitignore, a Git repository and the scripts Ingot uses: build runs next build and start runs next start.

Prepare the project for Sevalla

Pin the Node.js version:

npm pkg set engines.node="24.x"

Without it, Ingot builds on its default line, Node.js 24 today, which a new Ingot release can move. See Pin the Node.js version. Nothing else needs to change. Ingot installs the dependencies with npm ci, runs the build script, removes the devDependencies, such as Tailwind CSS and TypeScript, which next start doesn’t need, and starts the web process with the start script. next start takes its port from PORT, which Sevalla sets to the web process’s port (8080 by default), and listens on all network interfaces. Run npm run build && npm start and open http://localhost:3000 to check the production build locally. Then commit everything and push it to your Git provider:

git init
git add .
git commit -m "Prepare for Sevalla"
git branch -M main
git remote add origin https://github.com/acme/storefront.git
git push -u origin main

Deploy to Sevalla

These steps build with Ingot. To build from your own Dockerfile instead, see Deploy with a Dockerfile.

Create the application

In the sidebar, click Applications, then click Create > Application. Under Source, click Private repository, then choose the Git provider, the Repository and the Branch. Under Location, choose a Data center. Keep the Size at H1 or choose a larger one, then click Create application. The application opens on its Overview tab with the status Not deployed yet: creating an application doesn’t deploy it.

Deploy

Click the Overview tab, then click Deploy now under Recent deployments. Check the Branch and click Deploy.

Turn on auto-deploy

To deploy every push to the branch automatically, click the Settings tab, then click Update auto-deploy in the Auto-deploy section. Turn on Auto-deploy and click Update auto-deploy. See Deployments.

Verify the deployment

On the Deployments tab, click the deployment. Its Build log shows Ingot’s build plan: Node.js 24 from engines.node, npm from package-lock.json, Next.js from package.json, and next start from the start script.

Build log

╭─ ■ Next.js · Node.js 24 ─────────────────────────────────╮
│ Node.js          24          package.json engines "24.x" │
│ Package manager  npm         package-lock.json           │
│ Framework        Next.js     package.json                │
│ Start            next start  package.json scripts.start  │
│ DevDependencies  removed after the build                 │
├─ Image ──────────────────────────────────────────────────┤
│ Build            node:24-trixie                          │
│ Runtime          node:24-trixie-slim                     │
│ User             1000:1000                               │
│ Init             tini                                    │
│ Port             $PORT, default 8080                     │
╰─────────────────────────────────────────── Ingot v0.5.0 ─╯

Wait for the deployment’s status to change to Deployed. The application’s status next to its name changes to Running.
Click the domain under the application’s name, for example storefront-x7k2m.sevalla.app. The Next.js starter page opens.

Check the page’s title from a terminal:

curl -s https://storefront-x7k2m.sevalla.app/ | grep -o '<title>[^<]*</title>'

<title>Create Next App</title>

The application header with its name, Running status, repository, branch and the domain that opens the application

With the API, Get deployment (getDeploymentV3) returns the deployment’s status, success once it’s deployed, and Get application deployment logs (getApplicationDeploymentLogsV3) returns its build log, which ends with Web has been deployed successfully. See Deploy with the API. If the deployment fails, read its build log, then see Troubleshoot Ingot builds. If it deploys but the domain doesn’t respond, read the application’s runtime logs.

Deploy changes

With Auto-deploy on, every push to the branch starts a deployment; otherwise, click Deploy now for each change. Each deployment builds the image, then replaces the web process’s instances. See Deployments.

Use environment variables

Add configuration on the application’s Environment variables tab. Next.js reads server-side variables at runtime, but it writes variables that start with NEXT_PUBLIC_ into the JavaScript bundle during next build, so keep Available during buildtime selected for them and deploy again after you change one. See Environment variables during the build.

Cache pages and assets

Next.js gives the files under /_next/static/ content hashes, so they’re safe to cache for a long time. Turn on the CDN on the application’s Networking tab to serve static assets from Cloudflare’s servers, and edge caching to serve rendered pages from there too. Edge caching suits pages that are the same for every visitor. See CDN and edge caching.

Build a standalone server

With output: "standalone", next build writes a server with only the dependencies it uses to .next/standalone. Ingot detects the setting and builds a smaller image: it copies only .next/standalone, .next/static and public into it, instead of the whole project and its node_modules, and starts the web process with node server.js. In next.config.ts, replace the /* config options here */ line with the setting:

next.config.ts

import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  output: "standalone",
  cacheComponents: true,
  partialPrefetching: true,
  turbopack: {
    rules: {
      "*.css": {
        loaders: ["@tailwindcss/turbopack"],
        as: "*.css",
      },
    },
  },
};

export default nextConfig;

Commit and push the change. In the next deployment’s build plan, the Framework row shows Next.js (standalone) and the Start row shows node server.js. The standalone server reads PORT too, and Ingot sets HOSTNAME to 0.0.0.0 so that it listens on all network interfaces.

Deploy with a Dockerfile

Ingot needs no Dockerfile. Write one when you want full control of the image: the base image, the system packages and every layer. This one runs the standalone server, so set output: "standalone" first, as in Build a standalone server. Add a Dockerfile and a .dockerignore to the root of the repository:

Dockerfile

FROM node:24-trixie AS build
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:24-trixie-slim
WORKDIR /app
ENV NODE_ENV=production HOSTNAME=0.0.0.0 PORT=8080
COPY --from=build /app/public ./public
COPY --from=build /app/.next/standalone ./
COPY --from=build /app/.next/static ./.next/static
RUN mkdir .next/cache .next/server/route-cache \
    && chown 1000:1000 .next/cache .next/server/route-cache
USER 1000:1000
EXPOSE 8080
CMD ["node", "server.js"]

Line or choice	Why
`node:24-trixie`, then `node:24-trixie-slim`	Node.js 24, the line that `engines.node` pins, on Debian 13. The build stage has the compilers that native modules need; the slim final image leaves them out. A line tag picks up Node.js and Debian security fixes at every build, which a digest would stop.
Two stages	The build stage installs every dependency and runs `next build`. The final image gets only the standalone server, which holds the dependencies it uses, including `sharp` for image optimization.
`public` and `.next/static`	The standalone server doesn’t include them, so the Dockerfile copies them next to it, as Next.js documents.
The lock file before the source	`npm ci` installs exactly what `package-lock.json` lists, and the build cache reuses that layer until the lock file changes, so a code change doesn’t reinstall the dependencies.
`USER 1000:1000`	The server runs as the image’s `node` user, not as root. Root owns the copied files, so the server can’t change its own code. It owns only the two folders it writes to: `.next/cache`, for optimized images and fetched data, and `.next/server/route-cache`, for pages it renders again.
`CMD` in exec form	Node.js is the container’s main process and gets `SIGTERM` when an instance stops. Next.js handles it: it finishes the requests in progress, then exits.
`HOSTNAME=0.0.0.0`, `PORT=8080`, `EXPOSE 8080`	The standalone server listens on the address in `HOSTNAME` and the port in `PORT`. `0.0.0.0` means all network interfaces. Sevalla sets `PORT` to the web process’s port; `8080` is the default when you run the image yourself.

.dockerignore

.git
.next
node_modules
.env*
*.log
Dockerfile
.dockerignore

The .dockerignore keeps local builds, installed packages and local environment files out of the image, so it builds from the committed source only. Sevalla passes build-time environment variables to the build as build arguments: to use a NEXT_PUBLIC_ variable, declare it with ARG in the build stage, before RUN npm run build. See Use build arguments. Commit and push both files. Ingot doesn’t use the Dockerfile and adds your .dockerignore patterns to its own, so you can keep both files in a repository that builds with Ingot. Then switch the application to the Dockerfile build strategy:

Choose the Dockerfile build strategy

On the application’s Settings tab, in the Build strategy section, click Update build strategy. Click Dockerfile, keep the Dockerfile path Dockerfile and the Docker context ., then click Update build strategy.

Deploy

Click the Overview tab, then click Deploy now under Recent deployments. Check the Branch and click Deploy.

The deployment’s build log shows 📦 Building and pushing docker image using Dockerfile... instead of Ingot’s build plan, and its Dockerfile tab shows your file. When the status changes to Deployed, the application’s domain opens the Next.js starter page, and curl -s https://storefront-x7k2m.sevalla.app/ | grep -o '<title>[^<]*</title>' prints <title>Create Next App</title> again. To switch the build strategy with the API, see Build from the Dockerfile with the API.

Deploy a static export

When every page can be built ahead of time, Next.js can export the site to HTML, CSS and JavaScript files, and Sevalla publishes them as a static site, free up to 100 GB of bandwidth a month. A static export doesn’t support features that need a server, such as Server Actions, Proxy (formerly middleware), cookies and Incremental Static Regeneration. See the list of unsupported features. Replace next.config.ts with this:

next.config.ts

import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  output: "export",
  trailingSlash: true,
  images: { unoptimized: true },
  turbopack: {
    rules: {
      "*.css": {
        loaders: ["@tailwindcss/turbopack"],
        as: "*.css",
      },
    },
  },
};

export default nextConfig;

Change	Why
`output: "export"`	`next build` writes the site to the `out` folder.
`trailingSlash: true`	Each page becomes `about/index.html`, which a static site serves at `/about`. Without it, Next.js writes `about.html`, and `/about` returns `404` unless you turn on pretty URLs.
`images: { unoptimized: true }`	The `next/image` component can’t optimize images without a server.
`turbopack`	Kept from the generated file: it builds the Tailwind CSS styles.
`cacheComponents` and `partialPrefetching` removed	Cache Components needs a server. With it, `next build` fails with `Error: Invariant: PPR cannot be enabled in export mode`, and `partialPrefetching` can’t stay without it.

Run npm run build to check that it writes the out folder. Commit and push the change, then create the static site:

Choose the repository

In the sidebar, click Static sites, then click Create static site. Under Source, click Private repository, then choose the Git provider, the Repository and the Branch.

Check the build settings

Under Build settings, Sevalla shows Framework detected: Next.js and fills in the values. Check them:

Field	Value
Build site before publishing	On
Node version	Latest LTS
Build command	`npm run build`
Root directory	Empty, for the repository root
Publish directory	`out`

Create the static site

Enter a Name under Details, then click Create static site. Sevalla starts the first deployment right away, and deploys every push to the branch while Auto-deploy is on.

When the deployment’s status changes to Deployed, click Visit site on the static site’s Overview tab. The Next.js starter page opens on the site’s *.sevalla.page domain, for example storefront-x7k2m.sevalla.page. From a terminal:

curl -s https://storefront-x7k2m.sevalla.page/ | grep -o '<title>[^<]*</title>'

<title>Create Next App</title>

With the API, Get static site deployment (getStaticSiteDeploymentV3) returns the deployment’s status, success once it’s deployed, and Get static site deployment logs (getStaticSiteDeploymentLogsV3) returns its build log, which ends with Static site has been deployed successfully. See Deploy the static export with the API. Static sites don’t read engines.node: the build uses the Node version in the build settings. If the deployment fails, see Troubleshoot static sites. See Build settings for every field.

Add a custom domain

To serve the application from your own domain, such as shop.example.com, add the domain on the application’s Domains tab and create the DNS records that Sevalla shows. Custom domains need a web process larger than H1, so scale the web process first. Static sites have a Domains tab too. See Custom domains.

Connect a database

Create a database in the same location as the application, then connect the application to it with Add environment variables to the application turned on. Sevalla adds DB_URL, DB_HOST, DB_PORT, DB_DATABASE, DB_USERNAME and DB_PASSWORD to the application (what each one holds), and they apply at the next deployment. Read them in server code with process.env.DB_URL.

Deploy with the API

These calls make the same deployments as Deploy to Sevalla and Deploy a static export, in an order that a script or an AI agent runs as it is. Each step names the Sevalla API operation, then the CLI command and the MCP server tool that do the same. You need:

An API key with the Company developer role, or the APP:CREATE, APP:READ and APP:UPDATE permissions for the application and STATIC_SITE:CREATE, STATIC_SITE:READ and STATIC_SITE:UPDATE for the static site, in the SEVALLA_API_KEY environment variable. The CLI reads the key from SEVALLA_API_TOKEN.
The repository on a Git provider that’s connected to your Sevalla account. See Git providers. Creating the application or the static site checks it: when Sevalla can’t read the repository, the call returns 400 with Cannot access repository https://github.com/acme/storefront: Repository not found or you don't have access., followed by where to grant access.
curl and jq.

Deploy the application with the API

Choose the location

List clusters (listClustersV3) returns the locations your company can use, each with its id, its display_name and its region ID in location (see Locations). Keep the ID of the one you want, here Frankfurt, Germany:

CLUSTER_ID=$(curl -s https://api.sevalla.com/v3/resources/clusters \
  -H "Authorization: Bearer $SEVALLA_API_KEY" \
  | jq -r '.[] | select(.location == "eu-frankfurt-1") | .id')

CLI: sevalla resources clusters. MCP: get_platform_options.

Find the H1 size

List process resource types (listProcessResourceTypesV3) returns the sizes by name, in lowercase:

H1_ID=$(curl -s https://api.sevalla.com/v3/resources/process-resource-types \
  -H "Authorization: Bearer $SEVALLA_API_KEY" \
  | jq -r '.[] | select(.name == "h1") | .id')

CLI: sevalla resources process-types. MCP: get_platform_options.

Create the application

Create application (createApplicationV3) creates the application with a web process and auto-deploy off. It builds with Ingot (build_type is ingot) and isn’t deployed yet:

APP_ID=$(curl -s -X POST https://api.sevalla.com/v3/applications \
  -H "Authorization: Bearer $SEVALLA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"display_name":"storefront","cluster_id":"'"$CLUSTER_ID"'","source":"privateGit","git_type":"github","repo_url":"https://github.com/acme/storefront","default_branch":"main"}' \
  | jq -r .id)

CLI:

sevalla apps create --name storefront --cluster $CLUSTER_ID --source privateGit --git-type github --repository https://github.com/acme/storefront --branch main

. MCP: create_application with deploy set to false, because it deploys by default.

Find the web process

List processes (listProcessesV3) returns the web process that the application was created with:

WEB_ID=$(curl -s https://api.sevalla.com/v3/applications/$APP_ID/processes \
  -H "Authorization: Bearer $SEVALLA_API_KEY" \
  | jq -r '.data[] | select(.type == "web") | .id')

CLI: sevalla apps processes list --app-id $APP_ID. MCP: get_application.

Set the size

The API creates the web process at S1, where the dashboard’s default is H1. Update process (updateProcessV3) sets H1:

curl -s -X PATCH https://api.sevalla.com/v3/applications/$APP_ID/processes/$WEB_ID \
  -H "Authorization: Bearer $SEVALLA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"resource_type_id":"'"$H1_ID"'"}' \
  | jq -c '{resource_type_name, cpu_limit, memory_limit}'

{"resource_type_name":"h1","cpu_limit":300,"memory_limit":300}

CLI: sevalla apps processes update $WEB_ID --app-id $APP_ID --resource-type $H1_ID. MCP: scale_process with size_id and apply_now set to false.

Turn on auto-deploy

Update application (updateApplicationV3) turns on automatic deployments for every push to the branch:

curl -s -X PATCH https://api.sevalla.com/v3/applications/$APP_ID \
  -H "Authorization: Bearer $SEVALLA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"auto_deploy":true}' | jq .auto_deploy

CLI: sevalla apps update $APP_ID --data '{"auto_deploy":true}'. MCP: sevalla_api_update with updateApplicationV3.

Deploy

Trigger deployment (triggerDeploymentV3) deploys the latest commit on the application’s branch:

DEPLOYMENT_ID=$(curl -s -X POST https://api.sevalla.com/v3/applications/$APP_ID/deployments \
  -H "Authorization: Bearer $SEVALLA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{}' | jq -r .id)

CLI: sevalla apps deployments trigger $APP_ID. MCP: trigger_deployment.

Wait for the deployment

Get deployment (getDeploymentV3) returns the deployment’s status: waiting and inProgress while it runs, then success or failed. Poll it every 15 seconds, for up to 30 minutes, until the status is final:

for i in $(seq 1 120); do
  STATUS=$(curl -s "https://api.sevalla.com/v3/applications/$APP_ID/deployments/$DEPLOYMENT_ID" \
    -H "Authorization: Bearer $SEVALLA_API_KEY" | jq -r '.status // empty')
  case $STATUS in success|failed|cancelled|skipped) break ;; esac
  sleep 15
done
echo "$STATUS"

CLI: sevalla apps deployments get $DEPLOYMENT_ID --app-id $APP_ID. MCP: get_deployment.

Read the build log

Get application deployment logs (getApplicationDeploymentLogsV3) returns the build log, oldest line first: the build plan from Verify the deployment, the build and the rollout, which ends with Web has been deployed successfully. When the status is failed, the last lines say why. Without limit, the call returns the latest 1,000 lines, so a longer log loses its start; 5000 is the most it allows.

curl -s "https://api.sevalla.com/v3/applications/$APP_ID/deployments/$DEPLOYMENT_ID/logs?limit=5000" \
  -H "Authorization: Bearer $SEVALLA_API_KEY" | jq -r '.[].message'

CLI: sevalla apps deployments logs $DEPLOYMENT_ID --app-id $APP_ID. MCP: get_deployment_logs.

Check the application

List application domains (listApplicationDomainsV3) returns the application’s domain. Request the home page from it:

HOST=$(curl -s https://api.sevalla.com/v3/applications/$APP_ID/domains \
  -H "Authorization: Bearer $SEVALLA_API_KEY" \
  | jq -r '.data[] | select(.is_primary) | .name')
curl -s https://$HOST/ | grep -o '<title>[^<]*</title>'

<title>Create Next App</title>

CLI: sevalla apps domains list --app-id $APP_ID. MCP: get_application.

Build from the Dockerfile with the API

After you push the Dockerfile from Deploy with a Dockerfile, Update application (updateApplicationV3) switches the application’s build strategy. Then repeat the application’s Deploy, Wait for the deployment and Check the application steps:

curl -s -X PATCH https://api.sevalla.com/v3/applications/$APP_ID \
  -H "Authorization: Bearer $SEVALLA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"build_type":"dockerfile","dockerfile_path":"Dockerfile","docker_context":"."}' \
  | jq -c '{build_type, dockerfile_path, docker_context}'

{"build_type":"dockerfile","dockerfile_path":"Dockerfile","docker_context":"."}

CLI: sevalla apps update $APP_ID --data '{"build_type":"dockerfile","dockerfile_path":"Dockerfile","docker_context":"."}'. MCP: sevalla_api_update with updateApplicationV3.

Deploy the static export with the API

Create the static site

Create static site (createStaticSiteV3) creates the static site with the build settings from Deploy a static export. "node_version":"lts" is Latest LTS. Unlike the dashboard, the API turns on auto-deploy only when the body asks for it, and it doesn’t start a deployment:

SITE_ID=$(curl -s -X POST https://api.sevalla.com/v3/static-sites \
  -H "Authorization: Bearer $SEVALLA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"display_name":"storefront","source":"privateGit","git_type":"github","repo_url":"https://github.com/acme/storefront","default_branch":"main","auto_deploy":true,"build_command":"npm run build","node_version":"lts","published_directory":"out"}' \
  | jq -r .id)

CLI:

sevalla static-sites create --name storefront --source privateGit --git-type github --repository https://github.com/acme/storefront --branch main --build-command "npm run build" --node-version lts --publish-directory out

, which leaves auto-deploy off. MCP: create_static_site with the same fields.

Deploy

Deploy static site (deployStaticSiteV3) builds and publishes the latest commit on the branch:

DEPLOYMENT_ID=$(curl -s -X POST https://api.sevalla.com/v3/static-sites/$SITE_ID/deployments \
  -H "Authorization: Bearer $SEVALLA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{}' | jq -r .id)

CLI: sevalla static-sites deployments trigger $SITE_ID. MCP: trigger_deployment with service_type set to static_site.

Wait for the deployment

Get static site deployment (getStaticSiteDeploymentV3) returns the deployment’s status: waiting and inProgress while it runs, then success or failed. Poll it every 15 seconds, for up to 30 minutes, until the status is final:

for i in $(seq 1 120); do
  STATUS=$(curl -s "https://api.sevalla.com/v3/static-sites/$SITE_ID/deployments/$DEPLOYMENT_ID" \
    -H "Authorization: Bearer $SEVALLA_API_KEY" | jq -r '.status // empty')
  case $STATUS in success|failed|cancelled|skipped) break ;; esac
  sleep 15
done
echo "$STATUS"

CLI: sevalla static-sites deployments get $DEPLOYMENT_ID --site-id $SITE_ID. MCP: get_deployment with service_type set to static_site.

Read the build log

Get static site deployment logs (getStaticSiteDeploymentLogsV3) returns the build log, oldest line first: the build settings, the install, the build and the upload, which ends with Static site has been deployed successfully. When the status is failed, the last lines say why. Without limit, the call returns the latest 1,000 lines, so a longer log loses its start; 5000 is the most it allows.

curl -s "https://api.sevalla.com/v3/static-sites/$SITE_ID/deployments/$DEPLOYMENT_ID/logs?limit=5000" \
  -H "Authorization: Bearer $SEVALLA_API_KEY" | jq -r '.[].message'

CLI: sevalla static-sites deployments logs $DEPLOYMENT_ID --site-id $SITE_ID. MCP: get_deployment_logs with service_type set to static_site.

Check the site

Get static site (getStaticSiteV3) returns the site’s domain in hostname. Request the home page from it:

HOST=$(curl -s https://api.sevalla.com/v3/static-sites/$SITE_ID \
  -H "Authorization: Bearer $SEVALLA_API_KEY" | jq -r .hostname)
curl -s https://$HOST/ | grep -o '<title>[^<]*</title>'

<title>Create Next App</title>

CLI: sevalla static-sites get $SITE_ID. MCP: get_static_site.

Get started

Migrate

AI

JavaScript

Python

PHP

Ruby

Go

Rust

Java, Kotlin and Scala

.NET

Elixir

Gleam

Swift

Dart

Static site generators

Deploy a Next.js application

At a glance

Environment variables

Before you begin

Create the project

Prepare the project for Sevalla

Deploy to Sevalla

Verify the deployment

Deploy changes

Use environment variables

Cache pages and assets

Build a standalone server

Deploy with a Dockerfile

Deploy a static export

Add a custom domain

Connect a database

Deploy with the API

Deploy the application with the API

Build from the Dockerfile with the API

Deploy the static export with the API

​At a glance

​Environment variables

​Before you begin

​Create the project

​Prepare the project for Sevalla

​Deploy to Sevalla

​Verify the deployment

​Deploy changes

​Use environment variables

​Cache pages and assets

​Build a standalone server

​Deploy with a Dockerfile

​Deploy a static export

​Add a custom domain

​Connect a database

​Deploy with the API

​Deploy the application with the API

​Build from the Dockerfile with the API

​Deploy the static export with the API

At a glance

Environment variables

Before you begin

Create the project

Prepare the project for Sevalla

Deploy to Sevalla

Verify the deployment

Deploy changes

Use environment variables

Cache pages and assets

Build a standalone server

Deploy with a Dockerfile

Deploy a static export

Add a custom domain

Connect a database

Deploy with the API

Deploy the application with the API

Build from the Dockerfile with the API

Deploy the static export with the API