2018 - A Look at What's Coming

2018 is upon us, and boy, do we have an exciting year planned. 2017 was a year of growth. This year we're looking to accelerate that growth, mature our offering, expand our business, and build out our vision of simple, powerful infrastructure management. Here's a preview of what's coming.

Nanobox API & Rebuilt Dashboard

Since we first launched, the Nanobox dashboard and the underlying system that powers it have been a single, integrated application. This architecture allowed us to get up and running quickly, but the tight coupling of front and back-ends has proven to be a bottleneck as we've grown and have needed to add new functionality.

At it's core, Nanobox is a "sequencing engine" – a system that automates the running of sequenced tasks and sub-tasks. Everything from creating a new application and deploying code to monitoring and scaling is simply a sequence of tasks that Nanobox runs and manages for you. The inclusion of UI elements in the sequencing engine gives it multiple responsibilities; something we're not a fan of.

We are in the process of removing all front-end/dashboard code from the sequencing engine and are building out API endpoints for all dashboard functionality. The dashboard is being rebuilt in Elm and will be a standalone single-page application powered by the Nanobox API. This transition will be complete in Q1 2018 (definitely sooner than later) and will help us to more quickly and easily add new functionality to the Nanobox dashboard and the sequencing engine/API.

The Nanobox API won't be for internal use only. At some point this year, we will release API documentation that will allow any Nanobox user to integrate directly with Nanobox. This will open up endless possibilities for both you and us. Needless to say, it's something we're excited about.


Many account upgrades have been long-advertised, but not offered. Currently, the only available upgrade is "Scale," which allows you to scale your apps and their components beyond a single server. By the end of Q1 2018, we're looking to make the "Monitor" (monitoring and alerts), "Automate" (auto-scaling), and "Protect" (data redundancy) upgrades available as well. These upgrades all build and depend on each other, which is partially the reason they haven't been made available yet.



The Monitor upgrade will provide active monitoring of your apps and their components and alert you if certain thresholds are crossed.


The Automate upgrade will let you define logic that triggers scaling actions based on application and component metrics. You'll be able to configure logic to proactively and reactively scale.

Let's say, for example, you have consistent, predictable traffic patterns at particular times of the day. You'll be able to define logic that will add nodes to your web cluster to preempt an increase in traffic, then remove them when that traffic typically dies down.

You'll also be able to configure scaling logic based on server resource consumption. If a server or component crosses a RAM threshold, you can tell Nanobox to scale to a larger server or add more nodes. If it falls under another threshold, you can tell Nanobox to scale it down. All in all, the manual oversight and scaling will go away and in many cases, you'll be able to set it and forget it.


The Protect upgrade will allow you to run redundant data services with Nanobox. Data is hard... and many services avoid it. But handling production data is something we've been doing for a while and are comfortable with. The biggest challenge with any redundant data service is the process by which data is replicated and data integrity is maintained. Any data service that provides replication and clustering functionality has their own method of doing it and they're all different.

Over the last few months, we have successfully engineered a way to replicate data without service-specific functionality or cluster monitors/arbiters. I'd love to give you details, but to be quite honest, I don't know the details :). What I can say is that replication happens on the disk layer rather than the service layer, making it a universal replication solution.

This new method of data replication simplifies the process of creating custom images for use with Nanobox and paves the way for fully-automated migrations between providers. More on those later.

Multi-App Servers

The ability to deploy multiple apps to a single server is the most requested feature on our roadmap and for good reason. A lot of apps simply don't need their own server. This functionality is already in the works and we plan on making it available in either Q1 or Q2 of this year.

While the request has been for multiple apps on a single server, we’ve architected it in a way that will allow you to do that and spread multiple apps across a shared server cluster. Components can be scaled horizontally across the cluster with nodes/containers on different servers. This is all made possible by a significant shift in our defined application "boundary."

Applications vs Networks

The deployment world, and more specifically the Platform as a Service (PaaS) world, has been built around the idea of launching and deploying "apps." Due to our history in the PaaS world with Pagoda Box, Nanobox was architected under this same assumption, housing everything neatly in self-contained apps, each with their own private network.

We've since realized the "app" boundary is completely arbitrary and unnecessarily limiting. There is no reason that multiple "apps" can't live within the same private network, and soon, we'll be shifting away from the unnecessary "app" boundary and moving to the more flexible "network" boundary.

What does this look like? Well, we're still figuring it out, but rest assured, when it's done, it'll be awesome. We're also discussing nomenclature, so the terms "app" and "network" may change, but I'll stick with them for now.

What does this mean? It means you'll be able to do some really cool things. Multiple apps can be deployed in the same network. Apps within a network will be able to share components. Shared, scalable databases managed with Nanobox, everyone! Hallelujah! This will provide a solution to the much-requested support of multi-headed, single-backend applications (also known as "Hydra Apps"). Networks can and do span multiple servers, but they will also be able to span data centers, which means your apps will be able to as well. Yeah... it'll be awesome. There are other perks as well, but we'll save those for another time.

Build Pools

One of the many interesting pieces of data we've collected over that last year is that only about 50% of Nanobox users ever download and use Nanobox Desktop (the Nanobox CLI). This is especially surprising since Nanobox Desktop is the only way to build and deploy to live servers using Nanobox. When we began to ask users why, the answer was simple. Many like their local development setup and don't want to change.

We realize that developers want and should be able to deploy using Nanobox without having to download and install Nanobox Desktop. The only thing that currently prevents this is that builds happen locally (or on a CI server). We're happy to say that at some point in 2018, we will introduce "Build Pools" – servers provisioned on your provider account that will build, compile and deploy your code.

Build pools will be optional and can be configured in different ways. You'll be able to have a single-server build pool or a clustered build pool for concurrent builds. You'll be able to specify whether you want build servers to persist between builds or be strictly on-demand, provisioning a build server for each build then shutting it down when the build is complete.

Build pools will lay the foundation for some really interesting deploy pipeline possibilities, many of which we're still exploring.

Automated Deploys from Github & Others

Build pools will also introduce the ability to automate code deploys from Github, Bitbucket, or any other source control service. Each app will have a "source" configuration (name pending) that tells Nanobox how and where to get your code. Depending on the integration, new commits, merged pull requests, new branches, etc., will trigger a deploy. As long as there's a boxfile.yml in the root of your project, Nanobox will have all it needs to build and provision your infrastructure.

New Nanobox Desktop

Work on a new version of Nanobox Desktop has already begun and we're really excited for it. The current version works, but is limited by architectural decisions made early in its development. The new Nanobox Desktop is built from the ground up to improve stability, modularity, testability, and extensibility.

We're also changing the way code is deployed to live servers. Currently we build and compile your app/runtime into a compressed tarball which gets rsync'd up to your app's warehouse and distributed to web/worker containers/nodes. Depending on the size of your application, especially those with large dependency libraries (I'm looking at you, every Node.js app ever), the sync process can take a while.

We've prototyped a new deploy method that, rather than packaging everything in a tarball and rsync'ing it up, compiles your code and runtime into a Docker image which gets pushed to your live app using the Docker sync process. In our early tests, this process has proven to be much faster.

Simplified Images

Many have been waiting for documentation on creating custom Docker images for use with Nanobox. It's been on our to-do list for a while, but we've been putting it off in lieu of a significant change in requirements for Nanobox images. This change is coming thanks to the newly engineered method of data replication and migration mentioned above.

Every Nanobox image includes "hooks", scripts that tell Nanobox how to perform specific tasks for the service. As an example, you can check out the Postgres hooks here. The complexity comes when writing hooks for data migrations and data redundancy. The new data replication model (on the disk layer rather than the service layer) removes the need for the majority of these hooks and drastically simplifies the requirement for Nanobox-specific images. Once everything is in, we'll release the documentation and you'll be able to create custom images to your heart's content.

New Data Services

The simplified image requirements will also allow us to quickly release official support for other data services such as RabbitMQ, Minio, MariaDB, and others listed on our roadmap. Development of new services has been put on hold in lieu of the simplified image requirements, so once they're out the door, you can expect official support of other data services to roll out quickly.

New Provider Integrations

2017 was definitely a big year for Nanobox provider integrations. In 2018, we're looking to expand our offering of official integrations with services like UpCloud, Alibaba Cloud, Hetzner, and others listed on our roadmap.

Provider Migrations

One of our goals with Nanobox has been to "commoditize the cloud;" to make your decision of cloud provider less important; to allow you to base your decision on price and service rather than ease of use. When choosing between providers, dev teams today have to account for the time it will take to launch and configure servers, how deployment will work, what networking looks like with each provider, etc. Since Nanobox takes care of all that for you, these concerns don't really matter.

In an effort to make your decision of cloud provider matter even less, Nanobox will soon allow you to migrate entire apps (code, data, and all) to an entirely different provider. Don't like the provider you're currently on? Click a button in your dashboard and we'll move you to another one.

New Front Site

For a while now, we've had a hunch the message communicated on nanobox.io hasn't been quite right. Well, we now have data to back it up.

There has been a lot of confusion about what Nanobox is and what it does. Some visiting the site went away thinking it was only a local development environment comparable to Vagrant or Docker Compose. Others saw it as a Kubernetes "me-too." Some even thought it was a cloud-based IDE. Needless to say our messaging has been off and in desperate need of adjustment.

As we've interviewed customers, we've found the true value of Nanobox lies in the simplified production management it provides. Resoundingly, the main selling point for customers has been how easy Nanobox makes it to create and manage high-availability, production infrastructures on any cloud provider with little to no expertise. Deployment and local development functionality are nice-to-have's, but they aren't as important as the current site makes them out to be.

Keep your eye out a newly designed nanobox.io with an updated message that focuses more on production management and leaving the hard stuff up to us.

Onward & Upward

So as you can see, we have our work cut out for us in 2018, but we're excited for everything that's coming. Thank you again for all your support. This is going to be a great year! Happy Nanobox'n!

- The Nanobox Team -

Posted in Nanobox