Processes

How your application splits its workload across multiple containers.

An application on Nodion can run more than one kind of container at the same time. Each kind is called a process. A typical web app has a web process that handles HTTP traffic and a worker process that runs background jobs. They share the same code, but each one has its own command, its own scaling, and optionally its own ports, volumes and environment variables.

How processes are discovered

If your repository contains a Procfile at the root, Nodion reads it during the build and turns each entry into a process. You don't need to click anything together in the dashboard, your code defines what runs.

web: bundle exec puma
worker: bundle exec sidekiq
release: bundle exec rails db:migrateProcfile

The example above declares two long-running processes (web and worker) and one one-shot stage (release). On the next deploy you'll see them appear under the Processes tab of your application.

If your application is built from a Dockerfile and there's no Procfile, Nodion creates a single web process by default. You can add more processes manually from the dashboard.

Long-running processes

The most common process is long-running: a container that boots up, listens for traffic or background work, and stays alive. The web process is the canonical example, but you can have as many as you need (workers, schedulers, sidecars, you name it).

Each long-running process has its own settings:

• Instance count — how many copies of this process should run in parallel. Set to 0 to keep the process configured but not deployed.
• Instance type — the hardware tier (CPU, memory) for each container. Different processes can run on different sizes, so a small worker doesn't need to share resources with a beefy web tier.
• Ports — which ports the container exposes. A process becomes reachable from outside as soon as it has at least one port. Without ports it's purely background work.
• Volumes — persistent storage attached to this process. See Volumes for details.
• Environment variables — process-level variables that override the application-level ones with the same key. See Environment Variables for details.

The web process and $PORT

If your Procfile contains a web: entry, Nodion treats it specially. The first time it's discovered, a default HTTP port and subdomain are configured automatically, and the container is booted with a PORT environment variable that tells your application which port to bind on. That way you don't need to hard-code anything:

const port = process.env.PORT || 3000;
app.listen(port);Node.js

For other process names, ports are optional. If you want them reachable from the public internet, add at least one port in the dashboard. Without ports, the process runs as background work only.

Runs (one-shot stages)

Some commands aren't meant to run continuously, they should fire once during a deploy and then exit. Database migrations are the classic example. Nodion calls these runs. They live alongside your long-running processes but with a different lifecycle.

The most common run is the release stage. If you put a release: entry in your Procfile, that command runs before your new code goes live, on every deploy. If it fails, the deploy is rolled back and your old version keeps serving traffic.

A run has these settings:

• Run policy — when the run fires:
  • Every deploy — runs on each successful build (the default for release:)
  • First deploy only — runs once when the application is first set up, then never again automatically
  • Manual — only runs when you trigger it from the dashboard or API
• Timeout — how long the run is allowed to take before being killed
• Volumes and environment variables — same as long-running processes, but typically only set if the run needs them. By default a run starts with no mounts and only inherits app-level env vars.

You'll find the result of the latest run on each run's card in the dashboard, including its exit status and a link to the logs.

Scaling and editing

Open the Processes tab on your application. Each process gets its own card with quick actions for scaling, viewing instances, editing settings, attaching volumes and managing environment variables. Changes take effect on your next deploy or scale event.

What happens when you change your Procfile

Nodion reconciles your processes on every deploy:

• A new entry in your Procfile becomes a new process. Long-running processes start at 0 instances so you can configure them before they go live, the web process is the exception and is set up immediately.
• An entry that was already there keeps its existing settings. Your scaling config, port assignments, volumes and environment variables aren't touched.
• An entry that disappears from the Procfile is marked as orphaned. The process stops running but its configuration is preserved. If you re-add it later, it picks up exactly where it left off.
• A process you delete from the dashboard stays deleted. If you re-add the same name to your Procfile and push, it comes back with the previous configuration.