Documentation Center

Overview

Fri, 09 Oct 2026 12:00:00 +0000

OpenSearch®

OpenSearch® is a free and open-source search and analytics engine developed by Amazon and designed as a community-driven fork of Elasticsearch® 7.10, after Elastic® changed its licensing model. It allows users to ingest, search, visualize, and analyze large volumes of data quickly and in real time. OpenSearch® supports a variety of use cases such as log analytics, observability, and enterprise search, thanks to its powerful full-text search capabilities, scalability and RESTful API. Its modular design makes it a very good choice for both small applications, and large-scale, distributed systems.

Scalingo for OpenSearch®

Scalingo for OpenSearch® is our official OpenSearch® addon. We have several plans available from which you can choose depending on your needs and budget.

Please make sure to also see Features and Limitations, as well as the dedicated Plugins page to get a comprehensive view of what is included in our offers.

Life-Cycle

OpenSearch® delivers feature releases every few months, with major versions released approximately once a year. At Scalingo, we focus on providing stable and well-supported OpenSearch® versions for production workloads.

Our managed service currently includes version 2.x, with plans to introduce version 3.x once it becomes stable and widely adopted. However, as the OpenSearch® roadmap is not finalized, the exact timeline for this upgrade depends on the availability and maturity of the 3.x release.

Each major version we provide benefits from minor upgrades including critical bug fixes and security patches.

Available Versions

OpenSearch Version	Full Version
`2`	up to `2.19.6`

The default version when provisioning a Scalingo for OpenSearch® addon is 2.19.6-1.

Pricing

Our prices are detailed on our dedicated page.

Billing of your Scalingo for OpenSearch® addon is done on a minute basis.

If your database disk usage exceeds the threshold set on your plan, the over-quota is billed per GB-hour (see our FAQ for further details).

OpenSearch - New Scalingo release: 2.19.6-1

Fri, 09 Oct 2026 12:00:00 +0000

New default version: 2.19.6-1.

Changelog:

Docker images on Docker Hub:

scalingo/opensearch:2.19.6-1

Understanding Roles

Fri, 09 Oct 2026 07:00:00 +0000

Scalingo currently provides three predefined roles to help you adapt permissions to the level of responsibility you want to delegate to your collaborators: Owner, Collaborator and Limited Collaborator.

Owner

Reserved for the application owner, the Owner role grants the highest level of permissions, including full administrative control such as renaming or deleting the application. The Owner is also the one who is billed for the project’s usage.

Collaborator

The Collaborator role is intended for trusted team members who are directly responsible for the configuration, deployment, and operational maintenance of applications and databases. It grants broad permissions, including access to environment variables, hosted data, deployment settings, and collaborator management, making it suitable for lead developers or DevOps engineers who need full technical control over the application.

While collaborators can perform almost all actions, including inviting and managing other users, they cannot delete or rename the application. Those actions remain reserved for the Owner.

Limited Collaborator

The Limited Collaborator role is designed to minimize the risks associated with granting access to third parties or collaborators without operational responsibility. It allows contributors to perform essential day-to-day operations such as restarting applications, viewing logs or metrics, and managing review apps while preventing actions that could compromise the stability, confidentiality, or integrity of your services.

This role explicitly restricts access to critical operations like modifying configurations, deploying unvalidated code, exploring or exporting sensitive data and managing collaborators.

It is especially suited for environments where separation of duties is required. It ensures that users can contribute to the project without being able to compromise service stability, data integrity, or team governance.

Role Capabilities

Overview

The following table provides a synthetic overview of the main permissions associated with each role. In most cases, it should be enough to select the role that best suits your collaborators. However, we also provide an exhaustive list of access rights associated with each role.

	Owner	Collaborator	Limited Collaborator
Destructive Actions	🟢 Yes	🔴 No	🔴 No
App Configuration	🟢 Yes	🟢 Yes	🔴 No
Deployment	🟢 Yes	🟢 Yes	🟡 Limited
Add-ons Management	🟢 Yes	🟢 Yes	🔴 No
Collaborator Management	🟢 Yes	🟢 Yes	🔴 No
Access Data & Secrets	🟢 Yes	🟢 Yes	🔴 No
Public Routing Configuration	🟢 Yes	🟢 Yes	🔴 No

Permissions Matrices

The following tables detail the permissions available to collaborators of an app, grouped by scope, and differentiated according to the collaborator’s role. The Owner role is not listed, as it holds full and unrestricted access to all application resources.

Application Lifecycle

Permission	Collaborator	Limited Collaborator
Restart app	🟢 Yes	🟢 Yes
Stop app	🟢 Yes	🔴 No
Scale vertically	🟢 Yes	🔴 No
Scale horizontally	🟢 Yes	🔴 No
Setup an autoscaler	🟢 Yes	🔴 No
Update the settings of an autoscaler	🟢 Yes	🔴 No
Grant data access to Scalingo support operators	🟢 Yes	🟢 Yes
Manage log drains	🟢 Yes	🔴 No
Create a child app	🟢 Yes	🔴 No

Monitoring and Logs

Permission	Collaborator	Limited Collaborator
View activity	🟢 Yes	🟢 Yes
View activity details	🟢 Yes	🟡 Yes (env-vars values are hidden)
View logs	🟢 Yes	🟢 Yes
Download log archives	🟢 Yes	🔴 No
View metrics	🟢 Yes	🟢 Yes

App Configuration

Permission	Collaborator	Limited Collaborator
Delete app	🔴 No	🔴 No
Rename app	🔴 No	🔴 No
Change app’s stack	🟢 Yes	🔴 No

Managing Collaborators and Their Access

Permission	Collaborator	Limited Collaborator
Invite collaborator	🟢 Yes	🔴 No
Revoke collaborator’s access	🟢 Yes	🔴 No
Change collaborator’s role	🟢 Yes	🔴 No

Deployments

Permission	Collaborator	Limited Collaborator
Configure SCM	🟢 Yes	🔴 No
Manage automatic deployments	🟢 Yes	🔴 No
Redeploy any branch	🟢 Yes	🔴 No
Redeploy the branch set as the default one	🟢 Yes	🟢 Yes
Access deployments history	🟢 Yes	🟢 Yes
Access deployments logs	🟢 Yes	🟡 Yes (only for deployments < 7 days)
Reset deployment cache	🟢 Yes	🟢 Yes

Public Routing

Permission	Collaborator	Limited Collaborator
Manage custom domains	🟢 Yes	🔴 No
Manage Firewall Rules	🟢 Yes	🔴 No
Configure public routing	🟢 Yes	🔴 No

One-Off Containers and Scheduled Jobs

Permission	Collaborator	Limited Collaborator
List one-offs	🟢 Yes	🟢 Yes
Create a one-off	🟢 Yes	🔴 No
Access a one-off	🟢 Yes	🔴 No
List cron jobs	🟢 Yes	🟢 Yes

Environment Variables

Permission	Collaborator	Limited Collaborator
Manage environment variables	🟢 Yes	🔴 No
View environment variables names	🟢 Yes	🟢 Yes
View environment variables values	🟢 Yes	🔴 No

Review Apps

Permission	Collaborator	Limited Collaborator
Configure review apps	🟢 Yes	🔴 No
List review apps	🟢 Yes	🟢 Yes
Create review apps	🟢 Yes	🟡 Yes (only via SCM Tool if allowed)
Close review apps	🟢 Yes	🟢 Yes
Redeploy a review app	🟢 Yes	🟢 Yes

Add-ons

Permission	Collaborator	Limited Collaborator
Provision an add-on	🟢 Yes	🔴 No
Access an add-on dashboard	🟢 Yes	🔴 No
Change an add-on plan	🟢 Yes	🔴 No
Remove an add-on	🟢 Yes	🔴 No

Databases

Permission	Collaborator	Limited Collaborator
Access a database dashboard	🟢 Yes	🔴 No
Create a manual backup	🟢 Yes	🔴 No
Manage scheduled backups	🟢 Yes	🔴 No
Download backups	🟢 Yes	🔴 No
Restore backups	🟢 Yes	🔴 No
Restore a PITR	🟢 Yes	🔴 No
View connection details	🟢 Yes	🔴 No
View database logs	🟢 Yes	🔴 No
View database metrics	🟢 Yes	🔴 No
Manage Internet accessibility	🟢 Yes	🔴 No
Manage database configuration	🟢 Yes	🔴 No
Manage database users	🟢 Yes	🔴 No
Manage maintenance windows	🟢 Yes	🔴 No
Perform major upgrades	🟢 Yes	🔴 No
Perform minor upgrades	🟢 Yes	🔴 No

Scalingo JSON Manifest

Fri, 09 Oct 2026 00:00:00 +0000

The manifest is an optional file named scalingo.json you can add at the root of your repository to configure review apps and one-click deploy button. Its intent is to configure how an application should be created.

For Review Apps, configuration in scalingo.json takes precedence over configuration inherited from the parent application. The manifest is evaluated only when the review app is created. Changes to scalingo.json do not reconfigure existing review apps on subsequent deployments.

Configuration of the Environment

The scalingo.json manifest can be used to customize the environment of the application.

Review Apps

Variables described in the manifest are created when the review app is created, if one of those variables is present in the parent app environment, it will be replaced following the manifest rule.

One-Click Deployment

The manifest describes the default values of the environment variables, the user can still customize them before triggering the deployment.

Example

{
  "env": {
    "ENVIRONMENT": {
      "value": "staging"
    },
    "ADMIN_URL": {
      "generator": "url",
      "template": "%URL%/admin"
    },
    "SECRET_KEY": {
      "generator": "secret"
    }
  }
}

Monorepos

If your application code is in a subdirectory (configured using the PROJECT_DIR environment variable), Scalingo detects the JSON manifest under this subdirectory.

If there is no JSON manifest in the PROJECT_DIR folder, Scalingo tries to get the scalingo.json in every folder up to the root of your repository.

See our dedicated page on monorepos for more information about this type of setup.

Configuration of the Application Firewall

Review apps inherit the Application Firewall rules from their parent app by default. You can override the inherited rules in scalingo.json.

An explicit firewall_rules list replaces the parent’s rules; it is not merged with them. Omitting firewall_rules keeps the inherited rules.

If firewall_rules contains more rules than the application’s quota allows (20 by default), Review App creation fails.

Example

{
  "firewall_rules": [
    {
      "cidr": "203.0.113.42/32",
      "label": "office"
    },
    {
      "cidr": "192.0.2.0/24"
    }
  ]
}

Disabling the Application Firewall

To disable the firewall on a review app where the parent app have some firewall rules, pass an empty array.

In that case the child app will be created without any firewall rules and thus the firewall will be disabled for the child app.

{
  "firewall_rules": []
}

Configuration of Addons

Addons can also be declared in the JSON manifest and they’ll be provisioned before deploying a review app or starting a one-click deploy.

Review Apps

By default, addons are copied from the parent app. If you want to change the plan the review app will be using, or to avoid using some of them which only make sense in production, you can specify the list of addons in the manifest.

One-Click Deployments

Addons declared in the manifest will be provisioned before starting the deployment of the application.

Example

The options attribute is optional, currently only the version parameter is allowed in it.

{
  "addons": [
    {
      "plan": "postgresql:postgresql-starter-512",
      "options": {
        "version": "11"
      }
    }, {
      "plan": "redis:redis-starter-128"
    }
  ]
}

Deployment Hooks

The JSON manifest also lets you declare scripts which will be executed as postdeploy hook.

first-deploy: Executed after the first deployment of a review app or one-click app. It will be executed as many times as necessary until a first deployment is considered a “success” by the platform.
postdeploy [Deprecated]: Executed after each deployment of a review app except the first one if first-deploy is defined. This feature has been deprecated in favor of postdeploy script in the Procfile file.

Example

{
  "scripts": {
    "first-deploy": "bundle exec rake db:migrate db:seed",
    "postdeploy": "bundle exec rake db:migrate"
  }
}

Container Formation

The scalingo.json manifest can be used to setup a container formation. A container formation defines the shape of the containers that will be launched.

Review Apps

You can specify the shape and the number of containers to be launched when a Review App is created. This is useful for making an exact copy of a production environment in Review Apps without having to perform any manual actions.

One-Click Deployment

The manifest describes how applications deployed with our one-click button are deployed. This can be useful, for example, if you want to deploy a worker at the same time to handle asynchronous tasks.

Example

{
  "formation": {
    "web": {
      "amount": 2,
      "size": "L"
    },
    "worker": {
      "amount": 1,
      "size": "XL"
    }
  }
}

Reference Documentation

You can find the comprehensive documentation about the structure of the Scalingo JSON Manifest in our developers documentation

Custom Error and Maintenance Pages

Fri, 09 Oct 2026 00:00:00 +0000

Custom Error Pages

Our routers may return an error page when an application is unreachable. By default, the error page looks like the following:

You can customize these pages by providing Scalingo with a custom error page URL. Five different error pages can be customized. You need to set one of these environment variables depending on which error page you want to customize:

SCALINGO_NO_FRONT_ERROR_URL: if the application has no web container running but other types of containers are.
SCALINGO_STOPPED_PAGE_URL: if the application has no running container.
SCALINGO_APP_ERROR_URL: if the application returns a 502 HTTP response, crashed or cut the connection unexpectedly.
SCALINGO_TIMEOUT_ERROR_URL: if the application returns a 504 HTTP response or timed out.
SCALINGO_FORBIDDEN_PAGE_URL: if the request is denied by the application IP firewall.

To learn more about HTTP errors returned by our frontends, please see our documentation.

The usage is the following: SCALINGO_STOPPED_PAGE_URL=https://cdn.example.com/stopped_page.html.

In order to prevent the page to be fetched at each request, the content is cached in the router’s memory. Hence we limit the size of this page to 10MB.

It is mandatory to restart the application for the configuration of these pages to be taken into account.

Custom Maintenance Page

The SCALINGO_NO_FRONT_ERROR_URL environment can be used to display a specific page when an application is in maintenance. Here are the steps:

Set the SCALINGO_NO_FRONT_ERROR_URL environment variable to point to a valid URL containing the maintenance page.
Scale down the web containers to 0.
Execute all the operations needed for as long as you need. During this step, the maintenance page will be displayed for any request to the application.
Scale back up the web containers to the original value.

Review Apps

Fri, 09 Oct 2026 00:00:00 +0000

Review apps are a powerful collaboration tool to discuss about a new features between members of your organization. We implemented this feature as part of our SCM integration.

What Are Review Apps?

Let say that you have worked some hours on an awesome new feature. It’s time to show the world your work and to open a new Pull/Merge Request (PR) on the SCM tool (even if it’s not fully done). With review apps enabled on Scalingo, we will create a new application (called a review app) with the code of the new feature. You can now share the result of your work, to get it validated, with all people involved, even if they are not in the tech field.

Maybe they will tell you to change something like adding tests or to change a button color. You need to push your following modifications on the branch involved in the PR to update the review app.

Once all of our teammates are satisfied and the PR is closed, we will automatically delete the review app. You can disable this behavior or add a delay to fit your needs. This latter setting means that you can still review PR after your dev team has closed the PR.

The owner of the parent application is the only account which can manually delete the review app, via the Settings menu of the review app, submenu General, in the dashboard, or via our CLI.

If you don’t want to create a new review app for each PR you can also choose among open PRs of your app to manually deploy a review app.

It is also possible to manually create a review app using the Scalingo CLI:

scalingo --app my-app integration-link-manual-review-app 42
-----> Manual review app created for app 'my-app' with pull/merge request id '42'.

In this example, 42 is the pull request or merge request ID.

A manually created review app is instantly deleted after the pull request is closed.

Addons, Collaborators and Environment Variables

If you’ve enabled review apps, a new application will be created every time a new PR is opened in your linked SCM-hosted repository. This new application is a child application.

Child applications clone some information from the parent app:

the container formation
the stack
the environment variables
the databases and addons: including version and plans (can be overridden in scalingo.json), but excluding the content of the databases.
the collaborators
the routing settings: Force HTTPS, Sticky Sessions, and Application Firewall

This default behavior can be customized using a scalingo.json file, see: configuration of review apps.

It is however important to understand that the customization can allow to connect directly the Review App to the parent application database and addons, so Review Apps must be enabled only when trusted sources are allowed to create merge requests in the source code repositories. As a consequence, Scalingo prevents, by default, Review Apps from being created from forks of the original repository.

Accepting Review Apps deployments from forks

When your project also accepts pull requests from forked repositories, and you want to take advantage of the automatic deployment of the corresponding reviews apps, you can activate the automatic deployment of review apps from forks.

In the Dashboard, go to Review Apps configuration, and edit the setting for automatic deployment. Check “I want to allow review apps coming from forks”, then click on Update. As soon as the next pull request opened from a fork is received, a complete clone of your application will be automatically created!

When using the CLI, add the --allow-review-apps-from-forks flag to your integration-link configuration and accept the warning message.

$ scalingo --app my-app integration-link-update --deploy-review-apps --allow-review-apps-from-forks
  /!\  Only allow automatic review apps deployments from forks if you trust the owners of those forks, as this could lead to security issues. More info here: https://doc.scalingo.com/platform/app/review-apps#addons-collaborators-and-environment-variables

? Allow automatic creation of review apps from forks? Yes
-----> Your app 'my-app' integration link has been updated.

Configuration of Review Apps

Having a strict copy of the parent application is sometimes not desirable. You might not want to copy production credentials, or it is sometimes required to start a custom task after the initialization of the app. That’s where the Scalingo JSON manifest becomes useful.

If there are valid reasons and cases where configuring the scalingo.json is the adequate solution, it is important to understand that it is sometimes not the appropriate one. As Review Apps can connect to their parent database, and addons, this means personal, or health-related information can be exposed.

