Replacing Bluepill with Systemd

Cloud 66 for Rails switching to systemd

For many years we are have relied on Bluepill to manage processes on the Rails servers we deploy, and it has done the job excellently. However, as both our business and our platform have evolved, we’ve come to the point where we need to replace Bluepill. We’ve chosen to keep things simple and transition to using systemd — Ubuntu’s default (and optimal) process manager.

Why are you changing?

We’ve been maintaining a fork of Bluepill for several years and, as frameworks and operating systems have changed, it has become increasingly difficult to maintain. Over the same period Ubuntu replacing their own manager (called “upstart”) with systemd, which is a much better process manager, and can handle everything that Bluepill currently does.

What does this mean for me?

First and foremost, existing applications DON’T need to change! We understand intimately that change can be a pain, and very disruptive, especially when not originating internally. You can of course opt to upgrade your existing servers at any time, if you wish.

No more daemonized processes

The single most important difference, from the perspective of a Cloud 66 user, is that our systemd doesn’t support processes that daemonize themselves — for example by starting a process with the -d flag. This is part of a long term move away from self-daemonizing processes. The new method is much cleaner and more reliable. Persistent processes are managed and kept running by systemd exclusively.

Migrating existing Rails Applications

NOTE: If you’re a new customer of Cloud 66 and joined us any time from June 2020 then this does not apply to you as your applications will already be backed by systemd.

  1. Check and update any of your config files that enable daemonization. This is particularly relevant for users with the custom web servers: Puma, Unicorn, or Thin.
  2. Set your application(s) to migrate to systemd either:
  • cx settings set -s APPLICATION_NAME true


If you’re currently using Puma as your web server you are probably running it using a command similar to this one:

custom_web: bundle exec puma -d
custom_web: bundle exec puma

DevOps-as-a-Service to help developers build, deploy and maintain apps on any Cloud. Sign-up for a free trial by visting: