Applications on Scalingo run inside Linux containers. These containers are built from a base image maintained by Scalingo, itself derived from an official Ubuntu Long-Term Support Docker image.

This base image is referred to as a stack.

Scalingo currently supports three stacks:

The default stack for all newly created applications is scalingo-26.

Understanding How the Stack is Built

Since the stacks are shared across all applications hosted on the platform, they are designed to remain generic and unspecialized.

We complete the Ubuntu LTS base image with different libraries and softwares commonly used in build processes or used by human when running one-off containers:

• Build essentials utility (GCC, make, autotools, …)
• curl, git, telnet, ssh, ssh-client, openssl, dnsutils, sqlite, rsync, jq, …
• Ruby, Perl, Python
• ImageMagick
• PostgreSQL and MySQL related tools and libraries

Please refer to the dedicated page of each stack for an exhaustive list of packages available.

Understanding How the Stack is Used

Each time an application is built, a new specific container image is generated for your app. This image consists of the stack, plus an additional layer containing the application. This additional layer is built by the platform, using buildpacks. A buildpack typically transforms (e.g. compiles, installs dependencies, …) the application’s source code into an executable artifact.

Once the build process succeeds, the resulting image is pushed to our private registry, where it is later retrieved by our orchestrator to run the application within our infrastructure.

Using a shared base image (i.e. the stack) provides a significant performance advantage: once it has been downloaded onto a hosting node, it can be reused for all applications relying on the same stack. Although this approach slightly increases disk usage due to the inclusion of additional tools and libraries in the image (see above), starting a new container only requires fetching the application-specific layer, thus reducing both startup time and network transfers.

Understanding the Stack Lifecycle

Because the stack is built on Ubuntu Long-Term Support (LTS) releases, its availability, maintenance, and retirement follow as much as possible the support milestones defined by Ubuntu. This approach ensures that the stack benefits from the stability, security updates, and predictable release cadence of the upstream Ubuntu LTS ecosystem. We also hope it provides a clear timeline for upgrades and support.

• A stack lifecycle begins when a new Ubuntu LTS release comes out. We create a new stack from this Ubuntu release, thoroughly test it against our official buildpacks, and release it as soon as everything looks good. From this point, the stack’s status is Supported.

  During this period, the stack receives regular updates. Packages included in the stack are updated approximately every quarter, and new packages may be introduced to provide additional features. If a security issue affecting the stack is identified, a new version is released as quickly as possible.

• Roughly a year before support for the base distribution ends, the stack enters its End-Of-Life (EOL) phase. Its status changes from Supported to Deprecated .

  During this phase, the stack still remains actively supported, and keeps receiving regular updates. Yet, users are strongly encouraged to move their applications to a more recent stack to avoid any future unforeseen consequences.

• When the official support for the base distribution ends, the stack status switches to Discontinued, meaning it no longer receives updates, nor security fixes.

  Existing applications running on a Discontinued stack keep running. However, the stack is no longer available on the platform. Consequently, all new deployments of the application, including Review Apps, are done using the new default stack.

Viewing Your App’s Stack Name

Using the Command Line

1. Make sure you have correctly setup the Scalingo command line tool
2. From the command line, list the information for the application:

   scalingo --app my-app apps-info
   

   The output should look like this:

   +----------------+-------------+
   |    SETTINGS    |    VALUE    |
   +----------------+-------------+
   [...]
   | Stack          | scalingo-24 |
   [...]
   +----------------+-------------+
   

Migrating to a Different Stack

Planning the Migration

• If you have a staging application hosted on Scalingo, follow the instructions below to migrate to a more recent stack. Conduct your tests and deploy your fixes until your validation process is all green lights.

• Another way to test the stack upgrade without affecting your currently running application consists in creating a review app. Add a scalingo.json file to your project to specify the stack used to deploy the review app, like so:

  {
    "stack": "<stack name>"
  }
  

  Make sure your review app deploys successfully and works flawlessly.

• As always, make sure you have a valid, tested backup before you actually migrate your production applications. Also prioritize low-traffic hours to minimize a potential negative impact.

• Once your application is ready for the new stack, migrate to the desired stack and redeploy using a method described hereafter.

Migrating

Using the Dashboard

1. From your web browser, open your dashboard
2. Open the target application
3. Click the Settings tab
4. In the Settings submenu, select General
5. In the Scalingo Stack section, click Change Scalingo Stack
6. Select the new stack
7. Click Change
8. Trigger a new deployment to apply the stack change immediately
9. Run your functional tests to validate compatibility with the new stack

Using the Command Line

1. Make sure you have correctly setup the Scalingo command line tool
2. From the command line, list available stacks:

   scalingo stacks
   

   The output should look like this:

   ┌─────────────────────────────────────────┬─────────────────────┬──────────────────────────────────────────────────┬───────────┐
   │                   ID                    │        NAME         │                   DESCRIPTION                    │ DEFAULT ? │
   ├─────────────────────────────────────────┼─────────────────────┼──────────────────────────────────────────────────┼───────────┤
   │ st-460d3f35-573b-40da-9316-b8f7e737f416 │ scalingo-26         │ Scalingo Stack based on Ubuntu 26.04 LTS         │ Yes       │
   │ st-e063df00-0cef-4950-bdc7-4d0a9f72c6b0 │ scalingo-24         │ Scalingo Stack based on Ubuntu 24.04 LTS         │ No        │
   │ st-7ccbf8e6-04d3-4e2c-98e3-604a4700cebc │ scalingo-22         │ Scalingo Stack based on Ubuntu 22.04 LTS         │ No        │
   

3. Set the stack used to run your application:

   scalingo --app my-app stacks-set <stack name>
   

   With stack name being the name of the stack you want to run.

4. Redeploy your application:

   git commit --allow-empty -m "Upgrading to <stack name>"
   git push scalingo master
   

Setting the Timezone

The timezone configured inside our base image is UTC±00:00. You can set it to a different value by setting the environment variable TZ with the desired timezone:

scalingo --app my-app env-set TZ=Europe/Paris

Our stacks are standard Docker images, and are free to download, use, or inspect:

docker pull scalingo/scalingo-26
docker run --rm -it scalingo/scalingo-26:latest bash