As a consequence, Scalingo recommends not to enable Review Apps for production applications. The preferred approach is to create a second application linked to the same repository. This second, separate application can then have Review Apps, while protecting production data.

As a quick example, here is a sample scalingo.json that customize the environment variable CANONICAL_HOST_URL for a child app:

{
  "env": {
    "CANONICAL_HOST_URL": {
      "generator": "url"
    }
  }
}

Here, the value of the environment variable CANONICAL_HOST_URL will contain the URL to reach the newly deployed app. The scalingo.json configuration always takes precedence over parent app configuration.

Protect a Review App with Basic Auth

You may want to protect access to your review apps so that authentication is mandatory before reaching the review app. A solution is to update the scalingo.json file to look like:

{
  "env": {
    "BASIC_AUTH": {
      "value": true
    }
  }
}

Then you can test the presence of this environment variable in your application and setup Basic Auth in case this environment is defined in the environment of the application.

You can also generate a different password for each review app by using the secret generator in the scalingo.json file:

{
  "env": {
    // ...
    "PASSWORD": {
      "description": "Basic auth password for review apps",
      "generator": "secret"
    }
  }
}

The environment variable PASSWORD should be used by your application to configure Basic Auth on your app.

Run a Task After the First Deployment of a Review App

When a review app is created, you might want to execute a custom action like seeding its database. This can be done using the first-deploy script in the scalingo.json manifest. If such a property is defined, the given command will be executed as a postdeploy hook after the first deployment.

{
  "scripts": {
    "first-deploy": "bundle exec rake db:deploy db:seed"
  }
}

Run a Task After Each Deployment of a Review App

To run a custom command after each deployment of a review app, you need to define a postdeploy hook for your application. However defining a postdeploy hook would also impact the parent application.

To make sure only review apps are impacted, the common practice is to define a custom environment variable in the scalingo.json manifest:

{
  "env": {
    "IS_REVIEW_APP": {
      "value": "true"
    }
  }
}

Then use the environment variable in your postdeploy task to check if it is executed in the scope of a review app or not.

Is It Possible to Create Review Apps If My Code Is Hosted at a Different Place?

We implement review apps for code hosted on GitHub or GitLab. However you can set it up for your specific case thanks to the Scalingo API:

Create a child application
Deploy a gzipped tar archive containing your code: https://developers.scalingo.com/deployments#trigger-manually-a-deployment-from-an-archive

Application Firewall

Fri, 09 Oct 2026 00:00:00 +0000

Application Firewall is a feature that, once configured, restricts public HTTP and HTTPS access to an application based on allowed IPv4 CIDR ranges. Scalingo’s routers check the source IP address before forwarding a request to the application’s web containers.

How the Firewall Works

Each firewall rule allows access from an IPv4 range. A request only needs to match one rule to be allowed.

Configuration	Request source IP	Result
No rules	Any IP	The firewall is disabled and does not restrict public access
One or more rules	Matches at least one allowed range	The firewall allows the request
One or more rules	Matches none of the allowed ranges	The router returns HTTP `403 Forbidden`

Adding the first rule restricts public access to the allowed ranges. Deleting the last rule restores access from any source IP once the change takes effect.

Traffic and Source IP

The same rules apply to the application’s default Scalingo domain and all its custom domains.

Only public HTTP and HTTPS traffic to web containers is filtered. Traffic exposed through the TCP addon is not filtered.

Traffic through Private Networks is unaffected. Requests using the application’s public route remain subject to firewall rules, even when they come from another Scalingo application.

The firewall checks the IP address that opens the TCP connection to the router. It does not use HTTP headers such as X-Forwarded-For to decide whether access is allowed. When requests pass through a proxy, allow the proxy’s outbound IP addresses.

Rule Format and Limits

Each rule has an ID, an IPv4 range in CIDR notation, and an optional label.
Use a range such as 203.0.113.0/24, or /32 for a single address, such as 203.0.113.42/32. Addresses without a CIDR suffix are not accepted.
Incoming IPv6 traffic is currently not supported.
Each application can have up to 20 rules by default. This limit can be changed by Scalingo support.

Managing Firewall Rules

Collaborators can view, add, and remove firewall rules. Limited Collaborators can only view them.

Rule additions and deletions appear in the application’s Activity, with the user who performed the action, regardless of the interface used.

You can manage rules through the Dashboard, the CLI, the API, or the Terraform Provider. To change a rule, remove it and add a new one. To disable the firewall, delete all its rules.

Using the Dashboard

Firewall enabled means at least one rule exists. Firewall disabled means no rules exist. This indicator does not report whether changes have propagated to the routers.

To add a rule:

From your web browser, open your dashboard
Click on the application for which you want to add a firewall rule
Click on the Settings tab
From the Settings sub-menu, select Public Routing
Locate the Firewall rules block
In the IP Range field, enter the IPv4 range to allow in CIDR notation, for example 203.0.113.42/32
Optionally, enter a label in the Label field, for example Office VPN
Click the Save button

To remove a rule from the same Firewall rules block:

Locate the rule you want to remove by its IP range or label
Use the delete action for that rule

Deleting the last rule disables the firewall and restores public access from any source IP once the change takes effect.

Using the CLI

List the current rules, including their IDs and labels:

scalingo --app my-app app-firewall-rules

Allow access from a single IPv4 address:

scalingo --app my-app app-firewall-rule-add --cidr 203.0.113.42/32 --label office

Remove a rule using its ID:

scalingo --app my-app app-firewall-rule-remove '<rule-id>'

Replace my-app with your application’s name and <rule-id> with the ID returned by app-firewall-rules.

Common Use Cases

Restricting Access to a VPN

Allow the VPN’s public outbound IPv4 addresses. Users must route their requests to the application through that VPN. To restrict public access to the VPN, allow only its outbound addresses: any other allowed range also grants access.

Allowing Cloudflare Traffic

To require public incoming requests to your application to pass through Cloudflare:

