On simple web applications, it’s common to talk about a “develpment server” which one starts before coding. Any rails developer is familiar with
rails s. It boots up your application and it’s ready to view on
your favorite browser. As applications start to grow, so do the number of processes that your application depends on. Using memcached? Make sure it’s running. Need background processing? Better start your background worker. Pretty soon, you have half a dozen terminal tabs open and you haven’t begun coding yet. There is a better way.
Procfile and Foreman
A Procfile is a simple text file in which you declare the processes that your application needs in order to be up and running. I first became acquainted with it when reading up on Heroku’s Cedar stack, which uses to assign different kinds of dynos (which act as processes) for your app.
1 2 3
In essence, this specifies two types of processes: A web process, which executes the rails server (using bundler) and a worker processes, which executes a rake task provided by delayed job.
After installing foreman, you can use it to start both processes at once, on a single terminal. You also get color-coded output for each process and the ability to stop them all at once (ctrl-c).
Sometimes, your heroku’s processes are not identical to your development processes. For example, in my app we use the Websolr add-on as a search server. In development, I need to also start a Solr server, so that all the functionality is still there. Therefore I have a different Procfile for development:
1 2 3 4 5 6
The above starts my web server, background processing queue, Mailcatcher (awesome tool for sending email in development), the Solr server (wrapped by sunspot) and Memcached.
Before I start a coding session, I start them all up with:
For foreman to work properly, the executable commands you pass to it should not automatically deamonize. (Which is why you see mailcatcher being called with the -f flag). Otherwise, foreman will start your processes, but will not be able to stop them.
I currently don’t use foreman to manage my database process, because all my projects use Postgresql and it is always running on my machine. However, if that changes in the future, I will definitely start using foreman for that as well, as described by Bryan Veloso.