Deploy a FastAPI application

A FastAPI project runs on Sevalla as an application built from your Git repository: Ingot, Sevalla’s builder, detects FastAPI and starts it with Uvicorn in the web process, and a job runs its Alembic migrations before each deployment. Its data lives in a Sevalla PostgreSQL database that the application reaches over an internal connection.

At a glance


Source	A Git repository
Build	Ingot (Python 3.14, pip), or the Dockerfile
Start command	`uvicorn app.main:app --host 0.0.0.0 --port "$PORT"`, which Ingot detects from `app = FastAPI()` in `app/main.py`
Port	The `PORT` environment variable, `8080` by default
Processes	Web process; `Migrate` job (`alembic upgrade head`, Before deployment)
Services	PostgreSQL 18 over an internal connection
Disk	None
Health check	None; see Add FastAPI health checks
Size	H1 for the web process and the job

Environment variables

Variable	Required	Available during	Secret	Value
`DB_URL`	Yes	Runtime	Yes	`DB_URL` from the internal connection, `postgres://<user>:<password>@<host>:<port>/<database>`
`PORT`	No	Runtime	No	Set by Sevalla to the web process port
`WEB_CONCURRENCY`	No	Runtime	No	Number of Uvicorn worker processes, `1` when unset

Before you begin

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

Create the project

Create a virtual environment, install FastAPI, SQLModel, Alembic and the PostgreSQL driver, and create the app package:

mkdir storefront && cd storefront
python3 -m venv .venv
source .venv/bin/activate
pip install "fastapi[standard]" sqlmodel alembic "psycopg[binary]"
mkdir app && touch app/__init__.py

Package	What it does
`fastapi[standard]`	FastAPI with the `fastapi` command, Uvicorn, and form and file upload support
`sqlmodel`	Models and sessions on top of SQLAlchemy
`alembic`	Database migrations
`psycopg[binary]`	The PostgreSQL driver, psycopg 3

Keep local files out of the repository:

.gitignore

.venv/
__pycache__/
.env
*.db

Add the database engine. Sevalla’s connection URLs start with postgres://, which SQLAlchemy doesn’t accept, so the code switches the scheme to postgresql+psycopg://, SQLAlchemy’s name for psycopg 3:

app/db.py

import os
from typing import Annotated

from fastapi import Depends
from sqlmodel import Session, create_engine

def database_url() -> str:
    url = os.environ.get("DB_URL", "sqlite:///storefront.db")
    return url.replace("postgres://", "postgresql+psycopg://", 1)

engine = create_engine(database_url())

def get_session():
    with Session(engine) as session:
        yield session

SessionDep = Annotated[Session, Depends(get_session)]

DB_URL is the variable Sevalla adds when you connect the database; without it, the project uses SQLite on your computer. Add a model and the application:

app/models.py

from sqlmodel import Field, SQLModel


class Item(SQLModel, table=True):
    id: int | None = Field(default=None, primary_key=True)
    name: str

app/main.py

from fastapi import FastAPI
from sqlmodel import select

from app.db import SessionDep
from app.models import Item

app = FastAPI()


@app.get("/")
def index(session: SessionDep):
    items = session.exec(select(Item)).all()
    return {"items": len(items)}


@app.post("/items")
def create_item(item: Item, session: SessionDep) -> Item:
    session.add(item)
    session.commit()
    session.refresh(item)
    return item

Prepare the project for Sevalla

Set up migrations

Create the Alembic files:

alembic init alembic

In alembic/env.py, replace everything above def run_migrations_offline() with this, which points Alembic at the same database URL and at the SQLModel tables:

alembic/env.py

from logging.config import fileConfig

from alembic import context
from sqlalchemy import engine_from_config, pool
from sqlmodel import SQLModel

import app.models  # noqa: F401 (registers the tables on SQLModel.metadata)
from app.db import database_url

config = context.config
if config.config_file_name is not None:
    fileConfig(config.config_file_name)

# Alembic's config treats % as a special character, and passwords in URLs can contain it.
config.set_main_option("sqlalchemy.url", database_url().replace("%", "%%"))

target_metadata = SQLModel.metadata

SQLModel columns use its own types, so in alembic/script.py.mako, the template Alembic writes migrations from, add import sqlmodel under import sqlalchemy as sa:

alembic/script.py.mako

from alembic import op
import sqlalchemy as sa
import sqlmodel

Generate the first migration, apply it to the local database and start the development server:

alembic revision --autogenerate -m "Create item table"
alembic upgrade head
fastapi dev

fastapi dev finds the application in app/main.py. Open http://127.0.0.1:8000: the response is {"items":0}. Press Ctrl+C to stop the server.

