Setting up a deploy system for Python apps on Ubuntu using Supervisor, Upstart and git
September 21, 2013
In the past, I’ve always deployed web apps and side projects to Heroku. But after being bitten by it one too many times, I decided to get a server on DigitalOcean and do it myself. It was surprisingly easy.
First, I created a user called
www-data and gave it a home directory of
/var/www/. Inside there, I created this directory structure:
.virtualenvs folder is used by
virtualenvwrapper to manage my environments.
myproject.git is a bare repository that I set up by following these instructions for git deployment from Jeff Hoefs. You can customize the
post-receive hook, for example to restart your web process. But first let’s get our process daemonized, so it’ll keep running if it crashes or the server restarts.
Supervisord is a Python-based process management system. It’s similar to Upstart, which is more generic. In fact, I use Upstart to make sure Supervisord starts on boot.
Upstart now ships with Ubuntu, so you just need to install Supervisord. You can install a pre-built package, or use
easy_install like I did. I prefer easy_install, because the code generated by the package is hard to modify.
$ easy_install supervisor
Here’s an example program specified in
/etc/supervisord.conf. By default, supervisord will start all your programs when it launches.
user = www-data
directory = /var/www/myproject
command = /var/www/.virtualenvs/myproject/bin/python main.py
numprocs = 1
stdout_logfile = /var/www/bus.log
redirect_stderr = true
I also created a small Upstart script called
supervisor (without the d). This lives in
start on runlevel 
stop on runlevel [!2345]
exec /usr/local/bin/supervisord --nodaemon -c /etc/supervisord.conf
That leads us to the last part, which is the modified
post-receive hook which will run your newly pushed code:
GIT_WORK_TREE=/var/www/myproject git checkout -f
supervisorctl restart myproject
Start running your supervisor as a service, if it’s not running:
Then check the status of your project:
$ supervisorctl status myproject
You can also use
supervisorctl to start, stop, or restart your web process manually.
And that’s it! My app is more reliable now, and deploying is still just a
While waiting for Backspaces to be reviewed by Apple, we decided to build and open source a component popularized by Instagram: live camera filters. If you’re curious, you can read about some of the motivation behind that decision in Dmitri’s post.
Open source projects aren’t usually praised for good design, and our initial versions looked like it. But I knew that we were going to launch this component very publicly, and decided to make some improvements.
As it turns out, I couldn’t find any resources online to make a mockup of the iOS camera. Even the excellent Teehan & Lax resources didn’t have a camera!
In the spirit of open source, I’ve created my own camera PSDs and released them into the public domain.
Download the files here
Included are the default iOS camera and the Instagram-like design for our open source camera, in retina and regular resolutions:
You should go to a hackathon. You’ll find out quickly if it’s something you enjoy. But if you do, I’d like to help make your experience awesome.
A typical hackathon looks like this: Form a team, come up with an idea, work all night, and finally, present your project. Most last 24 hours. Your goal is to build the best thing you possibly can, starting at the same level as everyone else.
My first hackathon was a year ago. I had no idea what I was doing, but I showed up, met some people, and built something fun. I had a similar experience this past weekend. In between, there were a lot of hackathons, but none as exciting.
What makes these two experience stand out from all the others?
First, the team. The ideal team has a person covering every role. I think four people is best. This past weekend those four people were two developers and two designers. At my first hackathon it was two developers, one person figuring out gameplay, and one person doing sound. The trick is to find a way to work in parallel. You will fail if you don’t.
Second, the idea. Somehow you should find an idea that you’re all excited about. With these two hackathons, we spent a couple hours talking over the possibilities before we found one that we couldn’t stop talking about. Then we spent more time planning out all the features that we needed to build, that would be nice to have, and that we definitely shouldn’t build.
Fake everything except what you need. Every unsuccesful hack I’ve made failed because we tried to do too much. No, don’t implement that registration system. No, don’t implement a RESTful API. No, don’t build your app with tools you’ve never used before. Your audience won’t care about those things, so don’t spend time on them.
I always focus on what a teammate once described as “the happy path.” What path would someone take to solve their problem? Build that, and the demo is easy. Last weekend we used the example of Ken, a potential user we talked to while coming up with the idea. Every part of the app makes Ken’s life easier, so we just had to explain how.
Everyone has a different reason they go to hackathons. Some go for competition, or to build something cool. I go for the people. It’s an opportunity to spend time really getting to know someone, to figure out what motivates them. It’s a community of people that inspires me to be better. I’m still friends with the team from that first hackathon, who have since started a company and moved in together. A hackathon is an opportunity, and it’s up to you to make the most of it.
See the discussion on HN