Add one rule for each Cloudflare proxy IPv4 range in your Application Firewall allowlist
Make sure to only allow these ranges, so that any other source is rejected
Keep the allowlist in sync with Cloudflare’s published IP ranges

Allowing Other Scalingo Applications

Applications in the same project can use private routing, which is unaffected by Application Firewall.

For connections through the public route, including from other projects, allow the egress IPv4 addresses of each source region.

Allowing Webhooks and External Monitoring

When a webhook provider or monitoring service calls your application over the Internet, its connection source IP must match an allowed range. Add the service’s outbound IPv4 ranges to keep receiving these requests after enabling the firewall.

Firewall Rules for Review Apps

Review Apps copy their parent’s firewall rules at creation. Later changes to the parent’s rules are not synchronized to existing Review Apps.

The firewall_rules setting in scalingo.json can replace the inherited rules or disable the firewall for a Review App. It is read only at creation; subsequent deployments do not update the rules from this setting.

See Application Firewall configuration in the manifest for the configuration and JSON examples.

Identifying Blocked Requests

Blocked requests receive an HTTP 403 Forbidden response with a standard Scalingo error page. They are not forwarded to an application container.

Enable router logs to see blocked requests in your application logs:

scalingo --app my-app router-logs --enable

A firewall rejection has both status=403 and container=false. For example, the relevant fields are:

container=false status=403

The container=false field indicates that no target container was selected. It distinguishes a firewall rejection from an HTTP 403 returned by your application; status=403 alone does not.

Customizing the Access Denied Page

Set the SCALINGO_FORBIDDEN_PAGE_URL environment variable to the URL of your custom error page. See Custom Error and Maintenance Pages for configuration requirements and restart instructions.

Overview

Fri, 09 Oct 2026 00:00:00 +0000

In a Platform as a Service environment such as Scalingo, public routing refers to the way hosted applications are exposed to the Internet through publicly accessible network paths.

It designates how the platform connects external (Internet) traffic to the right application running inside our managed infrastructure. This process is fully handled by Scalingo in an automatic, fast, and secure manner.

When an application is deployed on Scalingo, the following happens:

The platform runs your app on our internal infrastructure, in an isolated runtime environment.
It assigns your application a publicly reachable domain name, ending in .scalingo.io..
It updates our public routing layer to ensure incoming requests are forwarded to the appropriate application containers. It ensures the connection between the outside world and our internal runtime environment (where your application is running).
The public routing layer also handles TLS termination (HTTPS), load balancing, Application Firewall, rate-limiting, and automatic failover.

In short, public routing turns your isolated application instance into a publicly consumable service. Networking (DNS, requests forwarding), security (TLS termination), and scalability (rate-limiting, failover) concerns are all automatically handled by the platform.

Public routing is a core component of a PaaS. It brings a good part of the magic while sparing our customers a lot of networking annoyances. As such, it’s fully included into our offers.

Routing

Fri, 09 Oct 2026 00:00:00 +0000

Reverse Proxy

Our infrastructure involves a multitude of servers running our customer’s applications. These servers are not directly reachable from the wild outside world. Instead, they are hidden behind frontend servers called reverse proxies.

A reverse proxy designates a server that sits in front of web servers and forwards client (e.g. web browser) requests to those servers.

At Scalingo, our frontend reverse proxies have multiple responsibilities:

Filter out undesirable traffic.
Apply Application Firewall rules.
Apply some constraints on ingress traffic to protect the platform and ensure good performances.
Terminate HTTPS and HTTP/2 traffic.
Forward HTTP requests to applications’ web containers, which act, as the name implies, as web servers.

Key Benefits

Running these frontend reverse proxies provides a lot of key benefits:

They add a layer of security by hidding the internal structure of the platform and reducing the attack surface available for malicious users. From the outside world, our frontend reverse proxies are the only visible brick of our infrastructure.
They allow us to distribute ingress traffic across available servers hosting the applications’ containers. When a server becomes unavailable, the reverse proxies’ configuration are updated so they can re-route the traffic to the available ones.
When an application is running multiple web containers, this also allows us to forward the requests to one of these containers.
Since our frontend reverse proxies also act as TLS termination points, they allow us to easily provide TLS encryption and simplify the certificate management and renewals via Let’s Encrypt automation.
They allow us to provide router logs and request metrics.

Routing Specifics

Requests Distribution

When an HTTP request is sent to an app hosted on Scalingo, it’s first received and analyzed by our frontend proxies to retrieve the targeted domain name, using either the Host HTTP header for simple HTTP requests, or the Server Name Indication (SNI) of the TLS handshake for encrypted HTTPS requests.

Once the domain name is known, our routers use it to determine the location of the application’s web container(s) and forward the request to one of them. Selection is made by applying a strict round-robin scheduling across the available web containers of the application, ensuring even load balancing.

The request is processed by the application, and the answer is sent back to the client through the reverse proxy.

Quarantine

Our reverse proxies also include a quarantine mechanism to prevent requests from being sent to misbehaving containers. If one of your application’s web containers unexpectedly closes the connection, it is automatically placed in quarantine. From this point on, our frontends will stop routing requests to it and will instead periodically attempt to contact the container using exponential backoff. Once the container responds successfully, it is removed from quarantine and begins to receiving requests again.

Sticky Session

Our Sticky Sessions feature allows to slightly modify the default routing configuration by associating all incoming HTTP requests to a specific, single web container.

For more details about this feature, please read the dedicated documentation page.

Requests Queue

Each router of the infrastructure is keeping a local request queue for each application running on the platform. For each application, this queue is limited to 50 requests per web container. If the queue is full and a new request is received the router returns a 503 Service Unavailable HTTP error.

For instance, if your application is using 2 web containers, our reverse proxies accept to queue up to 100 requests, and then reject any additional requests.

When requests are being queued, it means the application is not able to cope with the amount of received requests. It often means the application is not well sized compared to the traffic the instances need to handle. The application should either have more web containers, or it should be optimized to respond to requests faster.

Timeouts

When a new connection has been established to a web container, the app is given an initial 30 seconds window to return a response. This response can be incomplete, the idea is to have some data transiting into the TCP socket so we know the web process is active.