Pin the Python version

Ingot reads the Python version from .python-version. Without it, Ingot builds on its default line (3.14 in Ingot 0.5.0), which a newer Ingot release can move. Pin the version you develop with:

.python-version

3.14

See Pin the Python version.

Check the start command

The project needs no start command. Ingot finds app = FastAPI() in app/main.py and starts the web process with uvicorn app.main:app --host 0.0.0.0 --port "$PORT", which the build plan shows in its Start row.

Uvicorn listens on all interfaces, on the port in the PORT environment variable. Sevalla sets PORT to the web process’s port, 8080 by default.
Requests reach the application through Sevalla’s proxy. Ingot’s image sets FORWARDED_ALLOW_IPS=*, so Uvicorn trusts the X-Forwarded-Proto and X-Forwarded-For headers, and FastAPI sees the https scheme and the visitor’s address. See Request headers.
Uvicorn runs one worker process in each instance. On a larger size, set the WEB_CONCURRENCY environment variable to run more, for example 2. See Scaling.
Migrations don’t run here. A job runs them once per deployment.

Ingot looks for the application in main.py, app.py, app/main.py and a few other common files. To start it another way, set the web process’s start command; see Set the start command.

List the dependencies

Ingot installs the packages in requirements.txt with pip, so list them with the versions you tested:

pip freeze > requirements.txt

Commit everything, including the alembic folder and alembic.ini, 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 database

In the sidebar, click Databases, then click Create database. Under Database, choose PostgreSQL and the newest version. Enter orders-db as the Display name, choose a Data center and a Size, then click Create database. See Create a database for every field.

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 the same Data center as the database. 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.

Connect the database

Click the Networking tab. Under Connected services, click Add internal connection. Choose orders-db as the Service, turn on Add environment variables to the application, and click Add internal connection. Sevalla adds DB_URL and the other connection variables to the application. See Connect an application.

Create the migration job

Click the Processes tab, then click Create process. Choose Job, enter Migrate as the Name and alembic upgrade head as the Custom start command. Keep the Start policy at Before deployment and the Resource at H1, then click Create process.

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.

The Create process sheet with Job selected, the Name and Custom start command fields, the Start policy set to Before deployment, and the H1 resource

Verify the deployment

On the Deployments tab, click the deployment. Its build log shows Ingot’s build plan:

Build log

╭─ ■ FastAPI · Python 3.14 ───────────────────────────────────────────────────────────────────╮
│ Python           3.14                                                .python-version "3.14" │
│ Package manager  pip                                                 requirements.txt       │
│ Framework        FastAPI                                             app/main.py            │
│ Start            uvicorn app.main:app --host 0.0.0.0 --port "$PORT"  FastAPI                │
├─ Image ─────────────────────────────────────────────────────────────────────────────────────┤
│ Build            python:3.14-slim-trixie                                                    │
│ Runtime          python:3.14-slim-trixie                                                    │
│ User             1000:1000                                                                  │
│ Init             tini                                                                       │
│ Port             $PORT, default 8080                                                        │
╰────────────────────────────────────────────────────────────────────────────── Ingot v0.5.0 ─╯

After the build, the log shows Migrate has been successful, then Web has been deployed successfully. If the job fails, the deployment fails and nothing changes for visitors.

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, or run curl -s https://storefront-x7k2m.sevalla.app/. The response is {"items":0}, which shows that the application reads the PostgreSQL database.

Add an item and read it back, with your application’s domain:

curl -X POST https://storefront-x7k2m.sevalla.app/items \
  -H "Content-Type: application/json" \
  -d '{"name": "Mug"}'
curl https://storefront-x7k2m.sevalla.app/

The first response is {"id":1,"name":"Mug"} and the second is {"items":1}. The interactive API docs are at /docs.

To check the same things through the API, use APP_ID and DEPLOYMENT_ID from Deploy with the API. Get deployment (getDeploymentV3) returns the status, success once the deployment is done:

curl -s https://api.sevalla.com/v3/applications/$APP_ID/deployments/$DEPLOYMENT_ID \
  -H "Authorization: Bearer $SEVALLA_API_KEY" | jq -r .status

Get application deployment logs (getApplicationDeploymentLogsV3) returns the build log, build plan included; search keeps the lines that contain a text:

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

✅ Migrate has been successful
🚀 Web has been deployed successfully.

