Documentation Center

Node.js

Fri, 26 Jun 2026 12:00:00 +0000

Node.js is supported by Scalingo, furthermore, custom support has been added to manage the Meteor framework.

Detection

The file package.json should be present at the root of the project.

Node.js Versions

Availability

The following Node.js versions are available:

Node.js version	`scalingo-22` (EOL)	`scalingo-24`	`scalingo-26`
`v26`	up to `26.4.0`	up to `26.4.0`	up to `26.4.0`
`v24` (LTS)	up to `24.18.0`	up to `24.18.0`	up to `24.18.0`
`v22` (LTS)	up to `22.23.1`	up to `22.23.1`	up to `22.23.1`

Select a Version

The default Node.js version on all stacks is the latest v24 version. If you need to install another version, specify it in the engines.node key of your package.json file.
For example, to install the latest Node.js version of the v24 branch:

{
  "name": "my-app",
  "engines": {
    "node": "24"
  }
}

Dependencies Installation

The dependencies of your project are installed either with the npm package manager or the Yarn package manager.

If a yarn.lock file is present at the root of your project, yarn will be used to install the dependencies and run scripts, otherwise npm will build the dependencies during the deployment.

If a package-lock.json file is present at the root of your project and you are using npm version 6 or higher, Scalingo will use npm ci (for clean-install) to install your dependencies. Otherwise Scalingo will fallback to npm install.

Private Dependency

NPM Private Modules

First you need to create a read-only token with the NPM account you want to authenticate:

npm token create --read-only

Then set this token as environment variable (replace the 0-value by the token obtained in the previous command):

scalingo env-set NPM_TOKEN=00000000-0000-0000-0000-00000000

Add the following NPM configuration file .npmrc to the root directory of your project:

//registry.npmjs.org/:_authToken=${NPM_TOKEN}

Add this file and commit it in your Git repository, the environment variable will be automatically used during the build.

Configuring NPM

Sometimes a project needs custom npm behavior to set up proxies, use a different registry, etc. For such behavior, simply include an .npmrc file in the root of your project.

# .npmrc
registry = 'https://custom-registry.com/'

npm will also read the configuration from any environment variable starting with NPM_CONFIG.

Private Modules from SCM (GitHub/GitLab/etc.)

Your private module should be fetched from the SCM service through SSH. You can specify it this way:

"package-name": "git+ssh://git@<SCMhostname>/<workspace>/<repo>.git#master"

To authenticate to the SCM service, you need to use our SSH Private Key Buildpack, this buildpack will let you setup a private SSH key securely in the build environment.

devDependencies Installation

By default, dependencies present in the devDependencies field are installed. At the end of the deployment, devDependencies are pruned. Hence only production dependencies are left in the image used for the runtime.

devDependencies can be totally ignored and not installed at all by setting NPM_CONFIG_PRODUCTION=true npm or YARN_PRODUCTION=true with Yarn 1.

Skip Pruning

If you need access to packages declared under devDependencies at runtime, you may consider declaring those as dependencies. If required at runtime, they are not really development dependencies.

If you still need access to packages declared under devDependencies after the build has finished without moving those in dependencies - to be used in a different buildpack for example - then you’ll need to use Yarn 2+ and set YARN2_SKIP_PRUNING=true.

Package Manager	Environment Variable	Install Dev Deps	Prune
npm	none	Yes	Yes
npm	`NPM_CONFIG_PRODUCTION`	No	-
Yarn	none	Yes	Yes
Yarn	`YARN_PRODUCTION`	No	-
Yarn 2+	none	Yes	Yes
Yarn 2+	`YARN2_SKIP_PRUNING`	Yes	No

Ensure you’re Tracking all your Dependencies

It is important to ensure you are tracking all the dependencies of your project in the package.json file. Otherwise your app may build but will potentially crash during its runtime, failing to find a dependency.

A common mistake is to run npm install without the --save flag. In this case the dependency is installed in the node_modules directory, but nothing is tracked in the package.json file.

You should also avoid to install global packages (i.e. using the -g flag). In this case packages are installed at the system level and are not tracked for your project.

In a nutshell: you should always use the following command when adding a dependency:

npm install --save <module>

Do not Track Modules with Git

When working locally on your code, after running npm install, a directory node_modules containing the dependencies of your application is created. You should not check this directory in your Git repository. If the dependency is listed in your package.json file, it will automatically be installed during the deployment of your application.

Adding these files to Git will create confusion and unnecessary noise in your code history and we consider it’s a good practice to keep it clean, only add the useful code (the code of your project). Moreover there is an issue with dependencies which build binaries during their installation. If you add these binaries to your repository, it may create incompatibility with Scalingo runtime environment.

The good method to avoid checking in these files is to add the following content in a .gitignore file at the root of your project and commit this file:

node_modules
bower_components
# Any other file created by grunt/gulp/webpack builds

Once done, Git will ignore these directories when making commits.

Node.js App Startup

What we use in order of priority

Procfile at the root of your project
The field .scripts.start defined in your package.json

Example of package.json:

{
  ...
  "scripts": {
    "start": "node server.js"
  }
}

Memory Management

On Scalingo, the Node.js buildpack automatically defines WEB_CONCURRENCY when it is not already set. The value is calculated from the memory available in the container and the WEB_MEMORY value:

WEB_CONCURRENCY = MEMORY_AVAILABLE / WEB_MEMORY

By default, WEB_MEMORY is set to 512 MB.

You can override WEB_CONCURRENCY or WEB_MEMORY if the default values do not fit your application workload.

If your application needs an explicit V8 old-space limit, use NODE_OPTIONS:

$ scalingo --app my-app env-set NODE_OPTIONS="--max-old-space-size=512"

The value is expressed in megabytes. This setting can help make memory usage more predictable, but increasing it does not fix memory leaks.

For more details, refer to the official Node.js memory guide.

Node.js Build Hooks

If your application has a build step that you would like to run when you deploy, you can use the build step defined in the package.json:

{
  ...
  "scripts": {
    "start": "node server.js",
    "build": "grunt build"
  }
}

If the package.json has a build script which needs to be customized for Scalingo, you should define ascalingo-postbuild step:

{
  ...
  "scripts": {
    "build": "grunt build",
    "scalingo-postbuild": "grunt build --prod",
    "start": "node server.js"
  }
}

You may also want to run a custom command before the installation of dependencies. This is possible thanks to commands named scalingo-prebuild:

{
  ...
  "scripts": {
    "scalingo-prebuild": "node prebuild.js",
    "start": "node server.js"
  }
}

Custom Cache Folder

By default, Scalingo stores the directories bower_components and node_modules at the root of the project in the deployment cache. But you might need to add different folders to this cache. You can override these defaults by specifying the cacheDirectories (or cache_directories) key at the root of your package.json file.

