Deploy a Flask application

A Flask project runs on Sevalla as an application built from your Git repository: Ingot, the default builder, finds the application factory and serves it with Gunicorn in the web process, and a job runs the migrations before each deployment. The 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	`gunicorn -c /etc/ingot/gunicorn.conf.py app:create_app()`, which Ingot detects from `create_app` in `app/__init__.py`
Port	The `PORT` environment variable, `8080` by default
Processes	Web process; `Migrate` job (`flask db upgrade`, Before deployment)
Services	PostgreSQL 18 over an internal connection
Disk	None
Health check	None; see Add Flask 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>`
`FLASK_SECRET_KEY`	No	Runtime	Yes	Signs Flask sessions. Generate with `python3 -c "import secrets; print(secrets.token_hex(32))"`
`PORT`	No	Runtime	No	Set by Sevalla to the web process port
`WEB_CONCURRENCY`	No	Runtime	No	Number of Gunicorn 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, the version the project runs on in Sevalla.

Create the project

Create a virtual environment and install Flask, the database extensions, Gunicorn and the PostgreSQL driver:

mkdir storefront && cd storefront
python3 -m venv .venv
source .venv/bin/activate
pip install flask flask-sqlalchemy-lite flask-alembic gunicorn "psycopg[binary]"
mkdir app

Package	What it does
`flask`	Flask 3.1
`flask-sqlalchemy-lite`	Connects SQLAlchemy to the Flask application and its configuration
`flask-alembic`	Database migrations, as `flask db` commands
`gunicorn`	Production WSGI server. Ingot serves a Flask application with it when it’s installed.
`psycopg[binary]`	PostgreSQL driver

Keep local files out of the repository:

.gitignore

.venv/
__pycache__/
.env
instance/

Add a model and the extensions:

app/models.py

from sqlalchemy.orm import DeclarativeBase, Mapped, mapped_column

class Model(DeclarativeBase):
    pass

class Item(Model):
    __tablename__ = "item"

    id: Mapped[int] = mapped_column(primary_key=True)
    name: Mapped[str]

app/extensions.py

from flask_alembic import Alembic
from flask_sqlalchemy_lite import SQLAlchemy

from app.models import Model

db = SQLAlchemy()
alembic = Alembic(metadatas=Model.metadata)

Add the application factory, with a route that lists items and one that adds an item. Sevalla’s connection URLs start with postgres://, which SQLAlchemy doesn’t accept, so the code switches the scheme to postgresql+psycopg://:

app/__init__.py

import os

import sqlalchemy as sa
from flask import Flask, request

from app.extensions import alembic, db
from app.models import Item


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


def create_app() -> Flask:
    app = Flask(__name__)
    app.config["SQLALCHEMY_ENGINES"] = {"default": database_url()}
    # Loads every FLASK_* environment variable, for example FLASK_SECRET_KEY.
    app.config.from_prefixed_env()

    db.init_app(app)
    alembic.init_app(app)

    @app.get("/items")
    def list_items():
        items = db.session.scalars(sa.select(Item).order_by(Item.id))
        return [{"id": item.id, "name": item.name} for item in items]

    @app.post("/items")
    def create_item():
        item = Item(name=request.json["name"])
        db.session.add(item)
        db.session.commit()
        return {"id": item.id, "name": item.name}, 201

    return app

DB_URL is the variable Sevalla adds when you connect the database; without it, the project uses SQLite in the instance folder. Generate the first migration, apply it to the local database and start the development server. The flask command finds the factory in the app package on its own, so it needs no --app option. Flask-Alembic keeps migrations in app/migrations:

flask db revision "Create item table"
flask db upgrade
flask run --port 8000

Open http://127.0.0.1:8000/items. The response is [].

Prepare the project for Sevalla

Ingot, the default build strategy, needs no settings to build and start this project:

It looks for a Flask application, or a factory function named create_app or make_app, at the top level of the modules it searches, app/__init__.py among them. It finds create_app and starts the web process with gunicorn app:create_app(), so the project needs no start command. See Set the start command.
Gunicorn listens on 0.0.0.0 and the port in the PORT environment variable, which Sevalla sets to the web process’s port (8080 by default).
Ingot’s Gunicorn settings run 1 worker process with 4 threads. On a larger size, add a WEB_CONCURRENCY environment variable with the number of worker processes you want, such as 3.
Migrations don’t run in the web process. A job runs them once per deployment.

Add two files to the project: the Python version, so the build doesn’t depend on Ingot’s default, and the exact versions of the dependencies.

Pin the Python version

Without a version in the project, Ingot builds on its default Python line, 3.14 in Ingot 0.5.0, and a new Ingot release can move that default. Pin the version in .python-version, the first file Ingot reads it from. See Pin the Python version.

.python-version

3.14

List the dependencies

Ingot installs requirements.txt with pip, into a virtual environment in the image:

pip freeze > requirements.txt

Commit everything, including app/migrations, 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.

Add the environment variables

Click the Environment variables tab, then click Add environment variables. Add FLASK_SECRET_KEY with a random string of 32 characters or more (generate one with python3 -c "import secrets; print(secrets.token_hex(32))"), keep Available during runtime selected, and click Add environment variables. Flask signs sessions with it.

Create the migration job

Click the Processes tab, then click Create process. Choose Job, enter Migrate as the Name and flask db upgrade 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: Python 3.14 from .python-version, pip from requirements.txt, and Flask with the start command from app/__init__.py.

Build log

╭─ ■ Flask · Python 3.14 ───────────────────────────────────────────────────────────────────────────╮
│ Python           3.14                                                      .python-version "3.14" │
│ Package manager  pip                                                       requirements.txt       │
│ Framework        Flask                                                     app/__init__.py        │
│ Start            gunicorn -c /etc/ingot/gunicorn.conf.py app:create_app()  Flask                  │
├─ 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 ─╯

Wait for the deployment’s status to change to Deployed. The application’s status next to its name changes to Running. Before the web process rolls out, the build log shows Migrate has been successful; if the job fails, the deployment fails and nothing changes for visitors. On the Logs tab, with Process set to Migrate, the job’s output ends with Running upgrade -> <revision>, Create item table.
Add an item and list the items, with your application’s domain. The domain is under the application’s name, for example storefront-x7k2m.sevalla.app:
curl -X POST https://storefront-x7k2m.sevalla.app/items -H "Content-Type: application/json" -d '{"name": "Coffee mug"}' curl https://storefront-x7k2m.sevalla.app/items
The first command returns {"id":1,"name":"Coffee mug"} and the second [{"id":1,"name":"Coffee mug"}]: the application writes to and reads from the PostgreSQL database.

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 -> 1793297088, 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 ["gunicorn", "app:create_app()", \
     "--threads", "4", "--keep-alive", "0", \
     "--graceful-timeout", "20", "--worker-tmp-dir", "/dev/shm"]

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 Gunicorn as an unprivileged user with a home directory, where Gunicorn keeps its control socket. The code stays owned by root, so the application can’t change it.
`FORWARDED_ALLOW_IPS="*"`	Gunicorn trusts the `X-Forwarded-Proto` header from Sevalla’s proxy, so Flask sees HTTPS requests as HTTPS. Ingot sets the same.
Gunicorn options	Gunicorn listens on `0.0.0.0` and the port in `PORT` on its own, and reads `WEB_CONCURRENCY`. `--threads 4`, `--graceful-timeout 20` and `--worker-tmp-dir /dev/shm` match Ingot’s settings. `--keep-alive 0` closes each connection after its response: otherwise Gunicorn 26.2 waits out the whole graceful timeout before it stops when the proxy holds an idle connection open.
No init process	Gunicorn runs as PID 1, handles `SIGTERM` itself, finishes the requests in progress and exits.

.dockerignore

.git
.venv
**/__pycache__
.env*
instance
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 flask db upgrade in the new image. curl https://storefront-x7k2m.sevalla.app/items still returns [{"id":1,"name":"Coffee mug"}], from the same database, and 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 flask db revision "<message>" locally 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. Flask 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 Flask application`	The application or its factory isn’t at the top level of a module Ingot searches, for example because the package is named `storefront` instead of `app`.	Move the factory to `app/__init__.py`, or set the web process’s Custom start command on the Processes tab, for example `gunicorn 'storefront:create_app()'`.
The build fails with `Flask needs a production server, and gunicorn isn't installed`	`requirements.txt` doesn’t list Gunicorn.	Run `pip install gunicorn`, then `pip freeze > requirements.txt`, and push the change.
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 deployment fails at `Migrate has failed`	The migration raised an error, or the job can’t reach the database.	On the Logs tab, set Process to `Migrate` and read the job’s output. Check that the internal connection exists, that `DB_URL` is set, and that `app/migrations` is in the repository.

For more causes, see Troubleshoot Ingot builds and Troubleshoot builds and deployments. To add caching, background tasks or health checks, see the Flask 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 step that connects the database and the DB_URL line of the next step. 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 environment variables

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

FLASK_SECRET_KEY=$(openssl rand -hex 32)
while read -r KEY VALUE; do
  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 "{\"key\": \"$KEY\", \"value\": \"$VALUE\", \"is_runtime\": true, \"is_buildtime\": false}" \
    | jq -c '{key, is_runtime, is_buildtime}'
done <<EOF
DB_URL postgres://storefront:$DB_PASSWORD@$DB_HOST:$DB_PORT/storefront
FLASK_SECRET_KEY $FLASK_SECRET_KEY
EOF

It prints one line per variable, such as {"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"

, and the same for FLASK_SECRET_KEY; the CLI makes them available during build and runtime. MCP: set_environment_variables with both, 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": "flask db upgrade",
  "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 "flask db upgrade" --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/items

The response is []. 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 Flask application

At a glance

Environment variables

Before you begin

Create the project

Prepare the project for Sevalla

Pin the Python version

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

​Pin the Python version

​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

Pin the Python version

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