The messages carry terminal color codes, so match the text inside them. The job’s own output is in the runtime logs: Get application runtime logs (getApplicationRuntimeLogsV3) with search=Running%20upgrade returns INFO [alembic.runtime.migration] Running upgrade -> 4a832573a227, Create item table, with your migration’s revision. The CLI has sevalla apps deployments get, sevalla apps deployments logs and sevalla apps logs runtime, and the MCP server get_deployment, get_deployment_logs and search_runtime_logs.

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

FROM python:3.14-slim-trixie

ENV PYTHONUNBUFFERED=1 \
    PORT=8080 \
    FORWARDED_ALLOW_IPS="*"

RUN useradd --uid 1000 --create-home app
WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir --root-user-action=ignore -r requirements.txt

COPY . .
RUN python -m compileall -q .

USER 1000:1000
EXPOSE 8080
CMD ["sh", "-c", "exec uvicorn app.main:app --host 0.0.0.0 --port \"$PORT\""]

Line or choice	Why
`python:3.14-slim-trixie`	The Python line that `.python-version` pins, on Debian 13, as Ingot builds it. A line tag picks up each patch release and security fix when you deploy again; a digest would stay on one release.
One stage	pip installs prebuilt wheels, so the build needs no compiler and leaves nothing to clean up.
`requirements.txt` before the code	Docker reuses the installed packages until `requirements.txt` changes, so a code change rebuilds only the last layers.
`pip install` into the image’s Python	The image runs one application, so it needs no virtual environment. `--root-user-action=ignore` silences pip’s warning about installing as root.
`compileall`	Compiles the code at build time, because the application can’t write to `/app` when it runs.
`useradd` and `USER 1000:1000`	Runs Uvicorn as an unprivileged user with a home directory, the same user ID as Ingot’s images. The code stays owned by root, so the application can’t change it.
`FORWARDED_ALLOW_IPS="*"`	Uvicorn trusts the `X-Forwarded-Proto` and `X-Forwarded-For` headers from Sevalla’s proxy, so FastAPI sees the `https` scheme and the visitor’s address. Ingot sets the same.
`sh -c "exec uvicorn ..."`	Uvicorn doesn’t read `PORT` itself, so a shell puts it on the command line. `exec` replaces the shell with Uvicorn, which runs as PID 1, handles `SIGTERM` and finishes the requests in progress before it exits. Uvicorn reads `WEB_CONCURRENCY` for the number of worker processes.

.dockerignore

.git
.venv
**/__pycache__
.env*
*.db
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: its build plan shows an Ignored row with 7 patterns from .dockerignore. 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 Update build strategy sheet with Dockerfile selected, the Dockerfile path, the Docker context and the Docker registry credential

The build log shows 📦 Building and pushing docker image using Dockerfile... where Ingot’s build plan was, then Migrate has been successful: the job runs alembic upgrade head in the new image. The domain still returns {"items":1}, from the same database, and curl -i https://storefront-x7k2m.sevalla.app/items/ redirects to https://storefront-x7k2m.sevalla.app/items, with the https scheme that Uvicorn took from the proxy. The deployment’s Dockerfile tab shows your Dockerfile. See Dockerfile.

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, runs the Migrate job, then replaces the web process’s instances. For a schema change, run alembic revision --autogenerate on your computer and commit the new migration with the code. After you install a package, run pip freeze > requirements.txt again. See Deployments.

Add a custom domain

Add the domain on the application’s Domains tab. FastAPI doesn’t check the host, so no code change is needed. Custom domains need a web process larger than H1.

Troubleshoot the deployment

Symptom	Cause	Fix
The build fails with `Ingot couldn't find the FastAPI application`	`app = FastAPI()` isn’t at the top level of a file Ingot searches, such as `main.py` or `app/main.py`.	Create the application in `app/main.py`, or set the web process’s start command, for example `uvicorn storefront.api:app --host 0.0.0.0 --port "$PORT"`.
The build fails with `FastAPI needs a production server, and uvicorn isn't installed`	`requirements.txt` lists FastAPI without Uvicorn.	Install `fastapi[standard]`, run `pip freeze > requirements.txt` and push.
The application or the job crashes with `Can't load plugin: sqlalchemy.dialects:postgres`	The code passes Sevalla’s `postgres://` URL to SQLAlchemy unchanged.	Replace the scheme with `postgresql+psycopg://`, as `database_url()` does.
The job crashes with `invalid interpolation syntax`	The database password has a character that `DB_URL` percent-encodes, such as `#` or `@`, and Alembic’s config reads `%` as a placeholder.	Escape it with `.replace("%", "%%")` in `alembic/env.py`.
The deployment fails at `Migrate has failed`	The migration raised an error, or the job can’t reach the database.	Read the job’s output on the application’s Logs tab, with Process set to `Migrate`. Check that the internal connection exists and that `DB_URL` is set.