For example, if your application has a client and a server in the same repository, you can specify these folders to store them in the deployment cache with:

"cacheDirectories": ["client/node_modules", "server/node_modules"]

Meteor Application

If a .meteor file is detected at the root of your project, your app will be considered as a Meteor application.

See the Meteor applications documentation

Framework Requiring to Serve Static Files

Some front-end JavaScript frameworks (such as React Native, Ember.js, Ionic, Next.js, GatsbyJS) build static files and need a minimal web server to serve them. In order to do so, first update your package.json to at least specify the following scripts:

{
  // …
  "scripts": {
    "build": "<build script>",
    "start": "node server.js"
  },
  // …
}

The build script depends on the framework you use:

Ember.js: ember build --environment=production
GatsbyJS: gatsby build
Ionic: ionic-app-scripts build
Next.js: next build

The server.js file is a minimal web server such as the one presented here to serve the file generated during the build phase.

Buildpack

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

Next.js

Out of the box, Next.js is configured with a package.json which looks like:

{
  "name": "my-app",
  "version": "0.1.0",
  "private": true,
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start"
  },
  "dependencies": {
    "next": "^10.0.4",
    "react": "^17.0.1",
    "react-dom": "^17.0.1"
  }
}

To make it work on Scalingo, you need to provide the port. Otherwise, you would get a timeout error.

....
 Waiting for your application to boot...
 !   Error deploying the application
 !   → Timeout: my-app took more than 60 seconds to boot
....

To fix this issue, modify the start script by adding -p $PORT

{
  "name": "my-app",
  "version": "0.1.0",
  "private": true,
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start -p $PORT"
  },
  "dependencies": {
    "next": "^10.0.4",
    "react": "^17.0.1",
    "react-dom": "^17.0.1"
  }
}

Standalone Mode

The Next.js built image can be quite large, easily exceeding 500MB. If you encounter issues with the image size, you can try “standalone” mode.

More information here: Next.js in standalone mode.

Vite

In package.json, you need

  "scripts": {
    "start": "vite --port $PORT",
    // others scripts
    }
  }

In the vite.config (or vite.config.ts) file you need to add the following

  server: {
    host: "0.0.0.0",
  },

As a note, vite --port $PORT may compile components, depending on your configuration. If it does, it leads to a very long first HTTP request that may even crash your container. In this case, in the package.json, replace the start rule content to use node server.js (see section Framework Requiring to Serve Static Files) or vite preview --port $PORT.

Angular

Please refer to the Angular dedicated page for instructions on how to deploy such an application on Scalingo.

Yarn Known Issues

Catch `SIGTERM` In an Application Started With Yarn

You may want to catch the SIGTERM signal in your Node.js application:

process.on('SIGTERM', () => {
  log.notice('"SIGTERM" received');
  process.exit(0)
});

The good practice is to start the application by defining a start script in the package.json. For example:

{
  "scripts": {
    "start": "node server.js"
  }
}

Then define the web process in the Procfile. Example of Procfile content:

web: yarn run start

The problem with this approach is that Scalingo sends a SIGTERM signal to stop the application. But Yarn do not correctly forward this signal to the started process.

The solution is to change the content of the Procfile to directly start the Node.js process:

web: node server.js

Grafana - Grafana 13.1.0 is now available

Fri, 26 Jun 2026 12:00:00 +0000

Grafana 13.1.0 is now available.

It is also the new default version.

Changelog

Node.js - Node.js 22.23.1, 24.18.0, and 26.4.0 are now available

Fri, 26 Jun 2026 12:00:00 +0000

Node.js 22.23.1, 24.18.0, and 26.4.0 are now available.

[Changelogs]

Grafana - Grafana 13.0.3 is now available

Thu, 25 Jun 2026 12:00:00 +0000

Grafana 13.0.3 is now available.

It is also the new default version.

Changelog

nginx: nginx 1.30.3 (stable) is now available

Mon, 22 Jun 2026 12:00:00 +0000

nginx 1.30.3 (stable) is now available.

This is also the default version deployed on all stacks when using the nginx-buildpack.

Changelog

nginx: nginx 1.31.2 (mainline) is now available

Mon, 22 Jun 2026 12:00:00 +0000

nginx 1.31.2 (mainline) is now available.

Changelog

Node.js - Node.js 22.23.0, 24.17.0, and 26.3.1 are now available

Mon, 22 Jun 2026 12:00:00 +0000

Node.js 22.23.0, 24.17.0, and 26.3.1 are now available.

[Changelogs]

Prometheus - Prometheus 3.5.4 (LTS) is now available

Mon, 22 Jun 2026 12:00:00 +0000

Prometheus 3.5.4 (LTS) is now available.

Changelog

Stack scalingo-26 is the Default Stack

Mon, 22 Jun 2026 11:00:00 +0000

The stack scalingo-26 is now the default stack for all newly created application. It follows the announcement of scalingo-26 release in this blog post.

PostgreSQL® Dedicated Resources - Outscale Net Peering Support

Mon, 22 Jun 2026 00:00:00 +0000

Scalingo for PostgreSQL® Dedicated Resources databases can now be reached through Outscale Net Peering.

Each database now exposes a second endpoint dedicated to Net Peering traffic, alongside the existing public endpoint used for Internet-routed traffic.

This new access path lets you connect workloads running in an Outscale VPC to a Dedicated Resources database over Outscale Net Peering, without using the public Internet route.

Learn more in the Dedicated Resources access guide.

Accessing Your Scalingo for PostgreSQL® Dedicated Resources Database

Fri, 19 Jun 2026 00:00:00 +0000

By default the deployed database is completely private and is not reachable by any entity. Access configuration should be configured to allow database clients to reach it. Either it is an application using the database, or a database administration tool like a console or a web client.

Allowing Access with Firewall Rules

Dedicated Resources databases are protected by a deny-by-default firewall. To allow inbound connections, you must add explicit firewall rules for each trusted source.

Using the Database Dashboard

From your web browser, open your database dashboard
Select the Settings tab
In the Settings submenu, select Internet Access
In the Firewall rules block, click New rule
Select the rule type:
- Custom CIDR IPv4 to allow specific public IP addresses or ranges
- Scalingo <region> region to allow traffic from Scalingo apps in that region
Repeat as needed for each trusted source
Connect using the database connection URI

Using the Command Line (Preview)

Because Dedicated Resources databases are not yet generally available, you must first enable preview features to use the related CLI commands:

export SCALINGO_PREVIEW_FEATURES=true

Then:

# List the existing rules
scalingo --database <db-id> database-firewall-rules

# Add a new rule to the database based on a CIDR or a managed range
scalingo --database <db-id> database-firewall-rules-add --cidr "198.51.100.25/32" --label "My workstation"
scalingo --database <db-id> database-firewall-rules-add --managed-range mr-scalingo-osc-fr1

