Supervisor is a process control system: software whose job is to launch a set of programs, keep them running, and restart them if they die. Its documentation states it plainly: “Supervisor is a client/server system that allows its users to monitor and control a number of processes on UNIX-like operating systems.” Where an init system manages the whole machine’s services as PID 1, Supervisor manages a chosen group of programs at the project level, started like any other application.
The system has two main parts, reflected in the documentation. supervisord is the server: it reads a configuration file listing the programs it should manage, starts them as its own child processes, captures their output, and brings them back up when they exit unexpectedly. supervisorctl is the command-line client used to talk to that server, letting an operator start, stop, restart, and check the status of the managed programs without touching the underlying processes directly. There is also a web interface and an XML-RPC interface for control by other software. The project is written in Python; the GitHub repository reports a codebase that is overwhelmingly Python and runs on Linux, macOS, Solaris, and FreeBSD, though not on Windows.
Crucially, Supervisor is not trying to be init. Its documentation is explicit that it differs from programs like launchd, daemontools, and runit in that it “is not meant to be run as a substitute for init as ‘process id 1.’” Instead it launches at boot or by hand like an ordinary program and supervises only the processes it is told to. This is exactly what makes it useful in places where the real init is out of reach or inappropriate: inside a container that runs more than one process, on a shared host where an unprivileged user cannot install system services, or in a development environment where a lightweight, self-contained way to keep several programs alive is all that is needed.
The practical appeal is that Supervisor turns the fragile job of running long-lived programs into configuration. Rather than writing shell scripts that fork, redirect output, write PID files, and check whether a process is still alive, a developer writes a short block describing each program, its command line, and its restart policy, and supervisord handles the running, logging, and restarting. The programs themselves do not need to know how to daemonize; they can run in the foreground and let Supervisor own the supervision.
Supervisor occupies a clear niche between writing everything by hand and standing up a full init system. Many web applications, background workers, and queue consumers have been kept alive in production by a supervisord configuration, especially in the era before lightweight container runtimes and during the long transition between SysV init and systemd.
Its longevity comes from doing one bounded thing well: take a list of programs that should always be running, and make sure they are, with a simple way for a human or another tool to inspect and control them.