Thinking inside the box

We switched our entire development setup to and we’re not looking back. Here’s why.

Hi, my name is Jonathan and I have been with as a freelance front-end developer for the past 6 months. This week I am taking over the reigns from Harry to write a post about what I have been working on for the past three weeks.

Over the past year grew from a team of just 4 founders to a company of nearly 15. It happened organically but much fast than anyone had anticipated. To keep things running smoothly, we made the decision to standardize processes that were kept rather informal before.

A couple of weeks ago we decided that it was time to find a common foundation that all of our technical projects could share, because managing multiple development setups simultaneously got in the way of getting things done.

The inevitable code photo.

Yesterday’s cruft, today’s standards and tomorrow’s innovations form an ever-changing continuum of technological dependencies, that requires more time, attention and care than most people are willing to admit.

After having a close look at our current development process we came up with the following goals:

  1. Setting up projects locally should be as simple as possible. Ideally every developer should be able to get up and running within minutes.
  2. Even though most of our projects do not rely on heavy testing we wanted to have the flexibility to add more rigid tests later.
  3. Deploys had to become less stressful and time consuming for everybody involved. No more shuffling files manually via FTP.
  4. All of our projects should be able to scale with the client’s needs.
  5. All of our projects should include a backup strategy that keeps files and database records safe at all times.
  6. We are able to adopt new technologies on a project-by-project basis without having to rethink our overall deployment strategy.
  7. Our developers can focus on what they do best: writing code, not managing Docker swarms or setting up servers.

Naturally, I got very excited when Harry asked me to investigate Nanobox — a new tool that appeared to cover all these goals. It seemed too good to be true.

The video is a bit pretentious, but a good intro nonetheless.

At first, I was a bit intimidated — going from front-end developer to sysadmin was certainly not a career change I had anticipated. I am glad to say, that it was well worth it.

Within hours I had the first projects running inside nanobox, soon we were able to deploy to AWS, and just a few days later we have begun to migrate the majority of our projects to nanobox.

We now rely on a combination of Nanobox, Travis-CI, Github and AWS to run our projects locally, to test and build, to deploy and to host them. If all of this got you excited, keep on reading for the deep-dive — if not, just rest assured that your projects are in good hands.

Why are we using Nanobox?

Through virtualization Nanobox provides a unified development, staging and production environment for the majority of our projects. This has the following advantages:

  • Setting up a project on a local machine becomes a matter of minutes instead of hours. No more guesswork. “You hear me mcrypt!?!”
  • All developers work in the same environment. Making it easier to replicate and fix bugs across projects. “Oh, I totally forgot to mention that my local Apache has been roaming the Happy Hunting Grounds for quite some time.”
  • It allows our projects to run on fast, reliable and scaleable infrastructure (AWS) that would otherwise require the attention of a sysadmin — automated backups and instant-rollbacks included. “Need a server with 1952 gigabytes of RAM? We got you covered.”
  • Deploying a project becomes a lot less stressful when development, staging and production share the same configuration and the process is virtually identical for all our projects. No more “Let me just SFTP into the production server real quick. I think we forgot to update the database config — for the 7th time in a row.”

Nanobox also has the advantage that it is non-invasive. Apart from adding a handful of environment variables to already existing configuration files, there is no need to modify existing projects to get them running inside the box. Nanobox also does not make any assumptions about what other technologies you are using.

What are the advantages of using Travis CI?

Travis CI is a continuous integration service that we use to build and test projects managed on GitHub. It monitors the staging and production branches of any given project and automatically deploys them via Nanobox to different AWS apps whenever changes are committed. This has the following advantages:

  • Everybody who has access to the project on GitHub is able to deploy it without having to worry about its configuration just by merging changes into the staging or production brachnes. “Who needs M&A when you can M&D?”
  • No need to manually transfer or update files on the server after the initial setup is complete.
  • Most importantly: It allows us to use a vanilla copy of Nanobox with every build.

We used Codeship for continuous deployment before, but it doesn’t support Nanobox right now, its permission system is not based on Github and it doesn’t keep its configuration in the repository. All these boxes are ticked by Travis CI, which makes it the way to go for us.

Which role does AWS play in all of this?

Amazon Web Services provide on-demand Cloud Storage, Hosting and Computing. All our Nanobox projects are running on EC2 instances. This is what we get from using AWS:

  • It scales effortlessly according to our client’s needs.
  • Clients are more likely to know and trust AWS than any of the other hosting providers.
  • It is a breeze to connect to Nanobox and you never have to look at the AWS console ever again.

There is probably no need to mention what GitHub does for us.

And there you have it: We now run all our projects containerized, on easily scalable hosting, including trivial rollbacks, continuously deployed, well documented and featuring a super quick, consistent setup. All without changing our workflow and letting us focus on what matters: writing code and sleeping well.

Note: This article is not an advertisement or paid endorsement by Nanobox. We genuinely think their service is that fantastic and liberating. Give it a shot!

Indeed. is a nimble studio for strategy, branding and product development in Berlin, featuring a multidisciplinary team of designers, developers and strategists. We create tailor-made digital solutions with an agile mindset and a smile on our faces; seeing the bigger picture, as well as intricate details. You can hire us: let’s work together and make rad internet stuff! 🙌

Want more? We’re also on Twitter, Facebook, Instagram, Snapchat and we highly recommend our Tumblr. You could also subscribe to this publication to get notified when new posts are published! Phew. That’s all, over & out! 🛰