# Remove an existing rule to restrict access
scalingo --database <db-id> database-firewall-rules-remove <rule-id>

# List existing managed ranges which are maintained by Scalingo
scalingo --database <db-id> database-firewall-managed-ranges

How the Firewall Works

The firewall follows an allowlist model: you define allowed source networks with CIDR notation (single IPs or ranges), and only matching sources can reach the database endpoint.

You can configure up to 30 firewall rules per database, and rule changes usually propagate in around 2 minutes.

Here are common CIDR formats you can use in firewall rules:

Single IP: 203.0.113.10/32 (/32 means one exact IPv4 address)
IP range: 203.0.113.0/24 (/24 means a subnet of 256 IPv4 addresses)
Allow all (not recommended): 0.0.0.0/0 (/0 means all IPv4 addresses; this effectively disables firewall filtering)

Allowing Scalingo Apps To Reach a Dedicated Resources Database

If a Scalingo app must connect to a Dedicated Resources database, you need to allow inbound connections from the app region’s egress IP addresses.

To keep the service simple and maintenance-free, Scalingo provides a managed rule type that automatically allowlists egress IPs for a region.

Two managed rules are available:

Scalingo osc-fr1 region
Scalingo osc-secnum-fr1 region

Workflow:

Identify the app region (for example osc-fr1 or osc-secnum-fr1).
Add the matching managed rule in the Dedicated Resources firewall.
Add custom CIDR rules only for additional non-Scalingo sources (office IPs, VPN, etc.).

A database in osc-fr1 can accept traffic from an app in osc-secnum-fr1 (and the other way around) as long as the corresponding managed rule is present.

Creating an Outscale Net Peering

You can create an Outscale Net Peering between the Dedicated VPC of your database and an Outscale VPC from another Outscale account in the same region.

This feature is currently available from the Scalingo CLI only and requires preview features to be enabled.

Enable preview features in your shell:
```
export SCALINGO_PREVIEW_FEATURES=true
```

Fetch the database network configuration:

scalingo --database <db-id> database-network-configuration

From the fetched information, create the Outscale Net Peering from your Outscale account and copy the generated ID, for example pcx-123456789.

scalingo --database <db-id> database-net-peerings-add --outscale-net-peering-id pcx-123456789

Configure your Outscale VPC to route traffic to the database IP range. Update both the Security Group and the Route Table rules.
Get your private peering endpoint address to build your connection chain through the Net Peering.

Using Third Party Tools

While using psql to query and administer a PostgreSQL® database is probably the ubiquitous choice for a lot of users, it’s not limited to that. The PostgreSQL® ecosystem indeed offers a very large panel of tools made and provided by third-parties. For example, some might feel more intuitive because of their Graphical User Interface. Some are better integrated with others tools, when some others are more data-visualization centric.

By default, and for security reasons, your PostgreSQL® database is protected by a deny-by-default firewall.

Before using any third-party tool, configure the required firewall rules to allow connections from your trusted sources.

Once your firewall rule is active, you should be able to connect to your database with your tool of choice. If you don’t have one yet, we suggest you to take a look at pgAdmin.

Using pgAdmin

pgAdmin is probably the most popular and feature rich administration and development platform for PostgreSQL®. It’s open-source, it supports many platforms and comes with a Graphical User Interface, making it a reference tool for PostgreSQL®.

You can use your own pgAdmin, deployed on Scalingo or on another infrastructure as long as the firewall rules are correctly configured.

Connecting Your Scalingo for PostgreSQL® Dedicated Resources Database

Fri, 19 Jun 2026 00:00:00 +0000

Each Scalingo for PostgreSQL® Dedicated Resources database has its own connection URI, containing all information needed to connect to it.

Understanding the Connection URI

The connection URI is made of several components separated one from each other by a delimiter. For example, the @ character is used to mark the end of the userinfo (credentials) component of the URI.

In the case of PostgreSQL®, the connection URI provided by Scalingo is always formed as follows:

postgresql://[user]:[password]@[hostname]:[port]/[dbname]?sslmode=require

For more information about the connection URI syntax, please see RFC 3986 which defines the URI Generic Syntax.

Getting the Connection URI

Scalingo exposes a connection URI you can use to connect to your Dedicated Resources database with its default protected user.

Depending on the client or driver you use, you can either use this URI as-is or split it into separate values (host, port, database, user, password, TLS settings) to match the expected format.

If you connect with another database user you created, keep the same endpoint and database name, and replace the credentials with this user’s credentials.

Using the Dashboard

From your web browser, open your dashboard
Locate the Connect section then copy its Connection String

Using the Command Line

Make sure you have correctly setup the Scalingo command line tool
From the command line, list your databases:
```
scalingo databases
```
Locate the ID of the database you would like to connect to

From the command line, get the connection URI value:

scalingo --database <database_ID> env-get SCALINGO_POSTGRESQL_URL

The output is:

postgresql://my_dedicate_wxyz:YANs3y07m5_KJC2MSDGebh8tx1lliFWh2Yb239zVqGQvbElWDjIN7QWspVH92Ul8@my-dedicate-wxyz.postgresql.a.osc-fr1.scalingo-dbs.com:31000/my_dedicate_wxyz?sslmode=require

Building the Connection URI from a Specific Endpoint

Dedicated Resources databases expose multiple endpoints. You can choose which one to use depending on the network path you want for your connection. The database Dashboard, the environment variables generated by Scalingo, and env-get SCALINGO_POSTGRESQL_URL expose the default Public RW endpoint.

To use the Private Peering RW endpoint, for example through Outscale Net Peering, replace the hostname and port in the connection URI with the hostname and port of this endpoint.

All endpoints accept the default database credentials or the credentials of a custom user.

TLS Connections Are Enforced

By default, all PostgreSQL® Dedicated Resources databases enforce TLS. Any non-TLS connection is denied. Consequently, your application must be configured to use TLS when connecting to the database.

Connecting Multiple Applications to the Same Database

To share a database across multiple Scalingo applications, first make sure the Dedicated Resources firewall allows traffic from the application’s region (see Allowing Scalingo Apps to Reach a Dedicated Resources Database). Then add the database connection string as an environment variable in each application that needs access.

Copy the connection URI of your database instance
Create a new environment variable for the application that needs to access the database
Set the value of this new environment variable to connection URI you just copied
Restart the application to make the new environment variable available

Understanding Database Endpoints

Fri, 19 Jun 2026 00:00:00 +0000

Database endpoints are the different ways to access the database through the network.

Listing Database Endpoints with CLI

Because Dedicated Resources databases are not yet generally available, you must first enable preview features to use the related CLI commands:

export SCALINGO_PREVIEW_FEATURES=true

Run the following command to list your database endpoints:

