Supervisor (supervisord) Config Generator

Generate a Supervisor [program:x] section from a form. Set the command and working directory, the user to run as, how many processes to fork, the autostart/autorestart behaviour, environment variables, stop signal and log file settings — and get a correctly-formatted block to drop into /etc/supervisor/conf.d/. It generates live and runs entirely in your browser.

How to use the Supervisor (supervisord) Config Generator

Give the program a name (it becomes [program:name] and the label you'll use with supervisorctl) and the full command to run — always an absolute path, since Supervisor does not use a login shell. Set the working directory and the user to drop privileges to. If you need several identical workers, set numprocs above one and the generator adds the process_name template Supervisor requires so each gets a distinct name like worker_00, worker_01.

The restart settings control supervision. autostart launches the program when Supervisor starts; autorestart=true restarts it whenever it exits, while unexpected restarts only on exit codes you didn't declare as normal. startsecs is how long the process must stay up to count as successfully started, and stopwaitsecs is how long to wait after the stop signal before sending SIGKILL — raise it for workers that need to finish in-flight jobs. Add environment variables one per line. Save the block as /etc/supervisor/conf.d/name.conf, then run supervisorctl reread and supervisorctl update to load it.

What Supervisor is and when to reach for it

Supervisor is a process control system: a long-running daemon (supervisord) that starts your programs, keeps them running, restarts them when they crash, and gives you a single command-line and web interface (supervisorctl) to start, stop and tail them. It predates systemd's ubiquity and remains popular because its per-program configuration is simple, portable across distributions, and runs comfortably inside containers and minimal images where a full init system is awkward.

A program is declared in an INI-style [program:name] section. The essential fields are command (what to run, as an absolute path — Supervisor execs it directly, not through a shell, so shell features like pipes or globbing won't work unless you invoke a shell explicitly), directory, user, and the start/restart policy. Because Supervisor manages the process directly rather than daemonising it, your program must run in the foreground and not fork into the background; a program that double-forks will appear to exit immediately and Supervisor will keep restarting it.

Supervisor shines for running multiple application workers — Celery queues, queue consumers, websocket servers, cron-like loops — under one supervisor, each with its own log files, environment and restart behaviour, and for the common container pattern of running one or two foreground processes with automatic restart. The trade-offs versus systemd are real: Supervisor has no socket activation, no cgroup resource control, and no dependency ordering beyond priority, so for full host-level service management systemd is usually the better fit. This generator emits a conventional program section with sensible logging and restart defaults so the block you deploy is well-formed from the start.

Common use cases

  • Background workers. Run Celery, Sidekiq-style, or custom queue consumers with automatic restart and multiple processes.
  • Containers. Supervise one or two foreground processes in an image where a full init system is overkill.
  • App servers. Keep a Gunicorn, uWSGI or Node process running and restart it on crash.
  • Scheduled loops. Manage a long-running script that polls or processes work continuously.

Frequently asked questions

Why does my program keep restarting?
The most common cause is a program that daemonises (forks into the background). Supervisor must manage the process in the foreground, so configure your program with its no-daemon / foreground flag. Other causes are a non-absolute command path, a missing working directory or user, or the process exiting before startsecs elapses.

How do I run several identical workers?
Set numprocs above 1. Supervisor then needs a process_name template so the instances get distinct names; this generator adds process_name=%(program_name)s_%(process_num)02d automatically, producing names like worker_00 and worker_01 that you can manage individually with supervisorctl.

What is the difference between autorestart=true and unexpected?
true restarts the program whenever it exits, regardless of exit code. unexpected restarts it only when it exits with a code not listed in exitcodes (default 0), which is useful for programs that are meant to exit cleanly sometimes. false never restarts automatically.

How do I apply the config after editing it?
Save the section as a .conf file in /etc/supervisor/conf.d/, then run "supervisorctl reread" to pick up changes and "supervisorctl update" to apply them. Use "supervisorctl status" to see state and "supervisorctl tail -f name" to follow a program log.

Should I use Supervisor or systemd?
Use systemd for host-level services that benefit from socket activation, cgroup limits and dependency ordering. Reach for Supervisor when you want simple, portable per-program supervision — especially several application workers under one umbrella, or inside containers where running systemd is impractical.