For more causes, see Troubleshoot builds and deployments. To add file storage, caching or background tasks, see the FastAPI guides.

Deploy with the API

These calls make the same deployment as Deploy to Sevalla, in an order that an agent or a script runs as is. Each step names the API operation, then the CLI command and the MCP tool that do the same. The CLI reads the key from SEVALLA_API_TOKEN and prints tables; with --json it prints the API’s JSON, except that lists are bare arrays rather than the API’s data field. Before you start:

Put an API key in SEVALLA_API_KEY. The key needs the Company developer role or Company admin; see API keys. The commands use curl, jq and openssl.
Push the repository and connect its Git account to Sevalla, as in Before you begin. No API call reports whether the account is connected: if it isn’t, or Sevalla’s GitHub App can’t see the repository, creating the application fails with 400 and a message that starts with Cannot access repository https://github.com/acme/storefront: Repository not found or you don't have access. and says where to grant access.
Look up the location and the sizes. The first command picks the location by its region ID, here eu-frankfurt-1 (Frankfurt, Germany); see Locations for the others. List clusters (listClustersV3), List process resource types (listProcessResourceTypesV3) and List database resource types (listDatabaseResourceTypesV3) return them; the CLI has sevalla resources clusters, sevalla resources process-types and sevalla resources db-types, and the MCP server get_platform_options.

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')
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')
DB1_ID=$(curl -s https://api.sevalla.com/v3/resources/database-resource-types \
  -H "Authorization: Bearer $SEVALLA_API_KEY" \
  | jq -r '.[] | select(.name == "db1") | .id')

If a variable ends up empty or null, run its curl command without jq: the response’s message says what went wrong.

Create the database

Create database (createDatabaseV3). You choose the password here, because the API never returns it and DB_URL needs it:

DB_PASSWORD=$(openssl rand -hex 16)
DB_ID=$(curl -s -X POST https://api.sevalla.com/v3/databases \
  -H "Authorization: Bearer $SEVALLA_API_KEY" \
  -H "Content-Type: application/json" \
  -d @- <<EOF | jq -r .id
{
  "display_name": "orders-db",
  "type": "postgresql",
  "version": "18",
  "cluster_id": "$CLUSTER_ID",
  "resource_type_id": "$DB1_ID",
  "db_name": "storefront",
  "db_user": "storefront",
  "db_password": "$DB_PASSWORD"
}
EOF
)

CLI:

sevalla databases create --name orders-db --type postgresql --db-version 18 --cluster "$CLUSTER_ID" --resource-type "$DB1_ID" --db-name storefront --db-user storefront --db-password "$DB_PASSWORD"

. MCP: create_database generates its own password and never returns it. Call it once the application exists, with connect_to_application_id set to the application and env_var_name set to DB_URL: it then also adds the internal connection and DB_URL, in place of the steps that connect the database and add the database URL. Its URL starts with postgresql://, which SQLAlchemy 2.1 connects with psycopg 3 too, so database_url() needs no change.

Create the application

Create application (createApplicationV3). It creates the web process and doesn’t deploy:

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

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; by default it starts a deployment before the database, the variable and the job exist.

Set the web process size

The API creates the web process at S1, not the dashboard’s H1. List processes (listProcessesV3) finds it, and Update process (updateProcessV3) sets H1:

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')
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 -r .resource_type_name

It prints 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.

Wait for the database

Get database (getDatabaseV3) until its status is ready, then keep its internal hostname and port:

for i in $(seq 1 90); do
  [ "$(curl -s "https://api.sevalla.com/v3/databases/$DB_ID" \
    -H "Authorization: Bearer $SEVALLA_API_KEY" | jq -r '.status // empty')" = ready ] && break
  sleep 10
done
DB_HOST=$(curl -s https://api.sevalla.com/v3/databases/$DB_ID \
  -H "Authorization: Bearer $SEVALLA_API_KEY" | jq -r .internal_hostname)
DB_PORT=$(curl -s https://api.sevalla.com/v3/databases/$DB_ID \
  -H "Authorization: Bearer $SEVALLA_API_KEY" | jq -r .internal_port)

CLI: sevalla databases get "$DB_ID" --json. MCP: get_database.

Connect the database

Create internal connection (createApplicationInternalConnectionV3):

curl -s -X POST https://api.sevalla.com/v3/applications/$APP_ID/internal-connections \
  -H "Authorization: Bearer $SEVALLA_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"target_id\": \"$DB_ID\", \"target_type\": \"database\"}"