After this first exchange, the window grows to 60 seconds. To maintain the connection active (for instance, while your app is processing a response), it has to send data back to the client at least once every 59 seconds.

When these timeouts are reached, our frontend reverse proxies return a 504 Gateway Timeout HTTP error.

WebSockets, Server-Sent Events and Long-Running Connections

WebSockets, Server-Sent Events (SSE) and long-running connections are fully supported and available by default.

Timeouts still apply, so please make sure your application keeps the connection alive when necessary.

Headers

Our frontend reverse proxies add or update a few headers to each request:

X-Real-IP: The originating IP address of the client connecting to Scalingo.
X-Forwarded-For: The originating IP address of the client connecting to Scalingo.
X-Forwarded-Proto: The originating protocol of the HTTP request. Either http or https.
X-Forwarded-Port: The originating port of the HTTP request. Either 80 or 443.
X-Request-ID: UUID identifying the request, set only if not already existing.
X-Request-Start: Unix timestamp (in milliseconds) when the request was received by the front server.
Example: t=1693406590.527.
X-Scalingo-Error: Detailed error message when an error occurred on the router.

Requests Compression

Our routers apply gzip compression to incoming requests that include the Accept-Encoding: gzip HTTP header, but only for a limited set of resource types identified by the following mimetypes:

application/atom+xml
application/javascript
application/json
application/rss+xml
application/x-javascript
application/xml
text/css
text/html
text/javascript
text/mathml
text/plain
text/xml

If you need a different compression algorithm, or support for additional file types, please let your application code handle it.

HTTP/2

HTTP/2 is enabled by default and always available.

If the client supports HTTP/2, and if it is reaching the application using HTTPS, the connection is automatically upgraded to HTTP/2 by our frontend reverse proxies.

The HTTP/2 connection terminates at the Scalingo frontend reverse proxies. We then forward the requests from the routers to the application’s containers through HTTP/1.1. Consequently, your application should not expect HTTP/2 traffic.

The performance benefits of HTTP/2 still apply, especially for slow clients (e.g. mobile, xDSL) as the protocol is designed to improve speed over slow connections. Behind the scene, multiplexed requests are handled in parallel using HTTP/1.1 when communicating with the containers. Since these containers operate within the same internal network, adopting HTTP/2 there would not provide any significant additional performance gains.

HTTP Errors

413 Payload Too Large

The request size exceeds the max allowed body size.
Was previously called Request Entity Too Large.

403 Forbidden

The request source IP address does not match the application’s app firewall.

499 Client Closed Request

The client closed the connection before the server answered the request. It is usually caused by client side timeout.

502 Bad Gateway

The application sent an invalid response to our reverse proxy. This error is often sent when your application is abruptly cutting connections.
All containers running the app are in quarantine.

You can distinguish between these two cases based on the context: if you notice multiple consecutive requests returning a 502 error, it probably means one of your application containers is in quarantine.

503 Service Unavailable

The application requests queue is full, so the newly incoming request has not been dequeued.
The application has been stopped by its owner.
The application has no web container responding to HTTP requests.

504 Gateway Timeout

The application timed out. Your application must accept connections and send the first byte in a limited amount of time.

Features

Fri, 09 Oct 2026 00:00:00 +0000

Create new apps

scalingo create

scalingo create my-app

# Create a new app with a custom Git remote
scalingo --remote staging create my-app
scalingo --remote production create my-app
scalingo --remote custom create my-app

Setup your account SSH keys

scalingo keys|keys-add|keys-remove

scalingo keys
scalingo keys-add "Laptop SSH key" $HOME/.ssh/id_ed25519.pub
scalingo keys-remove "Laptop SSH key"

Configure their environment

scalingo env|env-set|env-unset

scalingo --app my-app env
scalingo --app my-app env-set NODE_ENV=production
scalingo --app my-app env-unset NODE_ENV

Configure custom domain names

scalingo domains|domains-add|domains-ssl|domains-remove

scalingo --app my-app domains
scalingo --app my-app domains-add example.com
scalingo --app my-app domains-ssl example.com --cert file.crt --key file.key
scalingo --app my-app domains-remove example.com

Configure canonical domain name

scalingo set-canonical-domain|unset-canonical-domain

scalingo --app my-app set-canonical-domain example.com
scalingo --app my-app unset-canonical-domain

Configure router

scalingo sticky-session|force-https|router-logs

scalingo --app my-app sticky-session --enable
scalingo --app my-app sticky-session --disable
scalingo --app my-app force-https --enable
scalingo --app my-app force-https --disable
scalingo --app my-app router-logs --enable
scalingo --app my-app router-logs --disable

Manage application IP firewall rules

scalingo app-firewall-rules|app-firewall-rule-add|app-firewall-rule-remove

scalingo --app my-app app-firewall-rules
scalingo --app my-app app-firewall-rule-add --cidr 203.0.113.42/32 --label office
scalingo --app my-app app-firewall-rule-remove '<rule-id>'

Use app-firewall-rules to display the current rules, including their IDs and labels. Replace <rule-id> with the ID of the rule to remove. To change a rule, remove it and add a new one. See the Application IP Firewall documentation for availability, limits, and propagation delays.

Manage collaborators of the application

scalingo collaborators|collaborators-add|collaborators-remove

scalingo --app my-app collaborators
scalingo --app my-app collaborators-add user@example.com
scalingo --app my-app collaborators-remove user@example.com

List existing addons and plans

scalingo addons-list|addons-plans

scalingo addons-list
scalingo addons-plans mongodb

Manage addons of your applications

scalingo addons|addons-add|addons-remove|addons-upgrade

scalingo --app my-app addons
scalingo --app my-app addons-add mongodb 1g
scalingo --app my-app addons-remove my-app_12345
scalingo --app my-app addons-upgrade my-app_12345 2g

# Display logs for addon
scalingo --app my-app --addon addon-uuid logs

Download backups of your applications addons

scalingo backups|backups-download

