Running Production on Scalingo: Add-ons, Scaling and the Real Limits of a Sovereign Heroku Alternative

Since Heroku dropped its free tier in late 2022, and since sovereignty has become a recurring topic in procurement meetings, many European teams have taken a fresh look at Scalingo. The pitch is simple: the same developer experience as Heroku (git push, buildpacks, Procfile, add-ons), hosted and operated in France, with a SecNumCloud-ready offering for regulated workloads. But a PaaS is a contract. You trade control for speed, and the real question is where the limits of that contract lie once you run in production.

This guide walks through a production deployment on Scalingo, explains how add-ons and scaling work, and compares the platform with Heroku on the points that actually influence the decision.

The Scalingo model in a nutshell

Scalingo is a French Platform-as-a-Service founded in Strasbourg. Applications run in containers on European infrastructure, mainly on 3DS Outscale in the Paris region. Two regions matter in practice:

• osc-fr1: the standard region, hosted in France.
• osc-secnum-fr1: a region built on SecNumCloud-qualified infrastructure, aimed at public-sector, healthcare and other sensitive workloads. Scalingo also holds the French HDS certification for health data hosting.

The building blocks will feel familiar to anyone who has used Heroku: an app made of container types declared in a Procfile (web, worker, clock…), managed add-ons for databases, and configuration injected through environment variables. Builds rely on buildpacks, largely compatible with the Heroku ecosystem, which is why migrations are usually straightforward.

Deploying an application step by step

Take a typical Node.js API with a PostgreSQL database and a background job worker. With the scalingo CLI installed and authenticated:

# Create the app in the target region
scalingo --region osc-fr1 create acme-api

# Attach a managed PostgreSQL database
scalingo --app acme-api addons-add postgresql postgresql-starter-512

# Application configuration
scalingo --app acme-api env-set NODE_ENV=production LOG_LEVEL=info

# Deploy
git push scalingo main

The DATABASE_URL variable (along with an add-on-specific SCALINGO_POSTGRESQL_URL) is injected automatically. Process types are declared in the Procfile:

web: node dist/server.js
worker: node dist/worker.js
postdeploy: node dist/migrate.js

The postdeploy entry is a Scalingo feature worth knowing: it runs once after each successful deployment, before new containers receive traffic. It is the natural home for database migrations. If it fails, the deployment is aborted and the previous version keeps serving traffic, which is exactly what you want in production.

Your app must listen on the port given in the PORT variable and respond quickly at startup: the platform waits for the process to bind the port before switching traffic. Zero-downtime deployments are the default for web containers, as long as your app handles SIGTERM gracefully.

Add-ons: what is managed, and what is not

Scalingo's catalog is deliberately focused on core building blocks, operated in-house: PostgreSQL, MySQL, MongoDB, Redis, Elasticsearch/OpenSearch, InfluxDB. The plans cover the full spectrum, from shared instances for staging to high-availability plans with replication and automatic failover, with scheduled backups and point-in-time recovery on business plans.

What you get:

• Version upgrades and maintenance driven from the dashboard or CLI.
• Backups, restore, and access to logs and metrics of the database.
• Network access restriction and TLS connections.
• Data stored in France, operated by a French company.

What you don't get, compared with Heroku Elements: a marketplace of hundreds of third-party services wired in with a single command. On Scalingo, monitoring (Datadog, Sentry), email sending, search-as-a-service or object storage will usually be consumed directly from the vendor, configured through environment variables. This isn't a blocker, but it means more manual wiring and, importantly, a sovereignty assessment for each of those external dependencies. Hosting your app in France is of little use if your error logs, with their personal data, go to a US tool.

For object storage, the usual approach is to use an S3-compatible service from a European provider (Outscale, OVHcloud, Scaleway), since the container filesystem is ephemeral.

Scaling: vertical, horizontal and autoscaling

Scaling on Scalingo has two dimensions per container type:

• Vertical: container size (S, M, L, XL, 2XL…), which determines available memory and CPU share.
• Horizontal: number of containers, with load balancing across web containers handled by the platform's router.

# 3 M-sized web containers, 2 workers
scalingo --app acme-api scale web:3:M worker:2:M

# Autoscaling web containers on CPU
scalingo --app acme-api autoscalers-add \
  --container-type web --metric cpu --target 0.7 \
  --min-containers 2 --max-containers 8

The autoscaler can rely on several metrics (CPU, RAM, response time, requests per minute per container). A few operational recommendations from experience:

• Keep a minimum of two web containers in production, both for availability and to absorb a container restart.
• Choose response time or RPM as the metric for I/O-bound APIs: CPU often stays low while the database is saturated.
• Scaling the app does not scale the database. Doubling web containers doubles database connections; size your pool (or add PgBouncer-style pooling at app level) before turning on autoscaling.
• Workers are not autoscaled on queue length out of the box; if that matters, drive scale via the API from your own job.

Scalingo vs Heroku: the comparison

On developer experience, the two are very close: an app running on Heroku generally runs on Scalingo with minor tweaks (stack, buildpack, environment variables). The decision is therefore rarely technical. It mostly hinges on three questions: does your data need to stay under European jurisdiction? Do you need HDS or SecNumCloud? Do you heavily depend on Heroku add-ons with no direct equivalent?

The limits of a PaaS, sovereign or not

Let's be honest: Scalingo shares the structural limits of any PaaS, plus a few of its own.

• Ephemeral filesystem: anything written to disk disappears on restart. Uploads, generated files and caches must go to object storage or Redis.
• Ceiling on container size: memory-heavy workloads (in-memory analytics, large ML models) quickly hit the top of the range. No GPUs either.
• Limited network control: no fine-grained VPC, custom service mesh or arbitrary TCP ports like you would have on Kubernetes. Integrations with on-premise systems require planning (IP allow-listing, dedicated options to discuss with the vendor).
• Workload model: long-running HTTP requests, complex workflow orchestration or stateful workloads are a poor fit. Push heavy work to asynchronous workers.
• Cost at scale: a PaaS charges for convenience. For a few dozen apps, this is generally cheaper than a platform team. Beyond a certain fleet size, a managed Kubernetes cluster on a European cloud can become more cost-effective, but only if you factor in the human cost of operating it.

Production checklist

• Two or more web containers, with SIGTERM handling and a health endpoint.
• Migrations in postdeploy, backward-compatible with the previous version of the code (expand/contract).
• Business-plan database with replication and PITR for anything critical; restore regularly tested.
• Log drain to your log stack and alerts on response time and container restarts.
• Review apps enabled via scalingo.json for pull requests, with an anonymized data seed.
• Secrets stored only in environment variables, rotated, never in the repository.
• Sovereignty check of every third-party SaaS consumed by the app.

When to choose Scalingo

Scalingo is an excellent choice for product teams that want to ship fast without a dedicated platform team, especially when data sovereignty or HDS/SecNumCloud compliance is a requirement and not just a nice-to-have. It is the natural migration path from Heroku for European organizations. It becomes less relevant as soon as your workloads need fine network control, GPUs, very large instances or a fleet so large that a managed Kubernetes platform pays for itself. In many organizations, the right answer is a mix: Scalingo for standard web apps and APIs, Kubernetes for the few workloads that genuinely need it.