Guides
Apps
Endpoints
Databases
Containers
Stacks
CLI
- Aptible CLI
- aptible apps
- aptible apps:create
- aptible apps:deprovision
- aptible apps:rename
- aptible apps:scale
- aptible backup:list
- aptible backup:orphaned
- aptible backup:purge
- aptible backup:restore
- aptible config
- aptible config:add
- aptible config:rm
- aptible config:set
- aptible config:unset
- aptible db:backup
- aptible db:clone
- aptible db:create
- aptible db:deprovision
- aptible db:dump
- aptible db:execute
- aptible db:list
- aptible db:modify
- aptible db:reload
- aptible db:rename
- aptible db:replicate
- aptible db:restart
- aptible db:tunnel
- aptible db:url
- aptible db:versions
- aptible deploy
- aptible domains
- aptible endpoints:database:create
- aptible endpoints:database:modify
- aptible endpoints:deprovision
- aptible endpoints:https:create
- aptible endpoints:https:modify
- aptible endpoints:list
- aptible endpoints:renew
- aptible endpoints:tcp:create
- aptible endpoints:tcp:modify
- aptible endpoints:tls:create
- aptible endpoints:tls:modify
- aptible environment:ca_cert
- aptible environment:list
- aptible environment:rename
- aptible help
- aptible log_drain:create:datadog
- aptible log_drain:create:elasticsearch
- aptible log_drain:create:https
- aptible log_drain:create:logdna
- aptible log_drain:create:papertrail
- aptible log_drain:create:sumologic
- aptible log_drain:create:syslog
- aptible log_drain:deprovision
- aptible log_drain:list
- aptible login
- aptible logs
- aptible logs_from_archive
- aptible metric_drain:create:datadog
- aptible metric_drain:create:influxdb
- aptible metric_drain:create:influxdb:custom
- aptible metric_drain:deprovision
- aptible metric_drain:list
- aptible operation:cancel
- aptible operation:follow
- aptible operation:logs
- aptible rebuild
- aptible restart
- aptible services
- aptible ssh
- aptible version
Tutorials
- Application Performance Monitoring
- CI Integration
- Aptible Demo App
- Deploying Grafana
- Direct Docker Image Deploy Example
- Dockerfile Deploy Example
- Exposing a Web App to the Internet
- Using Nginx with Aptible Endpoints
- Quickstart Guides
- Setting up Logging
- Automating Database Migrations
- Dockerfile Caching
- Using Domain Apex with Endpoints
- Accepting File Uploads
- Scheduling Tasks
- Serving Static Assets
- Terraform
- How to test a PostgreSQL Database's schema on a new version
- How to dump and restore PostgreSQL
- How to upgrade PostgreSQL with logical replication
- How to upgrade Redis
- How to upgrade MongoDB
- How to use mysqldump to Test for Upgrade Incompatabilities
- How to dump and restore MySQL
Troubleshooting
- Aptible Support
- App Processing Requests Slowly
- This Application Crashed
- before_release Commands Failed
- Build Failed
- Container Failed to Start
- Certificate Signing Requests
- Deploys Take Too long
- git Reference Error
- git Push "Everything up-to-date."
- HTTP Health Checks Failed
- App Logs Not Being Received
- PostgreSQL Replica max_connections
- Connecting to MongoDB fails
- MySQL Access Denied
- No CMD or Procfile in Image
- git Push Permission Denied
- aptible ssh Permission Denied
- PostgreSQL Incomplete Startup Packet
- PostgreSQL SSL Off
- Private Key Must Match Certificate
- aptible ssh Operation Timed Out
- SSL error ERR_CERT_AUTHORITY_INVALID
- SSL error ERR_CERT_COMMON_NAME_INVALID
- Unexpected Requests in App Logs
Procfiles
Procfiles are used to define Explicit Services (Procfiles) for an app.
They are completely optional: in the absence of a Procfile, Aptible will fallback to an Implicit Service.
Providing a Procfile
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.
Procfile syntax
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 :
character.
Procfile Commands
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:
Images without an ENTRYPOINT
If your image does not have an ENTRYPOINT
, the Procfile will be executed using a shell (/bin/sh
).
This means you can use shell syntax, such as:
web: setup && run "$ENVIRONMENT"
Advanced: PID 1 in your Container is a shell
📘 Note
The following is advanced information. You don't need to understand or leverage this information to use Aptible, 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.
Images with an ENTRYPOINT
If your image has an ENTRYPOINT
, Aptible 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"
Then, your ENVIRONMENT
will receive the literal strings run
and $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 ENTRYPOINT
.
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:
Call a shell from the Procfile
The simplest option is to alter your Procfile
to call a shell itself, like so:
web: sh -c 'setup && exec run "$ENVIRONMENT"'
Use a launcher script
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:
web: /app.sh
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.
Procfile examples
Single web
service
web: bundle exec rails server
web
and worker
services
web: bundle exec rails server
worker: bundle exec sidekiq
Using environment variables
web: bundle exec rails server
worker: bundle exec sidekiq -c "$SIDEKIQ_CONCURRENCY"