# List backups
scalingo --app my-app --addon addon-uuid backups

# Download backup
scalingo --app my-app --addon addon-uuid backups-download --backup $BACKUP_ID

# Download last backup
scalingo --app my-app --addon addon-uuid backups-download

# Set output path
scalingo --app my-app --addon addon-uuid backups-download --output tmp

# Do not show the progress bar and loading messages
scalingo --app my-app --addon addon-uuid backups-download --silent

Read and watch the logs

scalingo logs

# Display the last 1000 lines of log
scalingo --app my-app logs -n 1000

# Display logs for addon
scalingo --app my-app --addon addon-uuid logs

# Follow the logs of your application in real-time
scalingo --app my-app logs -f

# Filter your logs by container type
scalingo --app my-app logs -F "web"
scalingo --app my-app logs --filter "worker"
scalingo --app my-app logs -F "web|worker"

List the logs archives

scalingo logs-archives

# Display the last 10 logs archives
scalingo --app my-app logs-archives

# Follow the 2nd page of logs archives (from 11 to 20)
scalingo --app my-app logs-archives --page 2

Run custom job

scalingo run

scalingo --app my-app run bundle exec rails console

# Define custom environment variables into the one-off container
scalingo --app my-app run --env CUSTOM_ENV=value --env ENV_EXAMPLE=custom <command>

# Upload a file to the one-off container (target is /tmp/uploads)
scalingo --app my-app run --file ./dump.sql <command>

# Start the one-off container with a specific size of container
scalingo --app my-app run --size 2XL <command>

# When using hyphens in the job command, you must use double quotation marks
scalingo --app my-app run "bundle exec rails console --sandbox"

Get metrics of your application

scalingo stats

# Get the current stats of the containers of your app
scalingo --app my-app stats

# Display and update every 10 seconds the stats of the containers of your app
scalingo --app my-app stats --stream

Access your database

scalingo mongo-console|redis-console|mysql-console|pgsql-console|db-tunnel

scalingo --app my-app mongo-console
scalingo --app my-app redis-console
scalingo --app my-app mysql-console
scalingo --app my-app pgsql-console

# Build an encrypted tunnel to access your database
scalingo --app my-app db-tunnel MONGO_URL

Manage containers, scale, send signal

scalingo ps|restart|scale|one-off-stop

scalingo --app my-app ps
scalingo --app my-app restart web-1
scalingo --app my-app scale web:2
scalingo --app my-app scale worker:2:L
scalingo --app my-app scale clock:0
scalingo --app my-app one-off-stop one-off-1234
scalingo --app my-app send-signal --signal SIGUSR1 web
scalingo --app my-app send-signal --signal SIGUSR2 web-1 web-2

Check the logged in user

scalingo self|whoami

# Return the logged in user with either command
scalingo self
scalingo whoami

New: Application Firewall

Fri, 09 Oct 2026 00:00:00 +0000

Application Firewall lets you restrict public HTTP and HTTPS access to your application to allowed IPv4 ranges, for example your VPN’s outbound addresses.

Requests from other addresses receive HTTP 403 Forbidden before reaching your application’s containers.

See the Application Firewall documentation to configure your rules.

jemalloc - jemalloc 5.4.0 is now available

Tue, 06 Oct 2026 12:00:00 +0000

jemalloc 5.4.0 is now available for scalingo-22, scalingo-24, and scalingo-26.

This is also the default version.

Changelog

Jemalloc Buildpack

Tue, 06 Oct 2026 00:00:00 +0000

Purpose of this buildpack

Jemalloc is a general purpose malloc implementation that works to avoid memory fragmentation in multithreaded applications. This buildpack makes it easy to install and use jemalloc with your apps.

Set up this buildpack for your application

This buildpack is designed to be used in conjunction with one or more additional buildpacks, thanks to the multi buildpack.

For instance, when creating a new Ruby app on Scalingo:

$ scalingo create my-app

$ cat << EOF > .buildpacks
https://github.com/Scalingo/jemalloc-buildpack
https://github.com/Scalingo/ruby-buildpack
EOF

The above commands configure your application to use the multi buildpack, and define the .buildpacks file. This file configures the different buildpacks to apply. In this example, we configure the jemalloc and the Ruby buildpack.

Configuration

Per Container Type

To control when jemalloc is configured on a per container basis, use jemalloc.sh <cmd> and ensure that JEMALLOC_ENABLED is unset.

Example Procfile:

web: jemalloc.sh bundle exec puma -C config/puma.rb

jemalloc Versions

Availability

The following jemalloc versions are available:

jemalloc Version	scalingo-22	scalingo-24	scalingo-26
`5.4`	Up to `5.4.0`	Up to `5.4.0`	Up to `5.4.0`

Select a Version

The default jemalloc version on all stacks is the latest 5.4 version. If you need to install another version, please use the JEMALLOC_VERSION environment variable, like so:

scalingo env-set JEMALLOC_VERSION=5.3.1

nginx - ModSecurity OWASP Core Rule Set 4.25.2 (LTS) is now available

Mon, 05 Oct 2026 12:00:00 +0000

nginx ModSecurity OWASP CRS 4.25.2 (LTS) is now available.

Changelog

OWASP ModSecurity 3.0.17 is available

Mon, 05 Oct 2026 12:00:00 +0000

OWASP ModSecurity 3.0.17 is now available for nginx.

It’s also the default version.

Changelog

Python - Python 3.11.17, 3.12.15, 3.13.16 and 3.14.8 are now available

Mon, 05 Oct 2026 12:00:00 +0000

Python 3.11.17, 3.12.15, 3.13.16 and 3.14.8 are now available.

These are also the new default version for, respectively, Python 3.11, 3.12, 3.13 and 3.14.

Changelogs:

Scalingo for PostgreSQL® Overview

Mon, 05 Oct 2026 00:00:00 +0000

PostgreSQL®

PostgreSQL® is a free, open-source, community-managed object-relational database management system focusing on SQL compliance and extensibility. It is well-known for its performances, reliability and robustness, making it a very powerful database, able to handle small to huge workloads.

