supervisord.conf

[supervisord]
nodaemon=true
user=root
logfile=/var/log/supervisor/supervisord.log
logfile_maxbytes=10MB
logfile_backups=3
; warn, not info: at info supervisord narrates its own startup in eight lines
; (Set uid, started with pid, spawned, entered RUNNING) that say nothing an
; operator acts on. What matters survives at warn: `exited: ... not expected`,
; the line that repeats while a program crash-loops, is logged at warn, and
; configuration failures are logged at critical.
;
; The one loss is `gave up: ... entered FATAL state`, which supervisor logs at
; info. That case is already covered in plainer language by the two messages
; this repo prints itself, from scripts/exit-on-fatal.py and
; docker-entrypoint.sh. Do not restore info without re-reading that trade.
loglevel=warn
pidfile=/run/supervisord.pid

[program:nginx]
command=/usr/sbin/nginx -g "daemon off;"
autostart=true
autorestart=true
priority=10
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0
startretries=3
startsecs=2

[program:api]
command=node /app/api/src/server.js
directory=/app/api
user=node
autostart=true
autorestart=true
priority=20
; PORT is pinned: nginx proxies to 127.0.0.1:3000, and a platform that sets
; PORT for the container means the port nginx serves on. CONFIG_PATH and
; ICONS_PATH are not pinned. They carry the same values as the defaults in
; api/src/config.js, and pinning them here made the documented variables inert.
environment=NODE_ENV="production",PORT="3000",HOME="/home/node"
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0
startretries=3
startsecs=3

; Shut the container down when a program cannot be started at all.
;
; supervisord gives up on a program after startretries and marks it FATAL, then
; keeps running because the other program is still alive. The container stayed up
; with a dead API inside it and never recovered: Docker's healthcheck marks it
; unhealthy, but `restart: unless-stopped` restarts a container that exits, not
; one that is merely unhealthy.
;
; See scripts/exit-on-fatal.py.
[eventlistener:exit-on-fatal]
command=/usr/bin/python3 /app/scripts/exit-on-fatal.py
events=PROCESS_STATE_FATAL
autostart=true
autorestart=true
priority=1
; Not /dev/stdout: this program's stdout is the event listener protocol channel,
; so supervisord copying it to the child log puts READY, RESULT and OK in
; `docker logs`. supervisord still reads the protocol over its own pipe.
; stderr must stay on /dev/stderr; the "could not be started" message goes there.
stdout_logfile=/dev/null
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0