Last Updated: 2024-04-18

To get my Rails app running along with all its dependencies in development, I used a Procfile.dev that looked like this:

redis: redis-server /usr/local/etc/redis.conf --port 6379
elasticsearch: elasticsearch
# Unimportant for present purposes
webpack: ./bin/webpack_dev_server
web: ./bin/rails server -p 3000
scheduler: ./bin/scheduler.sh
docservices: ./bin/docservices
worker:  ./bin/rake jobs:work

i.e. elasticsearch and redis were started here instead of with brew services start x, as is typical for these services. My motivation for doing things this way was that I wanted to notice their boot failures or logs right away when I started my software (instead of needing to rummage around for their logs).

This, however, was less than ideal. Elasticsearch took 20 seconds to start, which meant rebooting sucked. Whatsmore, by starting and stopping redis and elasticsearch manually from this location, this meant I wasn't running them as services, which, in turn, means that other environments, like seed and test, would throw errors if I didn't either create additional Procfiles for these environments (adding weight and boilerplate) or (as I actually ended up doing) resorting to the hackish solution of running the dev environment Procfile in other environments (e.g. test) in order to get them working.

Eventually I rewrote the procfile to use existing services but instead tap into their logs and display them in my terminal foreground. This let me retain my ability to be aware of logged issues in my software dependencies:

redis: ./bin/follow_with_syslog.sh redis-server
elasticsearch: tail -f /usr/local/var/log/elasticsearch.log

webpack: ./bin/webpack_dev_server
web: ./bin/rails server -p 3000
docservices: ./bin/docservices
scheduler: ./bin/scheduler.sh
worker:  ./bin/rake jobs:work