Procfiles are used to define Explicit Services (Procfiles) for an app.
They are completely optional: in the absence of a Procfile, Aptible Deploy will fallback to an Implicit Service.
If you are using Dockerfile Deploy, add a file named
Procfile at the root of your repository.
If you are using Direct Docker Image Deploy, it must be located at
/.aptible/Procfile in your Docker image. See Procfiles and
.aptible.yml with Direct Docker Image Deploy for more information.
The Procfile syntax is standardized, and consists of a mapping of one or more Service names to commands that should be executed for those Services.
The two should be separated by a
The commands in your Procfile (i.e. the section to the right of the
: character) is interpreted differently depending on whether your image has an
ENTRYPOINT or not:
If your image does not have an
ENTRYPOINT, the Procfile will be executed using a shell (
This means you can use shell syntax, such as:
web: setup && run "$ENVIRONMENT"
The following is advanced information. You don't need to understand or leverage this information to use Aptible Deploy, but it might be relevant if you want to precisely control the behavior of your Containers.
PID 1 is the process that receives signals when your Container is signalled (e.g. PID receives
SIGTERM when your Container needs to shutdown during a deployment).
Since a shell is used as the command in your Containers to interpret your Procfile, this means PID 1 will be a shell.
Shells don't typically forward signals, which means that when your Containers receive
SIGTERM, they'll do nothing if a shell is running as PID 1. As a result, running a shell there may not be desirable.
If you'd like to get the shell out of the equation when running your Containers, you can use the
exec call, like so:
web: setup && exec run "$ENVIRONMENT"
This will replace the shell with the
run program as PID 1.
If your image has an
ENTRYPOINT, Aptible Deploy will not use a shell to interpret your Procfile. Instead, your Procfile line is split according to shell rules, then simply passed to your Container's
ENTRYPOINT as a series of arguments.
For example, if your Procfile looks like this:
web: run "$ENVIRONMENT"
ENVIRONMENT will receive the literal strings
$ENVIRONMENT as arguments (i.e. the value for
$ENVIRONMENT will not be interpolated).
This means your Procfile doesn't need to reference commands that exist in your Container: it only means to reference commands that make sense to your
However, it also means that you can't interpolate variables in your Procfile line. If you do need shell processing for interpolation with an
ENTRYPOINT, here are two options:
The simplest option is to alter your
Procfile to call a shell itself, like so:
web: sh -c 'setup && exec run "$ENVIRONMENT"'
A better approach is to add a launcher script in your Docker image, and delegate shell processing there.
To do so, create a file called
/app.sh in your image, with the following contents, and make it executable:
#!/bin/sh # Make this executable # Adjust the commands as needed, of course! setup && exec run "$ENVIRONMENT"
Once you have this launcher script, your Procfile can simply reference the launcher script, which is simpler and more explicit:
Of course, you can use any name you like:
/app.sh isn't the only one that works! Just make sure the Procfile references the launcher script.
web: bundle exec rails server
web: bundle exec rails server worker: bundle exec sidekiq
web: bundle exec rails server worker: bundle exec sidekiq -c "$SIDEKIQ_CONCURRENCY"
Updated 28 days ago