Deploy Swift applications

A Swift web server runs on Sevalla as an application: 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

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 in the repository, with the Dockerfile build strategy. Ingot, 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.
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 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.
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.
Files	The filesystem resets on every deployment. Keep uploads in object storage, or attach a disk.

Every process (web, worker, cron job and job) runs from the same image, each with its own start command. See Processes.

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 has a tested Dockerfile and what it changes from the one that vapor new generates.

Get started

Migrate

AI

JavaScript

Python

PHP

Ruby

Go

Rust

Java, Kotlin and Scala

.NET

Elixir

Gleam

Swift

Dart

Static site generators

Deploy Swift applications

Framework guides

Vapor

How Swift applications run on Sevalla

Pin the Swift version

Build with a Dockerfile

​Framework guides

Vapor

​How Swift applications run on Sevalla

​Pin the Swift version

​Build with a Dockerfile

Framework guides

How Swift applications run on Sevalla

Pin the Swift version

Build with a Dockerfile