> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sevalla.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> These are the docs for Sevalla, a platform for deploying applications, databases, static sites, object storage and load balancers. The dashboard is at https://app.sevalla.com.
> Bold text in steps is an exact dashboard label.
> To act on a Sevalla account, prefer the Sevalla MCP server (https://mcp.sevalla.com/mcp, see https://docs.sevalla.com/ai-agents/overview.md), then the Sevalla CLI (https://docs.sevalla.com/developer-tools/cli.md), then the REST API (https://api-docs.sevalla.com, OpenAPI spec at https://api.sevalla.com/v3/openapi.json).
> Every page index is at https://docs.sevalla.com/llms.txt.

# Deploy Swift applications

> How Swift server applications build and run on Sevalla: a Dockerfile on the official swift images, the Swift version, the PORT variable, databases, migrations in a job and shutdown.

A Swift web server runs on Sevalla as an [application](https://docs.sevalla.com/applications/overview.md): Sevalla builds an image from the Dockerfile in your Git repository, which compiles your Swift package into one executable on the official `swift` image, and runs that executable as processes. The web process serves HTTP, and jobs run database migrations with the same executable before each deployment.

## Framework guides

> **[Vapor](https://docs.sevalla.com/guides/swift/vapor.md)**
>
> Deploy Vapor 4 with Fluent and PostgreSQL, built on the official swift images, with the migrations in a job.

## How Swift applications run on Sevalla

| Part | On Sevalla |
| - | - |
| Build | A [Dockerfile](https://docs.sevalla.com/applications/builds/dockerfile.md) in the repository, with the **Dockerfile** build strategy. [Ingot](https://docs.sevalla.com/applications/builds/ingot.md), the default for new applications, has no Swift provider: its build stops with `Ingot couldn't tell what kind of application this is`. Choose the Dockerfile build strategy on the application's **Settings** tab before the first deployment. |
| Package manager | Swift Package Manager. Commit `Package.resolved`, and resolve with `swift package resolve --force-resolved-versions`, which builds exactly the versions you tested and fails when `Package.resolved` doesn't match `Package.swift`. |
| Swift version | The tag of the image the Dockerfile builds on, such as `swift:6.4-noble`. See [Pin the Swift version](#pin-the-swift-version). |
| What runs | The release build of the executable product, `swift build -c release --product <name>`, on the image's `-slim` variant, which has the Swift runtime libraries without the compiler |
| Start command | The Dockerfile's `ENTRYPOINT` and `CMD`. A process's **Custom start command** replaces both, so a job names the executable, such as `/app/storefront migrate --yes`. |
| Port | Sevalla sets `PORT` to the web process's port, `8080` by default. Read it in code and listen on `0.0.0.0`: Vapor listens on `127.0.0.1:8080` unless told otherwise. |
| Migrations | A job with the start policy **Before deployment** that runs the executable's migration command, such as Vapor's `migrate --yes`. When the job fails, the deployment fails and the previous version keeps running. |
| Databases | PostgreSQL, MySQL, MariaDB, Redis or Valkey on Sevalla, reached over an [internal connection](https://docs.sevalla.com/databases/connect.md#connect-an-application) that adds `DB_URL` and the other connection variables. Vapor's PostgreSQL driver accepts the `postgres://` URL; turn its TLS off for the internal connection, as in the [Vapor guide](https://docs.sevalla.com/guides/swift/vapor.md#prepare-the-project-for-sevalla). |
| Shutdown | Vapor's `serve` command handles `SIGTERM` as process 1, so the image needs no init process. |
| Crashes | The slim image has Swift's backtracer: a crash prints `Program crashed:` and a stack trace for each thread to the [runtime logs](https://docs.sevalla.com/applications/logs.md). |
| Files | The filesystem resets on every deployment. Keep uploads in [object storage](https://docs.sevalla.com/object-storage/overview.md), or attach a [disk](https://docs.sevalla.com/applications/disks.md). |

Every process (web, worker, cron job and job) runs from the same image, each with its own start command. See [Processes](https://docs.sevalla.com/applications/processes.md).

## Pin the Swift version

The Dockerfile's `FROM` lines set the Swift version: `swift:6.4-noble` compiles with the newest Swift 6.4 release, and `swift:6.4-noble-slim` runs the executable on the runtime libraries of the same release. Keep both stages on the same version and Ubuntu release, because the executable links to the runtime libraries of the compiler that built it.

A line tag such as `6.4-noble` moves to each 6.4 patch release and to Ubuntu's security fixes, so every new build picks them up. A full version, such as `6.4.1-noble`, stays on that release. The `swift-tools-version` line at the top of `Package.swift` is the oldest Swift that can read the manifest, not the version that builds it.

## Build with a Dockerfile

A Dockerfile for a Swift application builds in one stage and runs in another. The build stage uses the official `swift` image, copies `Package.swift` and `Package.resolved` first and resolves the dependencies in their own layer, then copies the sources and builds the executable product in release mode. The dependencies compile again on every build, which takes most of the build time. The final stage starts from the matching `-slim` image, copies only the executable, owned by root, and runs it as user `1000:1000` with an exec-form `ENTRYPOINT`, so the server is process 1 and receives `SIGTERM`. The [Vapor guide](https://docs.sevalla.com/guides/swift/vapor.md#deploy-with-a-dockerfile) has a tested Dockerfile and what it changes from the one that `vapor new` generates.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.