scalingo --database <db-id> database-endpoints
┌──────────────────────────┬────────────────────┬───────────────────────────────────────────────────────┬───────┐
│            ID            │        TYPE        │                       HOSTNAME                        │ PORT  │
├──────────────────────────┼────────────────────┼───────────────────────────────────────────────────────┼───────┤
│ 6a316183d0f1f10ecbcca123 │ public-rw          │ mydb-1234.postgresql.osc-fr1.scalingo-dbs.com         │ 30092 │
│ 6a316183d0f1f10ecbcca456 │ private-peering-rw │ mydb-1234.peering.postgresql.osc-fr1.scalingo-dbs.com │ 30092 │
└──────────────────────────┴────────────────────┴───────────────────────────────────────────────────────┴───────┘

Types of Database Endpoints

Public RW

Public RW (public-rw) stands for public read/write. Its hostname resolves to the public IP configured for the database. It will always route requests to the servers able to receive read and write operations on the database.

This is the default endpoint exposed through the database Dashboard, the environment variables generated by Scalingo, and env-get SCALINGO_POSTGRESQL_URL.

In case of a cluster failover (maintenance/incident), the gateway instance targeted by the endpoint will change transparently, the IP resolved by the hostname will not change.

Private Peering RW

Private Peering RW (private-peering-rw) stands for private peering read/write. Its hostname resolves to the private IP address on the database gateway instance which is considerd as primary at a given time.

This hostname:port couple will only be reachable from networks linked with a Net Peering to the database.

In case of a cluster failover (maintenance/incident), the hostname DNS resolution will be automatically updated to resolve on an available gateway instance.

Build a Connection String from an endpoint

When configuring an application, choose the endpoint matching the network path you want to use to reach your database.

For example, use the public endpoint to connect through the public Internet, or the Private Peering endpoint to connect through Net Peering.

Provisioning a Scalingo for PostgreSQL® Dedicated Resources Database

Thu, 18 Jun 2026 12:00:00 +0000

Once you have chosen the right plan for your needs, you are ready to provision the database. This can be done via our dashboard, our CLI tool, our Terraform Provider, or via our Kubernetes Operator.

Provisioning

Using the Dashboard

From your web browser, open your dashboard
Select the Project where you want to create the database
Click the arrow next to Create an application, then click Database Dedicated Resources
In the Databases engines section, select PostgreSQL Dedicated Resources and confirm your choice
Enter a database name, then select or confirm the appropriate Project and Region
Select the plan you want to provision and confirm your selection
Click the Create database button
Database provisioning typically takes 15–30 minutes

Using the Command Line (Preview)

Because Dedicated Resources databases are not yet generally available, you must first enable preview features to use the related CLI commands:

export SCALINGO_PREVIEW_FEATURES=true

Make sure you have correctly setup the Scalingo command line tool

From the command line, list the plans available for postgresql-ng:

scalingo database-list-plans postgresql-ng

The output should look like this:

┌─────────────────────────────────┬─────────────────┐
│               ID                │      NAME       │
├─────────────────────────────────┼─────────────────┤
│ postgresql-dr-starter-4096      │ Starter 4G      │
│ postgresql-dr-starter-8192      │ Starter 8G      │
│ postgresql-dr-starter-16384     │ Starter 16G     │
...

Locate the ID corresponding to the plan you want to deploy (for example postgresql-dr-starter-4096)

Provision the database:

scalingo database-create --type postgresql-ng --plan <plan_ID> <database_name>

The output should look like this:

-----> Your postgresql-ng database 698e082f968c27dfb8a27521 ('my-dedicated-database') is being provisioned…

Database provisioning typically takes 15–30 minutes

Optionally you can use --wait in order to make the command synchronous.

scalingo database-create --type postgresql-ng --plan <plan_ID> --wait <database_name>

Using the Terraform Provider

Place the following resource block in your Terraform file to create the database and attach it to your app:
```
resource "scalingo_database" "my-dedicated-database" {
  name       = "my-dedicated-database"
  technology = "postgresql-ng"
  plan       = "postgresql-dr-starter-4096"
}
```
In this example, we create a dedicated PostgreSQL Starter 4096 database named my-dedicated-database. We could have done the same with another plan.
Run terraform plan and check if the result looks good
If so, run terraform apply
Database provisioning typically takes 15–30 minutes

Using the Kubernetes Operator

Deploy the Scalingo Kubernetes Operator in your cluster using the installation manifest install.yaml from the latest release.
Create a Scalingo API token and store it in a Kubernetes Secret, as documented in Create Secret.

Create a custom resource to provision your dedicated PostgreSQL database:

apiVersion: databases.scalingo.com/v1alpha1
kind: PostgreSQL
metadata:
  labels:
    app.kubernetes.io/name: scalingo-operator
    app.kubernetes.io/managed-by: kustomize
  name: my-dedicated-database
spec:
  # Secret read by operator
  authSecret:
    name: scalingo
    key: api_token

  # Secret written by operator
  connInfoSecretTarget:
    name: my-dedicated-database-secret
    prefix: PG

  # Network configuration
  networking:
    internet_access:
      enabled: true
    outscale:
      oks:
        net_peering: false
    firewall:
      rules:
        - type: "custom_range"
          cidr: "198.51.100.25/32"
          label: "My workstation"

  name: my-dedicated-database
  plan: postgresql-dr-starter-4096
  region: osc-fr1

This example provisions a dedicated PostgreSQL database named my-dedicated-database on the postgresql-dr-starter-4096 plan and writes its connection information to the my-dedicated-database-secret Kubernetes Secret. You can use another postgresql-dr-* plan instead.

Apply the resource and wait for provisioning to complete:
```
kubectl apply -f my-dedicated-database.yaml
```
Database provisioning typically takes 15–30 minutes

To read the database URL from the generated secret:

kubectl describe secret my-dedicated-database-secret
kubectl get secret my-dedicated-database-secret -o jsonpath='{.data}' | grep PG

For a complete manifest (including all available fields), use the official PostgreSQL sample resource.

Accessing the Scalingo for PostgreSQL® Dashboard

Every PostgreSQL® database comes with its dedicated dashboard, generally referred to as database dashboard, which is the central place for administrative tasks such as:

Monitoring the database through logs, metrics and statistics
Upgrading the database engine version
Enabling specific features
Managing database users
Managing Collaborators
Managing backups

You can access the database dashboard from the main dashboard:

From your web browser, open your dashboard
Open the Project containing the database you want to manage
In the Databases section, click the database name

Managing Users of Your Scalingo for PostgreSQL® Dedicated Resources Database

Thu, 18 Jun 2026 12:00:00 +0000

Each Scalingo for PostgreSQL® Dedicated Resources Database instances comes with a default database user. You can create as many additional users as needed, grant them with the appropriate permissions, update/reset their password, and delete them once they are not required anymore.

Listing Existing Users

Understanding Protected User

