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. The corresponding base Docker images are open source and can be found on the Docker hub:

All Scalingo-supported buildpacks are compatible with supported stacks.

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

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-22 |
[...]
+----------------+-------------+

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.

You can migrate to the latest stack with:

scalingo --app my-app stacks-set scalingo-22

Then redeploy your application:

git commit --allow-empty -m "Upgrading to scalingo-22"
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-22"
}

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-22
$ docker run --rm -it scalingo/scalingo-22: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.