Skip to main content

Deploying Apps

Sprintsail supports three deployment strategies: automatic buildpack detection, Dockerfile builds, and pre-built container images.

The ss push flow​

Every deployment follows the same lifecycle:

  1. Upload --- source code or image reference is sent to the platform
  2. Build --- source is compiled into an OCI container image
  3. Deploy --- new containers roll out with zero-downtime updates
  4. Route --- traffic shifts to the new revision once health checks pass
cd my-app
ss push
Uploading source (4.1 MB)... done
Building with Paketo Buildpacks...
  -> Detecting... Python
  -> Installing dependencies... pip install
  -> Exporting to OCI image...
Build succeeded (38s)
Deploying to production...
  -> Rolling update: 0/2 -> 1/2 -> 2/2
  -> Health check passed
  -> Route active: https://my-app.my-org.sprintsail.com
Deploy succeeded (12s)

Build strategies​

Buildpacks (default)​

Sprintsail uses Cloud Native Buildpacks via the Paketo project to automatically detect your language and build a production-optimized image. No configuration needed.

Supported runtimes:

RuntimeDetection
Node.jspackage.json
Pythonrequirements.txt, Pipfile, pyproject.toml
Gogo.mod
Javapom.xml, build.gradle
RubyGemfile
.NET*.csproj, *.sln
PHPcomposer.json
RustCargo.toml

Force a specific buildpack:

ss push --buildpack paketo-buildpacks/nodejs

Dockerfile​

If a Dockerfile exists in your project root, Sprintsail uses it automatically. To force Dockerfile builds when both a Dockerfile and buildpack-detectable files exist:

ss push --strategy dockerfile

Point to a non-default Dockerfile:

ss push --dockerfile path/to/Dockerfile.prod

Pre-built image​

Deploy an existing image from any OCI-compatible registry:

ss push --image ghcr.io/my-org/my-app:v2.1.0

The image must expose a port via EXPOSE or the PORT environment variable. Authentication for private registries is configured with:

ss registry add ghcr.io --username my-user --password-stdin

Rolling updates​

By default, Sprintsail performs rolling updates. New containers start alongside old ones, and traffic shifts once health checks pass. Old containers are drained and stopped.

Configuration via ss.yaml or CLI flags:

# ss.yaml
deploy:
  strategy: rolling
  max_surge: 1
  max_unavailable: 0
  health_check:
    path: /health
    interval: 10s
    timeout: 5s
    retries: 3
ss push --health-check-path /health --max-surge 2

If a deploy fails health checks, it automatically rolls back to the previous revision.

Rollback​

Roll back to the previous revision:

ss rollback my-app

Roll back to a specific revision:

ss rollback my-app --revision 5

List available revisions:

ss revisions my-app
REV   STATUS    IMAGE                CREATED            TRAFFIC
7     active    my-app:build-7       2 minutes ago      100%
6     inactive  my-app:build-6       1 hour ago         0%
5     inactive  my-app:build-5       3 hours ago        0%

Sprintsail retains the last 10 revisions by default.

Build configuration​

Ignoring files​

Create a .ssignore file (or use .dockerignore) to exclude files from uploads:

node_modules/
.git/
*.log
.env

Build environment variables​

Set variables available only during the build phase:

ss env set my-app --build NPM_TOKEN=abc123

Build caching​

Buildpack builds use layer caching by default. To force a clean build:

ss push --no-cache

App configuration file​

Define app settings in ss.yaml at your project root:

name: my-app
instances: 2
memory: 512Mi
cpu: 250m

env:
  NODE_ENV: production

deploy:
  strategy: rolling
  health_check:
    path: /health

services:
  - my-postgres
  - my-redis

Values in ss.yaml serve as defaults. CLI flags and ss env set override them.

Next steps​