Besides the core features (ACID transactions, views, triggers, foreign keys, …) PostgreSQL® also offers solutions for more specialized usages, such as object storage with the native jsonb format, for specific dataset kinds, such as geographic datasets with the PostGIS extension, for time-series datasets with TimescaleDB or for vector similarity search thanks to the pgvector extension.

Scalingo for PostgreSQL®

Scalingo for PostgreSQL® is our official PostgreSQL® addon. We have several plans available from which you can choose depending on your needs and budget. A free plan is available for you to test our offer.

To get a complete view of what is included in our service, see High availability, Features, Limitations, and the dedicated Extensions page.

Life-Cycle

The PostgreSQL® project releases new major versions annually, introducing new features and performance improvements. At Scalingo, we ensure compatibility with these major versions, typically making them available on our platform about one year after their initial release.

While the PostgreSQL® community supports a major version for up to five years after its initial release, Scalingo supports each major version on our platform for three years, providing minor upgrades that include critical bug fixes and security patches. After this period, we gradually deprecate oldest versions to ensure security, performance, and operational efficiency.

Available Versions

PostgreSQL Version	Full Version	EOL
`18`	up to `18.6.0-2`	Nov 2030
`17`	up to `17.11.0-1`	Nov 2029
`16`	up to `16.15.0-1`	Nov 2028
`15`	up to `15.19.0-1`	Nov 2027
`14`	up to `14.24.0-1`	Nov 2026

The default version when provisioning a Scalingo for PostgreSQL® addon is the latest 17 version.

Pricing

Our prices are details on our dedicated page.

Billing of your PostgreSQL® addon is done on a minute basis.

If your database disk usage exceeds the threshold set on your plan, the over-quota is billed per GB-hour (see our FAQ for further details).

Python

Mon, 05 Oct 2026 00:00:00 +0000

The Python language is officially supported on the platform.

Detection

To ensure our deployment system considers your application as a Python application, a file Pipfile, requirements.txt, poetry.lock or uv.lock should be present at the root of your project, defining the dependencies of your app.

Python Versions

Availability

The following versions of Python are available:

Python Version	scalingo-22	scalingo-24	scalingo-26
`3.14`	up to `3.14.8`	up to `3.14.8`	up to `3.14.8`
`3.13`	up to `3.13.16`	up to `3.13.16`	up to `3.13.16`
`3.12`	up to `3.12.15`	up to `3.12.15`	up to `3.12.15`
`3.11`	up to `3.11.17`	up to `3.11.17`	up to `3.11.17`

Selecting a Version

The default Python version on all stacks is the latest 3.13 version. You can, however, instruct the platform to use another version.

The buildpack looks for a Python version in the following places (in descending order of precedence):

The runtime.txt file (deprecated)
The .python-version file (recommended)
The python_full_version field in the Pipfile.lock file (Pipenv users only)
The python_version field in the Pipfile.lock file (Pipenv users only)

To instruct the platform to use a specific Python runtime, add a .python-version file to your app’s root directory and declare the Python version number to use in it.

This version can be either:

The major Python version such as 3.12 (recommended)
The full Python version such as 3.12.7

Dependencies

Recommended: pipenv

When the project is using pipenv and contains a Pipfile and a Pipfile.lock files, the following command is used to install dependencies:

pipenv install

Legacy: requirements.txt

If a requirements.txt file is present in your application, the dependencies will be installed respecting this file with:

pip install -r requirements.txt

Alternative: Poetry

If your project uses poetry and contains a poetry.lock file, the following command is used to install dependencies:

poetry sync --compile

Frameworks

We handle most of the common frameworks. Obviously, Django is among them. You need to configure your application to bind the port defined by the environment variable $PORT.

Getting Started with Django

Specific Python Buildpack Hooks

You may want to trigger custom actions after a successful deployment. The postdeploy hook is exactly what you need. But your application may require some actions to be executed during the deployment.

The Python buildpack can execute two hooks: before and after the installation of Python and its dependencies. They must be located in the bin root folder of your application and be named pre_compile and post_compile.

Buildpack

More information at https://github.com/Scalingo/python-buildpack.

WEB_CONCURRENCY

The default level of concurrency is automatically defined, depending on the amount of memory available in the container running the app:

Container Size	Memory (MB)	Default Concurrency
S	256	1
M	512	2
L	1024	4
XL	2048	8
2XL	4096	16
3XL	8192	32

For further details about this calculation, please see the WEB_CONCURRENCY.sh script of the Python buildpack.

To override the automatically defined value, set the WEB_CONCURRENCY environment variable to the desired value.

PostgreSQL - New Version: 18.6.0-2

Mon, 05 Oct 2026 00:00:00 +0000

New Image

scalingo/postgresql:18.6.0-2
- TimescaleDB v2.30.1
- pgvector v0.8.6
- PostGIS v3.6.4
- PostgreSQL Anonymizer v3.1.3

Docker image on Docker Hub

Default version remains: 17.11.0-1

Free Trial

Thu, 01 Oct 2026 00:00:00 +0000

Free trial

When you create an account, Scalingo offers eligible accounts a 30-day free trial to test the platform.

To use your free trial, you must configure your billing profile and add a valid payment method. You are not charged while the free trial is active.

What can I do under the free trial?

You can have a maximum of 1 application using a maximum of 5 containers (S or M size).

Review apps are considered as applications, so you can’t create one while in free trial.

Your test application can also use managed databases during the free trial. For each of the eligible database engines listed below, you can provision 1 database instance on its smallest plan:

You would like to test another engine or another plan? Contact us on the chat.

How to leave the free trial early?

You may want to leave the free trial period earlier to start using the platform to its full potential. To do so, open the web dashboard and click the Stop free trial button. Your billing starts and the free trial limits are removed.

What happens at the end of the free trial?

3 days and 1 day before the end of the free trial, you will receive an email to notify you of the remaining days under the free trial.

At the end of the free trial, the resources you created keep running and your billing starts automatically with the payment method configured on your account.