Multi-process

First steps

Create a free Runway account.
Install the CLI. See the install docs.
Log in:
```
runway login
```
Add an SSH key. See key setup, or use the shortcut:
```
runway local key setup
```

Start a new project:

mkdir my-app
cd my-app
git init
runway app create

Many apps are a single web server, and Runway runs that for you without any configuration. Some apps need more: a migration step that runs before new code serves traffic, or a background worker that consumes a queue. Runway handles this with a Procfile.

The Procfile

A Procfile is a file at the root of your repository. Each line declares one process:

Procfile

<process type>: <command>

Process types

Runway supports web, init, and worker process types:

web

Required. Continuously running, and needs to listen on a port (unless runway route off is set).

web is your app’s main process. If you have a Procfile, you will need to at least specify web. If you have no Procfile at all, Runway handles that automatically for you.
init

Runs once before the web process starts.

init runs to completion before the web process starts accepting traffic, on every deploy. Database migrations belong here: a failing init fails the deploy.
worker

Continuously running, does not receive traffic on a port.

A worker is expected to stay up: if it exits, the whole app restarts.

web is only automatic without a Procfile

When there is no Procfile, Runway starts your app as a single web process, with no command-line arguments. This is why most apps need no Procfile at all.

As soon as a Procfile exists, it defines the complete list of processes. Nothing is added implicitly. If you add a Procfile for a worker or init process, you must also declare web: yourself, or the app has no web process and the build fails validation.

Procfile

web: my-app --server
init: my-app --migrate
worker: my-app --consume-queue

It is sometimes not trivial to figure out what command to use as the web process - see the language-specific guides for details.

How the processes run

All processes run from the same image that Runway builds, and share the same configuration you set with runway app config set. Each process runs in its own environment, though, and cannot share local memory with the others.

The worker process can reach the web process over the loopback interface, on the port web listens on (for example curl http://localhost:5000).
Persistent storage is available to the web process only. On apps created with persistence enabled, the /data volume is mounted for web; init and worker cannot read or write it. Use a database or an object store to pass data between processes.

To inspect what is running, and to open a shell in the worker container:

runway app ps       # show running processes
runway app exec -w  # open a shell in the worker container
runway app logs     # logs of all processes

Language guides

The details of the web command, and how extra binaries or scripts get built, depend on the language:

Go: multi-process for Go - build multiple targets with BP_GO_TARGETS and map them to process types.
PHP: workers & init for PHP - the web command for a PHP app, with Symfony and Laravel examples.
Node.js: multi-process for Node.js - a web server, a worker, and an init script in one repository.

Buildpack only

Procfiles are only used for buildpack-based apps (the default on Runway). If your repository has a Dockerfile, Runway builds and runs that instead, and the Procfile is ignored.

Company