Skip to main content
A Koa server runs on Sevalla as an application: Ingot, Sevalla’s builder, installs the dependencies from your Git repository with npm ci, and the web process runs the start script, node server.js, which listens on the port that Sevalla sets in the PORT environment variable.

At a glance

Environment variables

The application needs no environment variables of its own. Sevalla sets PORT to the web process’s port.

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 folder and install Koa and its router:
Create the server:
server.js
Keep installed packages out of the repository:
.gitignore

Prepare the project for Sevalla

Set the module type, the start script and the Node.js version in package.json:
server.js already handles the port, the proxy and shutdown:
  • It reads PORT, which Sevalla sets to the web process’s port (8080 by default), and app.listen(port) listens on all network interfaces.
  • Sevalla’s load balancer ends HTTPS and forwards each request to the instance over HTTP, with the original protocol and client address in the X-Forwarded-Proto and X-Forwarded-For headers. proxy: true makes Koa read them, so ctx.protocol is https, ctx.secure is true and ctx.ip is the visitor’s address. Without it, Koa sees every request as http, and setting a cookie with secure: true fails.
  • Sevalla sends SIGTERM to each instance it replaces during a deployment. server.close() stops accepting connections and lets the requests in progress finish, then Node.js exits.
Koa needs no build step, so the project has no build script, and Ingot needs no other configuration. Run npm start and open http://localhost:3000 to check the server locally: it shows Hello from Koa on Sevalla over http. Then commit everything and push it to your Git provider:

Deploy to Sevalla

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

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.
2

Deploy

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

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

  1. 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 and the start command from the start script.
    Build log
  2. Wait for the deployment’s status to change to Deployed. The application’s status next to its name changes to Running.
  3. Click the domain under the application’s name, for example storefront-x7k2m.sevalla.app. The page shows Hello from Koa on Sevalla over https: Koa read the protocol from the load balancer’s X-Forwarded-Proto header.
  4. Check the same address from a terminal:
The application header with its name, Running status, repository, branch and the domain that opens the applicationThe 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, check that the server reads PORT and read the application’s runtime logs. When the next deployment replaces an instance, the runtime logs show SIGTERM received, closing the server.

Deploy with a Dockerfile

Ingot needs no Dockerfile. Write your own when you want full control of the image: the base image, the system packages and every layer. Add a Dockerfile and a .dockerignore to the root of the repository:
Dockerfile
.dockerignore
Commit and push both files. Ingot doesn’t use the Dockerfile, so you can keep it in a repository that builds with Ingot, but it adds the .dockerignore patterns to its own, and its build plan lists them in an Ignored row. Then switch the application to the Dockerfile build strategy:
1

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.
2

Deploy

Click the Overview tab, then click Deploy now under Recent deployments. Check the Branch and click Deploy.
The Update build strategy sheet with Dockerfile selected, the Dockerfile path, the Docker context and the Docker registry credentialThe Update build strategy sheet with Dockerfile selected, the Dockerfile path, the Docker context and the Docker registry credential
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 Dockerfile. When the deployment is Deployed, the domain shows Hello from Koa on Sevalla over https again, and curl -s https://storefront-x7k2m.sevalla.app/ prints the same line. See Dockerfile for build arguments and private base images, and Deploy with the API to switch the build strategy with the API.

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 and read it with process.env, as the server reads PORT. Variables marked Available during buildtime also reach npm ci; with a Dockerfile, they arrive as build arguments, which a stage reads only after an ARG line for each one. Variables apply at the next deployment. See Environment variables.

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. 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 the server with process.env.DB_URL.

Troubleshoot

For more causes, see Troubleshoot Ingot builds and Troubleshoot builds and deployments.

Deploy with the API

These calls make the same deployment as Deploy to Sevalla, 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, 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 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.
1

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:
CLI: sevalla resources clusters. MCP: get_platform_options.
2

Find the H1 size

List process resource types (listProcessResourceTypesV3) returns the sizes by name, in lowercase:
CLI: sevalla resources process-types. MCP: get_platform_options.
3

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:
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.
4

Find the web process

List processes (listProcessesV3) returns the web process that the application was created with:
CLI: sevalla apps processes list --app-id $APP_ID. MCP: get_application.
5

Set the size

The API creates the web process at S1, where the dashboard’s default is H1. Update process (updateProcessV3) sets H1:
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.
6

Turn on auto-deploy

Update application (updateApplicationV3) turns on automatic deployments for every push to the branch:
CLI: sevalla apps update $APP_ID --data '{"auto_deploy":true}'. MCP: sevalla_api_update with updateApplicationV3.
7

Deploy

Trigger deployment (triggerDeploymentV3) deploys the latest commit on the application’s branch:
CLI: sevalla apps deployments trigger $APP_ID. MCP: trigger_deployment.
8

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:
CLI: sevalla apps deployments get $DEPLOYMENT_ID --app-id $APP_ID. MCP: get_deployment.
9

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.
CLI: sevalla apps deployments logs $DEPLOYMENT_ID --app-id $APP_ID. MCP: get_deployment_logs.
10

Check the application

List application domains (listApplicationDomainsV3) returns the application’s domain. Request the home page from it:
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 build strategy. Then repeat the Deploy, Wait for the deployment and Check the application steps:
CLI: sevalla apps update $APP_ID --data '{"build_type":"dockerfile","dockerfile_path":"Dockerfile","docker_context":"."}'. MCP: sevalla_api_update with updateApplicationV3.