Applications on Scalingo run inside Linux containers. These containers are built on a base image maintained by Scalingo, which itself is derived from the official Docker image of a well-known Linux distribution.

Scalingo currently supports two stacks based on Ubuntu LTS.

All Scalingo-supported buildpacks are compatible with supported stacks.

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

These base images are used for all applications hosted on the platform, as a result, it is a generic image which is unspecialized. That’s why they are based on a stable Ubuntu LTS environment.

Viewing Stack Used by your Application

The stack used by your application is available using Scalingo CLI:

scalingo --app my-app apps-info
+----------------+-------------+
|    SETTINGS    |    VALUE    |
+----------------+-------------+
[...]
| Stack          | scalingo-26 |
[...]
+----------------+-------------+

Migrating to a New Stack

Updating the stack can have a significant impact on your application. Consequently, we warmly recommend testing your applications in a staging environment before making changes in production.

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 scalingo-26
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 CLI

You can migrate to the latest stack with:

scalingo --app my-app stacks-set scalingo-26

Then redeploy your application:

git commit --allow-empty --message="Upgrading to scalingo-26"
git push scalingo master

You can view the list of all available stacks with the CLI:

scalingo stacks

Using a Staging Application

It is advisable to first test this change on a staging application. You may already have such staging application hosted on Scalingo. In such situation, the above-mentioned migration steps can be applied to it.

Using a Review App

Otherwise, a nice solution to test the stack upgrade without affecting your currently running application is to create a review app and add a scalingo.json file containing:

{
  "stack": "scalingo-26"
}

Make sure your review app deploys successfully and works flawlessly. Once your application is ready for the new stack, migrate to the desired stack and redeploy with the method described above.

The Build Process

Each time any user deploys a new release of their applications, a new container image is created. A new layer is added on top of the base image. It’s built using the buildpack and contains the application code and all its dependencies. When the build is done, the resulting image is sent to our private repository and our orchestrator will use it subsequently to actually run the application in our infrastructure.

The maximum build time is 30 minutes. After that duration the build will be cancelled by the platform.

Installed Libraries

We’ve installed different libraries and softwares which are commonly used in the build process or used by human when running one-off container.

You’ll find:

• Build essentials utility (GCC, make, autotools, …)
• Curl, git, telnet, ssh, ssh-client, openssl, dnsutils, sqlite
• Node.js, Ruby, Perl, Python, Java
• ImageMagick

The advantage of using a single base image is that once it has been fetched on a hosting node, we’re done. Even if we sacrifice a few megabytes of disk space, when a new container starts, only the application layer is fetched and nothing else.

Of course you can inspect this base image: it’s a completely standard Docker image after all! You can use something like:

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

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

A list of existing timezones is available here.

Stack End-Of-Life

EOL stands for End-of-Life and describes the retirement process of a stack. During this process, a stack remains supported until its documented end-of-support date. After that date, customers must migrate to a newer supported stack.

A stack usually enters the end-of-life process about one year before its end-of-support date. Scalingo informs customers using a stack scheduled for end-of-life when this process starts.

Applications already deployed on a deprecated stack continue to run, even after the stack is discontinued. However, once the stack is discontinued, all new deployments, including Review Apps, must use a newer supported stack.