CLI: sevalla databases connections internal-create "$DB_ID" --target-id "$APP_ID" --target-type app. MCP: sevalla_api_create with createApplicationInternalConnectionV3 and the same body.

Add the database URL

Unlike the dashboard, the API doesn’t add the connection’s variables. Create environment variable (createEnvironmentVariableV3) adds DB_URL in the dashboard’s format, available during runtime only (the API’s default is build and runtime):

curl -s -X POST https://api.sevalla.com/v3/applications/$APP_ID/env-vars \
  -H "Authorization: Bearer $SEVALLA_API_KEY" \
  -H "Content-Type: application/json" \
  -d @- <<EOF | jq -c '{key, is_runtime, is_buildtime}'
{
  "key": "DB_URL",
  "value": "postgres://storefront:$DB_PASSWORD@$DB_HOST:$DB_PORT/storefront",
  "is_runtime": true,
  "is_buildtime": false
}
EOF

It prints {"key":"DB_URL","is_runtime":true,"is_buildtime":false}. CLI:

sevalla apps env-vars create "$APP_ID" --key DB_URL --value "postgres://storefront:$DB_PASSWORD@$DB_HOST:$DB_PORT/storefront"

, which makes it available during build and runtime. MCP: set_environment_variables with runtime true and buildtime false.

Create the migration job

Create process (createProcessV3). A job needs job_start_policy, and every process needs scaling_strategy and resource_type_id:

curl -s -X POST https://api.sevalla.com/v3/applications/$APP_ID/processes \
  -H "Authorization: Bearer $SEVALLA_API_KEY" \
  -H "Content-Type: application/json" \
  -d @- <<EOF | jq -c '{display_name, type, job_start_policy, resource_type_name}'
{
  "display_name": "Migrate",
  "type": "job",
  "entrypoint": "alembic upgrade head",
  "job_start_policy": "beforeDeployment",
  "resource_type_id": "$H1_ID",
  "scaling_strategy": {"type": "manual", "config": {"instanceCount": 1}}
}
EOF

CLI:

sevalla apps processes create "$APP_ID" --name Migrate --type job --command "alembic upgrade head" --job-start-policy beforeDeployment --resource-type "$H1_ID"

. MCP: sevalla_api_create with createProcessV3 and the same body.

Deploy

Trigger deployment (triggerDeploymentV3) deploys the latest commit on the 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) until status is success or failed:

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"

It prints success when the deployment finishes, or failed; after 30 minutes without either, it prints the status it last read. On failed, read the build log with Get application deployment logs (getApplicationDeploymentLogsV3), as in Verify the deployment. CLI: sevalla apps deployments get "$DEPLOYMENT_ID" --app-id "$APP_ID". MCP: get_deployment, then get_deployment_logs.

Turn on auto-deploy

Update application (updateApplicationV3):

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 -r .auto_deploy

It prints true. CLI: sevalla apps update "$APP_ID" --data '{"auto_deploy": true}'. MCP: sevalla_api_update with updateApplicationV3 and the same body.

List application domains (listApplicationDomainsV3) returns the domain to run the checks in Verify the deployment against:

APP_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://$APP_HOST/

The response is {"items":0}. To build from the Dockerfile instead, send {"build_type": "dockerfile", "dockerfile_path": "Dockerfile", "docker_context": "."} to Update application, then deploy and wait again. CLI: sevalla apps update "$APP_ID" --build-type dockerfile --dockerfile-path Dockerfile.

Get started

Migrate

AI

JavaScript

Python

PHP

Ruby

Go

Rust

Java, Kotlin and Scala

.NET

Elixir

Gleam

Swift

Dart

Static site generators

Deploy a FastAPI application

At a glance

Environment variables

Before you begin

Create the project

Prepare the project for Sevalla

Set up migrations

Pin the Python version

Check the start command

List the dependencies

Deploy to Sevalla

Verify the deployment

Deploy with a Dockerfile

Deploy changes

Add a custom domain

Troubleshoot the deployment

Deploy with the API

​At a glance

​Environment variables

​Before you begin

​Create the project

​Prepare the project for Sevalla

​Set up migrations

​Pin the Python version

​Check the start command

​List the dependencies

​Deploy to Sevalla

​Verify the deployment

​Deploy with a Dockerfile

​Deploy changes

​Add a custom domain

​Troubleshoot the deployment

​Deploy with the API

At a glance

Environment variables

Before you begin

Create the project

Prepare the project for Sevalla

Set up migrations

Pin the Python version

Check the start command

List the dependencies

Deploy to Sevalla

Verify the deployment

Deploy with a Dockerfile

Deploy changes

Add a custom domain

Troubleshoot the deployment

Deploy with the API