Deploy a Node.js App to Scalingo and Scale Web Containers

Problem and takeaway

You push a Node.js application to Scalingo, but the router cannot reach it because the app listens on a hardcoded port and no web process is declared. The fix is to add a Procfile, bind to the PORT environment variable, push to the Scalingo Git remote, then scale the web process. Code changes require a new Git push; environment variable changes restart containers without a rebuild.

Desired outcome

A Node.js application is running on Scalingo behind its assigned URL, with two web containers receiving HTTP traffic through the platform router.

Prerequisites

• A Scalingo account with an SSH public key or API token registered.
• The Scalingo CLI installed locally; scalingo --version returns a version string.
• A Node.js project in a local Git repository.
• Maintainer or collaborator access to the target Scalingo application.

These steps assume a current Scalingo CLI release. Older CLI versions may use different flags or command names.

1. Authenticate the CLI

Run in your local terminal:

scalingo login
scalingo --version

scalingo login authenticates using a browser flow or API token depending on your CLI version. Without authentication, pushing to the Scalingo Git remote is rejected.

2. Declare the web process in a Procfile

Create Procfile at the repository root:

web: node server.js

The web process type tells Scalingo which command starts the service that receives HTTP traffic. Without it, the platform may not expose your application through the router.

3. Bind to the PORT environment variable

Scalingo provides the listening port through PORT. Hardcoding 3000 or 8080 means the router sends traffic to a port nothing is listening on.

const port = process.env.PORT || 3000;
app.listen(port, () => {
  console.log(`Listening on ${port}`);
});

Keep the local fallback for development, but retain the process.env.PORT lookup so the platform router can reach the app.

4. Add the Scalingo remote and push

From the repository root:

scalingo git-setup my-app-name
git push scalingo main

Replace my-app-name with your Scalingo application name and main with the branch you want to deploy. Scalingo runs buildpack detection, compiles a slug, and starts containers. A failed build leaves the previous release running unless the platform marks the application as failed.

5. Scale the web process

After the build completes:

scalingo scale web=2:100M

This requests two web containers with 100 MB of memory each. Available container sizes and total container hours depend on your plan.

Expected checks

• Open the Scalingo dashboard and confirm the deployment list shows a successful build.
• Run scalingo logs --follow during the push and confirm the Procfile command starts and the application logs its listening port.
• Request the Scalingo-assigned application URL and confirm the router returns a response instead of a connection error.
• Run scalingo scale without arguments or open the dashboard container list to confirm two web containers are active.

Recovery options

• Configuration changes only: Use scalingo env-set KEY=value to restart containers without a new build. This is useful for tuning configuration after deployment.
• Faulty release: Open deployment history in the dashboard and reactivate the previous deployment. This rolls back the running code without a new Git push.
• Build failure: Fix the Procfile or port binding locally, commit, and push again. The previous release continues to serve traffic while the new build fails.

Limitations

• Buildpack auto-detection can select the wrong runtime for monorepos or nonstandard layouts. If detection fails, declare a buildpack in .buildpacks or set the application root in the dashboard.
• Free or hobby plans may put containers to sleep after inactivity and enforce container-hour limits. Confirm plan terms before production use.
• scalingo scale changes running infrastructure immediately and has no CLI confirmation prompt. An incorrect container size can exhaust plan quotas.

Practical verification

After scaling, run:

scalingo logs --follow --n 50

Look for lines showing the web process started and requests reaching the router. Repeated container crashes usually indicate a missing PORT binding or a Procfile syntax error.