When provisioning a new Scalingo for PostgreSQL® Dedicated Resources Database instance, the platform creates a default user with a random name and password. It also grants this default user read and write permissions on the database, using the following queries:

GRANT CREATE ON SCHEMA public TO <username>
GRANT ALL PRIVILEGES ON DATABASE <database> TO <username>
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO <username>
GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO <username>
ALTER DEFAULT PRIVILEGES FOR USER <database> IN SCHEMA public GRANT ALL ON TABLES TO <username>
ALTER DEFAULT PRIVILEGES FOR USER <database> IN SCHEMA public GRANT ALL ON SEQUENCES TO <username>

Using the Database Dashboard

From your web browser, open your database dashboard
Once on the database dashboard, click the Settings tab, then select the Database Users tab
The list of available users is displayed under the Manage database users section

Using the Command Line

Make sure you have correctly setup the Scalingo command line tool
From the command line, list your databases:
```
scalingo databases
```
Locate the ID of the database for which you want to list users

From the command line, run the following command to list the users:

scalingo --database <database_ID> database-users-list

The output should look like this:

+----------------+-----------+-----------+---------------------+
|    USERNAME    | READ-ONLY | PROTECTED | PASSWORD ENCRYPTION |
+----------------+-----------+-----------+---------------------+
| my_app_4553    | false     | true      | SCRAM-SHA-256       |
| my_app_4553_rw | false     | false     | SCRAM-SHA-256       |
| my_app_4553_ro | true      | false     | SCRAM-SHA-256       |
+----------------+-----------+-----------+---------------------+

In this example, we can see that the database has 3 users available. The first one is protected, which means it’s been created along with the database. It can’t be removed. Among the two others, one can only read data from the database. We can also see the password encryption algorithm.

Creating a New User

The following restrictions apply when creating a new user, regardless of the method used:

Username:
- Must be between 6 and 32 characters long
- Can only contain alphanumerical characters and underscores (_)
- Must start with a letter
Password:
- Must be between 24 and 64 characters long.
- Must not contain the character " or '

Using the Database Dashboard

From your web browser, open your database dashboard
Once on the database dashboard, click the Settings tab, then select the Database Users tab
Click the Add a database user boutton and fill out the form
- Fill a username
- Fill the corresponding password twice
(optional) If you want to restrict this user to read only abilities, make sure to check the Read only checkbox
Validate by clicking the Add this user button

Using the Command Line

Make sure you have correctly setup the Scalingo command line tool
From the command line, list your databases:
```
scalingo databases
```
Locate the ID of the database for which you want to create a user
From the command line, run the following command to create a new user:
```
scalingo --database <database_ID> database-users-create <username>
```
Optionally, if you want to restrict this user to read only abilities, use the --read-only flag:
```
scalingo --database <database_ID> database-users-create --read-only <username>
```
Set the user password:
- Either chose a password and confirm it
- Or let the platform generate a password by leaving the field empty
The output should look like this:
- If you set a password:
```
User "my_user" created.
```
- If you let the platform generate a password:
```
User "my_user" created with password "YANs3y07m5_KJC2MSDGebh8tx1lliFWh2Yb239zVqGQvbElWDjIN7QWspVH92Ul8".
```

Updating or Resetting a User Password

It is possible to reset the password of any non-protected user.

Using the Database Dashboard (Reset Only)

From your web browser, open your database dashboard
Once on the database dashboard, click the Settings tab, then select the Database Users tab
Locate the non-protected user for which you want to reset the password
Open the … menu next to this user, then click Reset password
Confirm the reset operation and safely store the newly generated password

Using the Command Line

Make sure you have correctly setup the Scalingo command line tool

Update the user password with the following command:

scalingo --database <database_ID> database-users-update-password <username>

Example:

scalingo --database 699d6312565f770d0a6cdab3 database-users-update-password my_user

An interactive prompt asks you for a password you want to attribute to your user:
- Either choose a password and confirm it
- Or let the platform generate a password by leaving the field empty The output should look like this:
- If you set a password:
```
User "my_user" updated.
```
- If you let the platform generate a password:
```
User "my_user" updated with password "YANs3y07m5_KJC2MSDGebh8tx1lliFWh2Yb239zVqGQvbElWDjIN7QWspVH92Ul8".
```

Deleting a User

Using the Database Dashboard

From your web browser, open your database dashboard
Once on the database dashboard, click the Settings tab, then select the Database Users tab
Locate the user you want to remove
Open the … menu next to this user, then click Delete user
Confirm the removal

Using the Command Line

Make sure you have correctly setup the Scalingo command line tool

Remove the user with the following command:

scalingo --database <database_ID> database-users-delete <username>

Architecture Models

Thu, 18 Jun 2026 10:00:00 +0000

Scalingo Managed Database Service lets you deploy and operate databases in minutes, with a fully managed service built for production workloads. Common features cover scaling, resilience, security, backups and minute based pricing. Then, the architecture model you choose defines the level of execution and network isolation, and the SecNumCloud scope.

Architecture model	Shared Resources	Dedicated Resources
Execution isolation	Container with shared vCPU	VM with dedicated vCPU
Network isolation	Shared	Dedicated VPC
Cluster communications ¹	Encrypted communications	Encrypted communications
Regions	osc-fr1, osc-secnum-fr1	osc-fr1, osc-secnum-fr1
Availability Zones	Single AZ	Up to 3 AZ
Service classes	Starter, Business	Starter, Business, Enterprise
Scaling	Scale up and scale down	Scale up only
Service class switching	Scale in and out between service classes	Scale in and out between service classes
Attachment model	Add-on to an application	Dedicated database, no app required
Provisioning permissions	Any Collaborator²	Owner only
Collaborators	Inherits the app collaborators	Has its own collaborators
Network exposure	Enable/disable Internet access, no source filtering	Fine-grained firewall, optional Outscale Net Peering
HDS eligibility	Yes	Yes
SecNumCloud scope	Infrastructure qualified	Infrastructure qualified; Service targeted in 2026³

Shared Resources

Shared Resources is Scalingo’s default architecture model and has been powering our managed databases for years. It delivers strong performance and security on shared infrastructure.

It is suitable for a wide range of workloads, from development and testing to production.

Shared Resources Infrastructure Model

In the Shared Resources model, each database instance runs in its own dedicated container, managed by the Scalingo platform.

Containers run on shared hosts alongside other databases. Isolation is enforced at the container level, while the underlying infrastructure is shared.

For HA clusters, nodes are placed on different hosts to improve resilience against host-level failures.

Dedicated Resources

Dedicated Resources builds on the same deployment and management stack, but runs each database instance in a private environment with dedicated compute and network isolation (dedicated VM and dedicated VPC). For multi-node clusters, nodes are distributed across multiple Availability Zones within the same region. This provides stronger isolation and security.

