When we started Risktronics, we really didn’t want to care about where should we host the app. Heroku seemed a pretty obvious choice, and in the end, the pleasure was all ours to use it and it was definitely a win… Well, at least for some time.
Our latest bill for Heroku was something we didn’t plan, at least not that soon:

The decision that followed was to move away from Heroku to an own server. All great, except the fact that this means we will have to change the way we were deploying the code and monitoring its health — things I didn’t want.
Below you will find the hooks I used to fire on a deployment using git. Beside detecting the Gemfile changes and running bundler, I really wanted a solution to restart/start the application on new commits.
We were already using foreman, and it’s great (solving problems like environment variables, sub-process spawning, master process), but in order to use foreman upstart integration, you would need root permissions or some other sudo magic. So for us, foreman has to live on a user level, and nginx should take care of stuff to proxy with it.
In the end, if you pre-set a port on which the app has to live, this should solve any other problems.
To recap, I eneded up with something like this, on every commit I make (including Gemfile changes):
Counting objects: 2347, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (1775/1775), done.
Writing objects: 100% (2347/2347), 330.17 KiB, done.
Total 2347 (delta 1533), reused 879 (delta 526)
remote: Master branch changes. Starting the deployment...
remote: Gemfile updated...
remote: Running bundler...
remote: Using rake (0.9.2.2)
...
remote: Using bundler (1.0.21)
remote: Your bundle is complete! It was installed into /home/app/.bundle
remote: Sending TERM to 19934...
remote: Starting the app...
remote: HEAD is now at aa2a2 My last commit
To git@ourserver.risktronics.net:apps/risktronics.net
* [new branch] HEAD -> master
Pretty cool, eh?!





