Nanobox supports multiple languages and we're working on rolling out support for more. Elixir is one we're really excited about. There isn't really any good, standardized support for Elixir deployments, but Nanobox is a huge step in that direction.
It's definitely a tricky balance. Ultimately there's best practices to follow, and there's no need to manually implement best practices in every project if you can automate it. The balance is between time-saved vs absolute control.
Nanobox tries to strike the balance between saving time and giving devs ways to hook into and control the dev-to-production lifecycle.
Core Nanobox team member here. A brief history of how Nanobox came about. We are a small team of developers who were doing a lot of medium to large-ish web applications and found ourselves having to do the same, tedious tasks over and over when deploying apps to production servers. So we built Nanobox to automate the process, save us time, and preserve our sanity.
One common mistake is thinking that you need a fully-fleshed-out dataset with real data. You don't. You just need the bare-bones structure with some generic data, which can easily be accomplished with a seed file. Django calls these fixtures: https://docs.djangoproject.com/en/1.10/howto/initial-data/.
Once the initial data is seeded, you then just need to implement migrations to update the database as the structure is modified. These too are already built into Django: https://docs.djangoproject.com/en/1.10/topics/migrations/.
With those in place, every developer can have their own local environment with its own database. I personally use Nanobox (https://nanobox.io) to spin up dev environments with local databases. I then can console into the environment, run the seeding process and any migrations I need too. You just need to set up a version control workflow to keep everybody's codebase in sync.
There's a lot of services out there help to alleviate many of these. Companies like Heroku, Codeship, Engine Yard, etc. One of the newest services to hit the scene is Nanobox (https://nanobox.io).
Nanobox will build both development and production environments using docker containers, but it automates the deploy process, sets up all the networking, locks everything down with firewalls, sets up a load-balancer, health monitor, messaging system, then provides a dashboard that lets you introspect into your app's performance (at least for live apps). Locally it lets you configure your entire environment from a single config file, much like docker-compose, but different.
Artists pull inspiration from things they're familiar with, both then and today. Travel in Medieval times was challenging, causing people to generally stay where they were, limiting their view of the world.
I'm sure these artists had only heard descriptions of elephants from the few that had travelled and actually seen an elephant. They then referenced things they knew are were familiar with in northern Europe: wild boar, trumpets, etc.
I find this interesting that people are looking for cheaper alternatives to Heroku and completely agree that Heroku gets expensive fast, especially for hobby sites. But one thing to consider is the value that Heroku provides.
Heroku automates the provisioning and configuring servers, deploying code to those servers, scaling servers, etc. It's more than just cheap hosting.
If you're looking for cheap hosting, there's tons of alternatives out there. If you're looking for cheaper alternatives that provide the same value, the search gets a little tougher, and understandably so.
I'm part of the core Nanobox team (https://nanobox.io). Members of our team were instrumental in introducing releases in Elixir and helped to lay the foundation for exrm.
Elixir deploys are currently functional, but we're working with the Elixir community to really fine-tune the process (including hot-code-reloads).
DigitalOcean has been supported for a few months now. AWS support was just released yesterday.
I'm part of the core team behind Nanobox and am more than willing to answer any questions. We're super excited to be out of beta. Feel free to check us out: https://nanobox.io
I love the section about the first idea is probably not going to be the last idea. I've seen startups come in with a very set idea of how the product was going to work, only to find that the way it was going to work wasn't really what customers were looking for.
Rather than defining how a product should work, startups should define their mission and adapt their product to both accomplish their mission and meet the needs/demands of the customer.
I've been involved in a few startups and this is what I've learned:
1. Iteration is key and should be welcomed.
2. Validation, as noted, is incredibly important.
3. Continuing to validate iterations ultimately leads to a successful company.
These are great. Something I've always found interesting is how often "looking to the future" campaigns harken back to decades-old iconic art styles. That's not a criticism. I love the juxtaposition of concept and style.
Side note: Am I the only one that sees the No Man's Sky reference in the Venus poster?
We (I work for Nanobox) listed all the languages we hope to support mainly as an invitation to collaborate. We admittedly do not specialize in all programming languages. Engines are open-source and those who do specialize are invited to create engines for each language. We'll even create the engine for you. We just need to know what the engine should look for and how the environment needs to be configured.
---
The library of engines is in its infancy and we're working to expand it. You're absolutely right in saying that the list of engines is "aspirational". Anybody can build and publish new engines. Any help you can provide would be greatly appreciated.
Thanks for the support. Nanobox Cloud is still a work and progress, but we are hoping to open up the private beta soon. You can sign up for a beta invite on https://nanobox.io/cloud/ (Just click "Sign up for the Private Beta" and submit your email).
We, like otto, see the need for tools like these in today's development climate. While both tools are very similar and accomplish nearly the same thing, the main difference is under the hood:
1. Nanobox embraces Docker and the philosophy of containers. Every component and process of your app is housed inside of an isolated container. The VM only runs the Docker deamon and the Nanobox deamon. In contrast, otto leverages Docker, but is built more to conform to Hashicorp's existing toolset.
2. Extensibility in Nanobox is accomplished through engines, which are inspired by and very similar to Heroku buildpacks. As noted above, engines run inside of isolated containers inside the VM. Otto's extensibility is accomplished through Go plugins that run on the host machine.
3. Nanobox caters to the dev workflow. We'll automatically suspend and save the VM state when it's not in use. Nanobox doesn't require the VM to always be running.
- https://news.nanobox.io/packet-now-officially-supported/
- https://docs.nanobox.io/providers/hosting-accounts/packet/
Their full list of officially supported cloud providers is here: https://docs.nanobox.io/providers/hosting-accounts/