Dedicated Resources are designed for SecNumCloud requirements and is the model we plan to certify under SecNumCloud.

Dedicated Resources Infrastructure Model

In the Dedicated Resources model, each database node runs on its own dedicated virtual machine, with allocated RAM, dedicated vCPU cores, and a dedicated storage volume with dedicated IOPS.

This infrastructure-level isolation (one VM per node) provides strong tenant separation and more predictable compute and storage performance.

Each database instance or cluster is deployed in a dedicated VPC. For multi-node clusters, nodes are distributed across up to three Availability Zones within the same region.

For Business and Enterprise (HA) plans, intra cluster communications are always encrypted, for both architecture models. ↩
The “Collaborator” role (excluding “Limited Collaborator”) allows users to provision add-ons. ↩
In 2026, Scalingo’s objective is to qualify the architecture model that powers Databases on Dedicated Resources. This qualification is not yet completed. ↩

Database Network Exposure

Thu, 18 Jun 2026 00:00:00 +0000

This page explains how Managed Databases can be accessed remotely at the network level depending on the architecture model.

At a Glance

By default, databases are not exposed to the public Internet. We apply secure connectivity settings out of the box, so your database is not publicly exposed unless you explicitly enable it.

	Shared Resources	Dedicated Resources
Default reachability	Reachable from the Scalingo regional network	Not reachable by default (no internal or public access)
Internet-routable endpoint	Optional, through Internet Accessibility	Available, denied by default, allowed only via firewall
Private peering endpoint	Not available	Optional, through Outscale Net Peering
Force TLS	Disabled by default	Enabled by default

For Shared Resources and Dedicated Resources fundamentals, see Architecture Models.

Shared Resources

Allowing Scalingo Apps To Reach a Database

Shared Resources databases are reachable from the Scalingo regional network by default. Apps running in the same region can reach the database at the network level without adding a firewall rule.

TLS and Force TLS

On Shared Resources, TLS is available, but Force TLS connections is disabled by default to maximize compatibility with application frameworks and database clients.

When Force TLS connections is enabled, the database denies any non-TLS connection, whether it comes from the Scalingo network (for example applications) or from the public Internet.

For multi-node clusters, intra-cluster communications are always encrypted and do not depend on the Force TLS connections setting. See Common Features.

Making Your Database Reachable from the Internet

Public Internet exposure is optional. To make the database reachable from the public Internet:

Enable Force TLS.
Enable Internet Accessibility from the database dashboard.
Use Direct Access for client connections.

Dedicated Resources

Dedicated Resources databases provide fine-grained control over network exposure. By default, no application, external client, or peered network can reach them until you explicitly allow traffic.

Outscale Net Peering

In addition to their Internet-routable endpoint, Dedicated Resources database instances can provide a private endpoint reachable through an Outscale Net Peering from an Outscale account in the same region as the database. This creates a private connectivity path between the database network and an Outscale VPC.

This access path is useful when your workloads run outside Scalingo but inside an Outscale VPC, and you want traffic to reach the database without using the public Internet route.

How the Firewall Works

With Dedicated Resources, the database endpoint is Internet-routable, but inbound traffic is denied by default. Access is controlled through a fine-grained firewall that follows an allowlist model: every incoming connection must match an explicit rule.

Each access path requires an explicit firewall rule:

Scalingo apps: add the matching managed firewall rule for the app region.
Public Internet clients: allow only the required public source IP addresses or CIDR ranges.
Outscale Net Peering: allow the private IP ranges from your own Outscale network in the firewall.

Allowing Scalingo Apps To Reach a Database

Dedicated Resources databases are not reachable from the Scalingo network by default. If a Scalingo app must connect to the database, add the managed firewall rule for the app region.

This rule allows the Scalingo regional network, so the database becomes reachable at the network level from any Scalingo app hosted in that region.

Making Your Database Reachable from External Networks

Open only required source networks in the firewall allowlist.
If needed, add managed rules for Scalingo regions.

Scalingo Operator for Kubernetes®

Thu, 18 Jun 2026 00:00:00 +0000

Scalingo Operator

Kubernetes is an open-source container orchestration platform used to deploy, scale and operate applications.

Scalingo maintains a Kubernetes Operator that lets you manage Scalingo Dedicated Resources instances directly from a Kubernetes cluster.

Scope

The Scalingo Kubernetes Operator is a deployment and provisioning tool for Dedicated Resources. It handles the operations:

create database
add/remove firewall rules
add net peerings
change plan
remove database

It does not target supervision or day-2 operations. Operations outside this scope must be handled through the Scalingo CLI, API, or Dashboard, for example:

Collaborator management
Database user management
Maintenance window configuration
PITR restoration
Database extension management

Get started

To start using the Scalingo operator in your Kubernetes cluster:

Deploy the Operator in your Kubernetes cluster using the install.yaml file from the latest release
Create a Scalingo API tokens from your account settings
Put the token in Kubernetes secret
Create your dedicated database custom resource, based on these examples
Apply the custom resource to deploy the dedicated database

For the complete list of resources, details and examples, see the operator documentation page.

Managing Dependencies

Tue, 16 Jun 2026 12:00:00 +0000

Composer is the official dependency manager for PHP. It allows to manage (download, install, upgrade, configure, and remove) the libraries a project depends on.

If you want the platform to use Composer to manage your dependencies, make sure to include both the composer.json and the composer.lock files in your codebase.

Declaring Dependencies

The dependencies required by your application must be declared in a file named composer.json, stored at the root of your codebase. The format is described in the Composer documentation.

Once your dependencies have been defined and declared, their versions must be frozen to ensure a precise version of the application will always be deployed with the same compatible set of Composer packages. This allows for better reproducibility and consistency across environments. These versions are written in a file named composer.lock, also stored at the root of your project.

Use Composer itself on your local computer (or in your CI/CD pipeline) to generate the composer.lock file:

$ composer install

To upgrade a dependency, run the following command (in the example below, we ask Composer to upgrade slim):

$ composer update slim/slim

In some circumstances, it can be convenient to add either the --ignore-platform-req= or the --ignore-platform-reqs flag to the above commands.

After each command, the composer.lock file is automatically updated. Don’t forget to commit the modifications!

Managing Private Dependencies

If you want to install a private dependency, you need to define the COMPOSER_AUTH environment variable, as specified in the Composer documentation.

For a private dependency hosted on GitHub, the COMPOSER_AUTH environment variable should contain:

{
  "github-oauth": {
    "github.com": "MY-TOKEN"
  }
}

MY-TOKEN must be replaced with a valid access token (OAuth token) for your GitHub account.

Such a token can be generated from your GitHub account. For more details about GitHub access tokens, please refer to their comprehensive documentation.

Specifying the Composer Version

You can select the Composer version to install by specifying it in your composer.json:

{
  "extra": {
    "paas": {
      "engines": {
        "composer": "2.x"
      }
    }
  }
}

Scalingo currently supports the following versions of Composer:

Composer	`scalingo-22` (EOL)	`scalingo-24`	`scalingo-26`
`2.10`	up to `2.10.1`	up to `2.10.1`	up to `2.10.1`
`2.2` (LTS)	up to `2.2.28`	up to `2.2.28`	up to `2.2.28`

Working with Composer Environments

By default, Scalingo considers that your application runs in production mode. This means that composer install automatically runs with the --no-dev flag. As a result, won’t install the development dependencies of your application, if any.

Set the COMPOSER_DEV environment variable to true if you would like to run your application with these development dependencies installed (e.g. to debug your app).

In addition to the --[no-]dev flag, the platform always runs composer install with the --prefer-dist and --optimize-autoloader flags.

PHP on Scalingo

Tue, 16 Jun 2026 12:00:00 +0000

Detection

Your application is detected as a PHP application if:

a composer.lock file is present in the root directory of your project
or if an index.php file is present in the root directory of your project (Classic app)

Stack

A stack based on Nginx and PHP-FPM is installed.

Default Configuration

The default configuration for your application is stored in two files, both available in the PHP buildpack:

Reviewing them can give you useful inputs, such as the default values for parameters like upload_max_filesize or post_max_size.

PHP Versions

Availability

The following PHP versions are available:

PHP Version	`scalingo-22` (EOL)	`scalingo-24`	`scalingo-26`
`8.5`	up to `8.5.7`	up to `8.5.7`	up to `8.5.7`
`8.4`	up to `8.4.22`	up to `8.4.22`	up to `8.4.22`
`8.3`	up to `8.3.31`	up to `8.3.31`	up to `8.3.31`
`8.2`	up to `8.2.31`	up to `8.2.31`	up to `8.2.31`

Select a Version

The default PHP version on all stacks is the latest 8.4 version. If you need to install another version, specify it in your composer.json file. For example, to install the latest PHP version of the 8.5 branch:

{
  "require": {
    "php": "~8.5"
  }
}

If you do not use composer.json (classic app), you can specify the PHP version through the environment variable PHP_VERSION.

PHP Extensions and Dependencies

See our dedicated documentation pages:

Supported Frameworks

Here is a non-exhaustive list of frameworks known to work on Scalingo:

Symfony
Laravel
Laravel Lumen
Slim
CakePHP
CodeIgniter
Laminas MVC
Magento

Configuration Tweaks

Setup Basic Authentication

You may want to hide your application behind an authentication gateway. You can configure HTTP basic auth for your application.

PHP-FPM Concurrency

The level of concurrency configured is defined automatically according to the size of the containers of your application. If you want to override this value, you can define the environment variable: WEB_CONCURRENCY. It directly modifies the pm.max_children parameter of PHP-FPM, defining the upper limit of how many workers handling incoming requests will be running. Each of these processes will be able to run 1 request at a time.

The default values for pm.max_children are based on the memory_limit parameter of the PHP configuration, the used formula is: floor(available_memory / php_memory_limit) + 2

Container Size	Memory (MB)	Default Concurrency
S	256	3
M	512	4
L	1024	7
XL	2048	12
2XL	4096	22

Concurrency Fine Tuning

Fine tuning the value of the WEB_CONCURRENCY environment variable is a bit tricky and must be handled with care. There is no magic formula and you should load test your application to find the best value matching your use case. If the application is swapping, you might need to lower the value of WEB_CONCURRENCY and increase the amount of containers. On the contrary, if your application does not use all its memory, you can try to slightly increase the WEB_CONCURRENCY value and make sure the application does not start swapping.

Note that if the WEB_CONCURRENCY value is too high your application will not be 100% available. You will see at some point the following error message in your application logs, multiple times:

connect() to unix:/tmp/php-fpm.sock failed (11: Resource temporarily
unavailable) while connecting to upstream, client: XXX.XXX.XXX.XXX, server:
localhost, request: "GET / HTTP/1.1", upstream:
"fastcgi://unix:/tmp/php-fpm.sock:", host: "example.com"

It happens when the PHP-FPM requests queue is full. Restarting your application empties this requests queue and makes your application back up. Then you should improve the value of the WEB_CONCURRENCY value.

Buildpack Custom Configuration

The buildpack allows you to configure precisely how your application is deployed. This configuration is done in your composer.json at the root of your project.

All these fields are optional, define them if you need to modify their default value.

{
  … // Your content
  "extra": {
    // default values of PaaS specific instructions
    "paas": {
      "document-root": "",
      "index-document": "index.php",
      "engines": {
        "nginx": "default"
      },
      "framework": "",
      "php-config": [],
      "php-includes": [],
      "php-fpm-config": [],
      "php-fpm-includes": [],
      "nginx-includes": [],
      "log-files": [],
      "compile": [],
      "new-relic": false,
      "access-log-format": ""
    }
  }
}

`.extra.paas.document-root`

The directory where Nginx will define the root of your app.

This parameter can also be overridden with the DOCUMENT_ROOT environment variable.

`.extra.paas.framework`

Bypass framework detection by specifying the framework you want. It could also be useful if you need to specify your application does not use any framework. This is done by specifying default in the .extra.paas.framework configuration.

`.extra.paas.index-document`

Name of the index document of each directory. When accessing a directory (https://example.osc-fr1.scalingo.io/web/), Nginx looks by default for an index.php file to execute, if your project is using another name, specify it here.

`.extra.paas.engines.composer`

Define a specific version of Composer to use. By default your application uses the latest Composer version available. Most of the time, you don’t need to change this value.

`.extra.paas.engines.nginx`

Define a precise version of Nginx to use. By default your application is reachable through the last stable version of the server. Most of the time, you don’t need to change this value.

Scalingo supports the following versions of Nginx:

Nginx version	`scalingo-22` (EOL)	`scalingo-24`	`scalingo-26`
`1.31` (Mainline)	Up to `1.31.2`	Up to `1.31.2`	Up to `1.31.2`
`1.30` (Stable)	Up to `1.30.3`	Up to `1.30.3`	Up to `1.30.3`

`.extra.paas.php-config`

List of directives which will be added to your php.ini. The default values used for your application are in the buildpack’s php.ini.

Example:

{
  "php-config": [
    "display_errors=off",
    "short_open_tag=on"
  ]
}

`.extra.paas.php-fpm-config`

List of directives which will be added to your php-fpm.ini.

Example:

{
  "php-fpm-config": [
    "log_level=debug"
  ]
}

`.extra.paas.php-includes`

Extra files which will be included in the php.ini.

`.extra.paas.php-fpm-includes`

Extra files which will be included in the php-fpm.ini.

`.extra.paas.nginx-http-includes`

Extra files which will be included in the Nginx configuration of your application. These files are injected at the http scope of the configuration file.

`.extra.paas.nginx-includes`

Extra files which will be included in the Nginx configuration of your application. These files are injected at the server scope of the configuration file.

`.extra.paas.compile`

Commands to run after the dependency installation.

Example:

{
  "compile": [
    "php app/console assetic:dump --env=prod --no-debug"
  ]
}

`.extra.paas.log-files`

If your project is writing in custom log files, you can specify them here and they will be streamed to the logs of your application.

Your can read the logs on your dashboard or with the Scalingo CLI utility.

`.extra.paas.datadog`

To enable Datadog support, set the extra.paas.datadog property to true. It makes the following Datadog products available:

Datadog APM (Application Performance Monitoring)
Datadog ASM (Application Security Management)

This automatically installs the latest available version of the Datadog Tracer and enables APM. To disable the tracer, set the DATADOG_TRACER_VERSION environment variable to 0 (latest by default). Note that disabling the tracer will also disable APM and ASM.

The Datadog ASM (Application Security Management) extension is disabled by default. To install and enable ASM, set the DATADOG_APPSEC_VERSION environment variable to latest (0 by default).

`.extra.paas.new-relic`

If true, enable New Relic instrumentation tools.

The environment variable named NEW_RELIC_LICENSE_KEY is required.

It is also highly recommended to include the NEW_RELIC_APP_NAME environment variable to specify the name of the application as displayed in the New Relic UI.

`.extra.paas.scout`

If true, enable Scout APM support.

You may want to use the environment variable SCOUT_APM_VERSION to install a specific version of the PECL extension.

`.extra.paas.access-log-format`

The format of the logs produced by the proxy Nginx for each request to your application.

It is empty by default, it means that Nginx will use the following format:

'$http_x_forwarded_for - "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent"'

e.g.

109.26.203.98 - "GET / HTTP/1.1" 200 1761 "https://google.com/search" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:51.0) Gecko/20100101 Firefox/51.0"

When defining a custom value for the log format, please refer to the Nginx documentation page..

This parameter can also be overridden with the ACCESS_LOG_FORMAT environment variable.

Warning: `.htaccess` Files

Classic PHP applications often use .htaccess file in their project to modify the configuration of the Apache server. As the buildpack is based on Nginx and PHP-FPM, these files are ineffective.

Instead of using these files, you have to write directives for Nginx and configure the nginx-includes part of your composer.json. It can contains one or more configuration files:

{
  …
  "extra": {
    "paas": {
      "nginx-includes": ["path/to/nginx_conf_file", …]
    }
  }
}

Example: Configuring Rate Limiting

In the following example we will set a rate limit of one request per second per IP.

Create a nginx-http.conf file at the root of your project:

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s;

Then create a nginx-app.conf file at the root of your project:

location /login {
    limit_req zone=mylimit;
    try_files $uri $uri/ /index.php?$query_string;
}

Then modify your composer.json to add nginx-http-includes and nginx-includes config:

{
  "extra": {
    "paas": {
      "nginx-http-includes": ["nginx-http.conf"],
      "nginx-includes": ["nginx-app.conf"]
    }
  }
}

Example: URL Rewriting (e.g. WordPress)

Here is an example of classic .htaccess which won’t work on Scalingo. You need to replace it with the Nginx configuration following the example.

Classic .htaccess example:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Nginx configuration:

location / {
  try_files $uri $uri/ /index.php?$args;
}

Documentation Center

Node.js

Detection

Node.js Versions

Availability

Select a Version

Dependencies Installation

Private Dependency

NPM Private Modules

Configuring NPM

Private Modules from SCM (GitHub/GitLab/etc.)

devDependencies Installation

Skip Pruning

Ensure you’re Tracking all your Dependencies

Do not Track Modules with Git

Node.js App Startup

Memory Management

Node.js Build Hooks

Custom Cache Folder

Meteor Application

Framework Requiring to Serve Static Files

Buildpack

Next.js

Standalone Mode

Vite

Angular

Yarn Known Issues

Catch SIGTERM In an Application Started With Yarn

Grafana - Grafana 13.1.0 is now available

Node.js - Node.js 22.23.1, 24.18.0, and 26.4.0 are now available

Grafana - Grafana 13.0.3 is now available

nginx: nginx 1.30.3 (stable) is now available

nginx: nginx 1.31.2 (mainline) is now available

Node.js - Node.js 22.23.0, 24.17.0, and 26.3.1 are now available

Prometheus - Prometheus 3.5.4 (LTS) is now available

Stack scalingo-26 is the Default Stack

PostgreSQL® Dedicated Resources - Outscale Net Peering Support

Accessing Your Scalingo for PostgreSQL® Dedicated Resources Database

Allowing Access with Firewall Rules

Using the Database Dashboard

Using the Command Line (Preview)

How the Firewall Works

Allowing Scalingo Apps To Reach a Dedicated Resources Database

Creating an Outscale Net Peering

Using Third Party Tools

Using pgAdmin

Connecting Your Scalingo for PostgreSQL® Dedicated Resources Database

Understanding the Connection URI

Getting the Connection URI

Using the Dashboard

Using the Command Line

Building the Connection URI from a Specific Endpoint

TLS Connections Are Enforced

Connecting Multiple Applications to the Same Database

Understanding Database Endpoints

Listing Database Endpoints with CLI

Types of Database Endpoints

Public RW

Private Peering RW

Build a Connection String from an endpoint

Provisioning a Scalingo for PostgreSQL® Dedicated Resources Database

Provisioning

Using the Dashboard

Using the Command Line (Preview)

Using the Terraform Provider

Using the Kubernetes Operator

Accessing the Scalingo for PostgreSQL® Dashboard

Managing Users of Your Scalingo for PostgreSQL® Dedicated Resources Database

Listing Existing Users

Understanding Protected User

Using the Database Dashboard

Using the Command Line

Creating a New User

Using the Database Dashboard

Using the Command Line

Updating or Resetting a User Password

Using the Database Dashboard (Reset Only)

Using the Command Line

Deleting a User

Using the Database Dashboard

Catch `SIGTERM` In an Application Started With Yarn

`.extra.paas.document-root`

`.extra.paas.framework`

`.extra.paas.index-document`

`.extra.paas.engines.composer`

`.extra.paas.engines.nginx`

`.extra.paas.php-config`

`.extra.paas.php-fpm-config`

`.extra.paas.php-includes`

`.extra.paas.php-fpm-includes`

`.extra.paas.nginx-http-includes`

`.extra.paas.nginx-includes`

`.extra.paas.compile`

`.extra.paas.log-files`

`.extra.paas.datadog`

`.extra.paas.new-relic`

`.extra.paas.scout`

`.extra.paas.access-log-format`

Warning: `.htaccess` Files