I have used elastic beanstalk in the past, probably most recently at CondeNast when I was working on a syndication platform in Clojure (:heart:). At the time we used ElasticBeanstalk in a pretty hands-off way. Our magical tool would package the clojure code, push the uberjar into S3, create an application version, and deploy that version to our staging system.

Once on the staging system, we would use the eb console UI to deploy it to production.

I remember being told about this by my good friend, and fantastic engineer - Tim Ramsey - and I initially thought that all deploy systems should be completely via the CLI. After working with this pattern, I do quite like the workflow where code changes can be pushed via scripts up to staging. The transition from staging to production is a different sort of beast, and now I like the forced break between coding and deployment. It feels a slight bit safer than letting me, in my impatience, do something like

  deploy stag && deploy prod

We ran elastic beanstalk wonderfully for a couple years, using worker tiers and SQS as well as standard web servers. It has been a simple thing to manage and scales well.

In the meantime

In the meantime I worked on a few other systems, some running capistrano, some going with the bleeding edge of kubernetes. I started working on a consulting contract and needed a few webservices brought up, with associated databases on RDS. I figured I would give elastic beanstalk another try.


I had wrestled with how to deploy things in a previous engagement which was trying to build something like heroku, on k8s, but with some twists. In that time I started to have a few opinions grow on my around how a deploy pipeline could work. When I came back to eb in the last few days, I was surprised to find that many of the features I had considered ‘missing’ from eb before, were now present. What a treat.




init sets your local repository up, pointing at an elastic beanstalk environment. I was able to create the environment in the UI (a lot easier for me than via a CLI) - and provision it with a sample application. When I ran eb init in my code repository, it asked a few questions, and then provided me a list of eb environments I could link with this repository. Easily looking up the context based on my AWS access keys. Wonderful. That was easy.


This command is doing all the work that the clojure lein beanstalk plugin was doing (mostly). It seems to just package the latest version of your code, push it on S3, and deploy it. And deploys on eb seem to have sped up (or maybe my expectations were too low) - but many times, I would be shell’d into the ec2 instance, and in one tab I would run eb deploy, and by the time the code was pushed to S3, I could hardly switch tabs, and cat the /var/logs/eb-activity.log in time! Pretty spiffy.

Speaking of ssh…


ssh is so great. It’s going to open an ssh shell into on of your running instances. No more finding the instance to get it’s public DNS and then running ssh ec2-user@.....

eb ssh simply jacks you in to the running instances. FTW. How nice.


I’ve only scratched the surface of what ebextensions brings me, but it lets you modify the instances - sortof like a poor-mans puppet/chef - to add packages, or run scripts on startup. Since everything in elastic beanstalk can be redeployed from scratch (rebuilt), when I make changes to those files and redeploy, I can feel pretty confident that if I “rebuild environment”, I will consistently have the same environment. The scripts and packages all get installed. How nice! That is a great improvement (in my mind) over some of the ways Heroku makes you work things or on EC2 having to establish your own AMI and maintain it.


I specified in the UI that I wanted a PG RDS instance, selecting the smallest I could for the moment. It was brought up for me and the ENV vars were exposed. I had a little trouble when my password generator added a % into the password. Try to avoid those things! The Ruby DataMapper library (or something inside it) seemed to get confused on that when I put it into the postgres connection URL.

You can clone environments in elastic beanstalk too - so once I had set up my staging environment, I just cloned my production environment (and set a new db password!).


Pretty impressed. For the size of projects I will be running, this seems like a wonderful sweet spot between Herkou and a raw EC2 instance.