Skip to content

Jaggies Weekly

The Twelve-Factor App: Admin processes

Dev, Architecture pattern, The Twelve-Factor App, English1 min read

Run admin/management tasks as one-off processes


Besides the app's regular business processes, developers frequently need to perform one-off administrative or maintenance tasks for the app, such as:

  • Running database migrations;
  • Running a console to run arbitrary code or inspect the app's model against the live database;
  • Running one-time scripts committed into the app's repo (e.g. php scripts/fix_bad_records.php)

Those tasks should operate within the same environment as the regular long-running processes of the app. They execute against a release, utilizing the identical codebase and configuration. Moreover, to prevent synchronization issues, the code must be shipped alongside the application code.

All process types should employ the same dependency isolation techniques. For instance, if the Ruby web process utilizes the command bundle exec thin start, the database migration should also use bundle exec rails db:migrate.

The Twelve-Factor app strongly advocates for languages that offer a built-in REPL shell, simplifying the execution of one-off administrative scripts. During development, developers can run these scripts by accessing a local console within the app's container. In a production deployment, developers can access the app's console via SSH or another mechanism provided by the execution environment, and then execute the script.

This Twelve-Factor App post series is a means for me to consolidate the knowledge I've gained while studying these rules. Please feel free to visit the site for more detailed explanations. That's all folks!