The aggregate HN community seems to be reacting pretty negatively, but I see a lot of value in high-level "magic" tools (like this and Otto) that abstract away configuration for developers. While everyone else commenting is likely more experienced and thus feels more comfortable setting up the required config files, I am still a relatively novice web developer. Tools such as Nanobox and Otto provide a way for people like me to start using the right dev environment management processes without being overwhelmed.

You hit it right on the head. We realize that this tool isn't going to be for everyone, but it will definitely help others. We're trying to make it so that developers don't have to worry about configuring an environment and just focus on coding.

Even an experienced developer could benefit from this if they don't want to take the time to configure environments.

I think it's great what you're doing to reduce friction for developers.

I don't think people want to take time to configure environments. It's just that we've all been bitten by environment configuration and sometimes configuring it in a specific way matters.

I don't think the tool is for me, as it feels like too much of an opinionated framework.

However, I really appreciate you open sourcing it under a permissive license, as I can see myself using some of your shell and go scripts in the future.

Thanks.

Yes, I agree that setting up dev/live environments needs to be simpler. As even for experienced devs, it is awfully time consuming and the entire process is not streamlined. The advent of Docker have made the process slightly better but it brought other complexities yet to be resolved (deploying local environment's volumized code-base, etc). I checked out Nanobox and liked the concept but I do get the feeling it is "yet another Docker builder" with it's own build file.

I've learn how to setup everything to develop NodeJS apps and I still hate it. I wish I had nanobox a month ago when I was setting up a new machine against a tight deadline.

Then learn Chef/Puppet or something like that and write/reuse recipes to install and configure whatever you need to configure.

I haven't set up an environment manually in a few years: I simply have my own recipes for the types of apps I'm developing in Chef (most of them just minor tweaks or config changes over existing recipes), my own vagrant boxes (I like different flavors of linux for different types of apps) and so on.

Starting a new project implies choosing the necessary recipes, adding them to a vagrant file, 'vagrant up' and wait a few minutes until everything is set up. Done.

Believe me. We share the same sentiment about setting up almost any environment, so we thought we'd bite the bullet and do all the work for you, so you don't have to :)

It's a bit disingenuous to list a bunch of languages (along with custom logo icons) that are _presumably_ supported by nanobox, only to force visitors to drill-down one-by-one to discover that only one out of three have any support at all, and the others are just placeholders saying "please contribute".

On the positive side, I guess it is better odds than a state lottery.

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 php part has almost no content. Im also concerned that the custom builds are not documented, its easy to build a dev env with half a dozen rpm files thrown in, but when it comes to getting all your custom extensions etc added thats a bit harder and we cannot judge that as of right now.

There's currently only one php engine, other than the generic php engine, listed on https://engines.nanobox.io/languages/php. However if you look at the generic php engine docs, there's a lot of content: https://engines.nanobox.io/releases/3b30f069-bb16-4f1a-9c36-.... And even more in the Advance config options included in the nanobox-engine-php repo: https://github.com/nanobox-io/nanobox-engine-php/blob/master...

Hey, I typically browse with javascript turned off. Your site is a blank page for me.

Perhaps if they dropped the opacity on the yet-to-be supported language icons? With that said, though I'm not a huge fan of the tool itself, I do really like the site design. Great job, it definitely kept me looking around and interested in reading further.

I am skeptical about this tool because I feel like the learning surface underneath will actually be massive, but massive in the wrong direction toward someone's idiosyncratic product.

In order to give me confidence that I won't have to look underneath the surface too much, I'd want to know that the abstraction is very airtight, but all appearances say otherwise. Like another commentator said, I'd rather have an app with well-defined boundaries.

Yep, I don't get this whole trend. Want to start a virtual machine? Use docker-machine. Want to start a bunch of services? Use docker-compose. Want to define the service stack? Use a Dockerfile with the predefined language stacks.

Previously we used to write hundreds of lines of puppet/chef/whatever scripts just to set things up. Its all already boiled down to just a few lines of configuration files. With tools like this or otto, its getting further hidden into nothing, seeming to look almost like magic. I'd rather stick with the few lines that I can control.

Yes, nanobox will try to auto-configure your environment for you. If you would rather define your environment or if nanobox can't auto-configure your environment, you can either:

1- Explicitly define your app's environment with the Boxfile (https://docs.nanobox.io/getting-started/boxfile/)

2- Write your own engine that will actually setup the environment (https://desktop.nanobox.io/engine-dev/).

Interesting, but this is too much of a framework for my taste. I prefer to work with independent tools with a well-defined boundary, so that I can change them at will.

Agreed. This sentence especially makes me think this is too much magic:

>Nanobox detects your app type and automatically configures the environment and installs everything your app needs to run

and

>Each Engine sniffs the code looking for a positive match to determine which language / framework your app is written in

and lastly:

>The matched Engine generates a Boxfile defining the services your app needs to run and how each should be configured

This sound quite fragile imo. No specs or configuration, it just guesses what all my deps are, and how to configure redis,mysql, and "other data-specific services" etc.

So an enourmous abstraction over everything except my source code with no configuration and a promise to "take care of everything" and forcing me to use their pipeline. Hm...

You're right, not every scenario can be handled automatically. For that reason, the Boxfile is king: https://docs.nanobox.io/getting-started/boxfile/

>> Nanobox detects your app type and automatically configures the environment and installs everything your app needs to run

Yeah, that's gonna be a bit hard for it to do with our Clojure web app. Well, maybe. If it knows to install openjdk-7 and nginx because it sees a project.clj, then perhaps it really is as smart as it thinks it is.

.. or immutant or jetty or .... Buildinng a simulated production environment on the dev machine is hard because in production, there are (in most cases) special settings, special servers, special configurations, special files on special places, ... It is rarely out of the box configured service stacks.

Auto-detections is based on the existing library of engines, which is only in its infancy right now. Engines have what's called a "sniff" script. This is a bash script written by the engine developer that searches the codebase for uniquely identifying files or content within files. Auto-detection won't work for every app, but it should help to get the majority of apps up and running quickly. For very custom apps, anybody can develop and publish their own engine. Information about engines is in the nanobox docs: https://docs.nanobox.io/engines/

Note: this is exactly how buildpack detection on heroku - and anything that uses buildstep/herokuish for PaaS solutions - work.

the target audience for the tool?

While I don't think your tool is for everyone your site design is. Love the colors and clean design, goes a long way towards making me want to understand Nanobox.

Also a big dan of the design but I do find it to be much too dark, I'm in a well lit office, with a calibrated Dell UltraSharp display and the site's color scheme is really quite hard on the eyes, even if the design itself is beautiful.

_Ars Technica_ and Heroku, two sites that catered to the tech ninja videogamer-brogrammer demographic, both spent a lot of effort work walking back their light-on-dark visual identities when it was time to join the grown-ups.

_Ars_ addressed this issue in the FAQ for their 2004 redesign:

http://arstechnica.com/uncategorized/2004/10/redesign/

> Q. Why the white? Oh my eyes!

> A. Believe it or not, many people cannot read the "black" version of the site. This has been the #1 complaint Ars has received since day one. We thought it unwise to continue to use a default color scheme that was driving so many users away. Once it was clear that we could support both, we did, but white will be the default. The black design was also unfavorable to readers in corporate environments, and other places where the scheme sent the wrong signals to bosses and cubicle neighbors.

What makes it different from https://ottoproject.io ?

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.

And again dependency on Vagrant and Virtualbox. What can you do.

On every modern Ubuntu (even previous/old LTS) Docker works out of the box, without any issue.

Why add another virtualization layer on top?

To work with other operating systems?

Then why not have it optional?

I have a Dockerfile that I use to run my production. This is already built.

Is there anything I can use to build a local dev environment quickly using the Dockerfile. Obviously I can use docker, but quite often new developers have trouble with docker.

Yeah, I've been trying to streamline this too. Have yet to find a good way to do local development inside docker. The best approach so far I've found is that I have my db, redis, and other services like that running in docker. My application is checked out locally and configured to hit the docker services.

Why not docker-compose[1]? One thing it does well is abstract docker commands to `docker-compose build && docker-compose up`.

[1]: https://www.docker.com/docker-compose

Docker Compose depends on a bundled copy of OpenSSL that has been insecure since June: https://github.com/docker/compose/issues/1601

our production is built using docker-compose. But it is still not as easy for a developer to get started using docker-compose and be as effective as installing the code on his desktop.

I know I'm nitpicking here, but it would be great to have an abstraction on top of Dockerfiles that make it possible to develop in a near-production environment.

You can use Lattice for that: http://lattice.cf/docs/

thanks for that. lattice seems overly complicated for a developer machine usecase. I might as well do Docker.

Can't see the letters, sorry. Not everyone is sitting in a dark room.

I am sitting in a dark room, with a high-contrast IPS screen, and still can barely read anything.

That said, the colors really are beautiful. At least, what I can see of them. Excellent color palette! I'm a sucker for softened tones like these.

Seems to be the solarized colour palette (or was inspired by it, at least): http://ethanschoonover.com/solarized

Looks fancy, but boy is it bad on the eyes. I've since switched away from it to harlequin ( https://github.com/nielsmadan/harlequin ).

I used to use Solarized but switched to Zenburn since then in my editor. That said, whatever color scheme they're using on that website looks really nice on the website, even if I wouldn't use it in my editor (I might though!)

Assuming this works perfectly well, all the time — this is awesome. A possible pain-point this is addressing is that apps behave differently locally and then when you move them to the cloud (aka deploy them) they behave differently.

Full disclosure: I work for Nanobox. We're prepping Nanobox Cloud for release likely in 2016 https://nanobox.io/cloud/. With Nanobox Cloud, you'll be able to take the exact same environment configuration you have locally and deploy it to a cloud provider (starting with Digital Ocean but others will soon follow). The same engine used to run your app locally will be used in the production app. The whole workflow has been designed to provide parity between development and production environments.

How can I pay you for this?

Note — I know many might disagree, because of very valid points, but for me personally, deployment is a nightmare. I really have no clue how that works. I didn't know SQLite3 (being file-based) needed special permissions on the .db file to be able to avoid an OSError, and the folder containing the file needed other permissions. The whole absolute-path-in-server-but-relative-will-work-locally, blah blah — This is really a irritating business for me.

Deployment ideally should be like —

$ sometool deploy myAwesomeApp

$ Enter <some-sort-of-username-for-server> — myServer

$ Enter <some-sort-of-password-or pem key location> — ••••••••••

$ Deploying...done!

$ Your app is live on YOUR-SERVER-IP

Too far off for many. Many might hate it, but trust me I personally know atleast 50 other developers who would benefit from a setup like this. Mostly people learning how to code, who just want to put their simple apps out there.

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).

Thanks for the feedback. You might want to keep any eye on Nanobox Cloud (https://nanobox.io/cloud/).

What's your take on Nix/Guix vs containers/virtual machines for setting up development environments? (note that the former also support containers, but they provide a very systematic way to manage dependencies)

It's an odd comparision, because Nix and Guix both include tools for making virtual machines and containers. I think the better comparison would be virtualizing/containerizing traditional distributions like Debian vs. using Nix/Guix.

With a traditional distro, you need to use a handful of additional tools like Vagrant, Docker, Ansible, etc. as well as several additional package managers to get everything setup. With Nix and Guix, you use a single package manager and single suite of tools to provision local environments, with or without virtualization. Those environments are declarative, reproducible, can be rolled back, etc. It's a much cleaner way to work.

I have read about half of Eelco Dolstra's Ph.D. thesis [1]. I wish all distros worked like this. I had never heard of Guix before and was about to ask how it relates to / differs from Nix, so if anyone else is wondering:

Guix:

    Specializes in providing exclusively free software.
    Based on Nix [2].
    Implementation differences, quoted from section 2.3 in [3]:

"Our main contribution with GNU Guix is the use of Scheme for both the composition and description of build processes, and the implementation of build scripts. In other words, Guix builds upon the build and deployment primitives of Nix, but replaces the Nix language by Scheme with embedded domain-specific languages (EDSLs), and promotes Scheme as a replacement for Bash in build scripts. Guix is implemented using GNU Guile 2.0 2 , a rich implementation of Scheme based on a compiler and bytecode interpreter that supports the R5RS and R6RS standards. It reuses the build primitives of Nix by making remote procedure calls (RPCs) to the Nix build daemon. We claim that using an embedded DSL has numerous practical benefits over an independent DSL: tooling (use of Guile’s compiler, debugger, and REPL, Unicode support, etc.), libraries (SRFIs, internationalization support, etc.), and seamless integration in larger programs. To illustrate this last point, consider an application that traverses the list of available packages and processes it—for instance to filter packages whose name matches a pattern, or to render it as HTML. A Scheme program can readily and efficiently do it with Guix, where packages are first-class Scheme objects; conversely, writing such an implementation with an external DSL such as Nix requires either extending the language implementa- tion with the necessary functionality, or interfacing with it via an external representation such as XML, which is often inefficient and lossy. We show that use of Scheme in build scripts is natural, andcan achieve conciseness comparable to that of shell scripts, but with improved expressivity and clearer semantics."

From my limited view, Nix has a very strong theoretical base. Do you expect any developments at that level, and do you think these hypothetical developments will be integrated by the developers of Guix, or might it at some point start ignoring improvements in the theory?

[1] http://nixos.org/~eelco/pubs/phd-thesis.pdf

[2] https://en.wikipedia.org/wiki/Nix_package_manager

[3] http://arxiv.org/abs/1305.4584

>From my limited view, Nix has a very strong theoretical base. Do you expect any developments at that level, and do you think these hypothetical developments will be integrated by the developers of Guix, or might it at some point start ignoring improvements in the theory?

I don't anticipate any major changes in the theory, but if there were improvements made, Guix would surely want to implement them. In general, we take things like build reproducibility further than Nix does. There are many packages in nixpkgs that use pre-built binaries rather than building from source. Guix also has tools to allow users to publish their own binaries for others, and also provides a tool to compare locally built binaries to remote binaries to detect non-determinism or security compromise.

Does anyone know what the endgame for this software is? Does Nanobox plan to offer a more premium service in addition to the basic functionalities? Hashicorp makes some revenue from premium services and I cannot imagine a tool this polished being sustainable without some sort of revenue source. Just asking, not a criticism.

We hope to keep the nanobox desktop tool free and open source. We plan on offering a "cloud" version of the tool (https://nanobox.io/cloud/) that will use nanobox desktop to help streamline deploying production code to a provider of your choice.

Thanks Steve. After looking into your company a bit it's clear that you all have been building your infrastructure to support PagodaBox for some time. Thanks for open sourcing so many tools https://nanobox.io/open-source/ . I had never heard of anything you all made until today.

DigitalOcean and Linode? Want!

To save everybody some time, here is a list of the runtimes and frameworks actually supported by nanobox:

  - ruby 1.9, 2.0, 2.1, 2.2 / jruby 1.6, 1.7, 9.0
  - node 0.8, 0.10, 0.12 / iojs 2.3
  - python 2.7, 3.4
  - php 5.3, 5.4, 5.5, 5.6
      - wordpress (version unknown)
  - java openjdk 7, 8 / sunjdk 6, 7, 8 (no minor version information available)

The actual content on the "Engines" page is aspirational, to say the least. One of the first question I ask of a tech product is "is it usable today for any current projects?" - why make this question challenging for site visitors?

If they're targeting novice web developers who should follow best practices, no rails support and out-of-date node support seems like a bad place to start.

Posted this answer to a similar question/comment:

---

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.

Aspirational is great, but I would suggest you update that page to clearly identify what is currently supported versus what is aspirational. There is probably limited overlap between your target user audience and your target collaborator audience.

I think you're right. Thanks for the advice!

seems interesting but I started clicking around, specifically in the Python section and this website seems to have been released too early, the text I am not sure is right(it says I need to use a ruby engine settings for python?) and some links don't work or give 404.

Yeah, if anyone from nanobox is reading, I found a broken link on the Node.js Engine page:

On page https://engines.nanobox.io/languages/nodejs the link for Create Custom Engine leads to a 404 on https://nanobox.io/engine-dev

We will get that fixed asap. Thanks for letting us know

Later it says you can specify which JS runtime to use with python:

  build:
    runtime: python27
    js_runtime: nodejs-0.12
    app_module: ''

The js_runtime is included because of the ubiquity of using tools like bower and gulp to compile assets, which require node.

That one's not unreasonable.

It seems I can't also specify a ruby runtime, though. What makes one reasonable and another not?

The mention of ruby in the description is a typo. There isn't a ruby runtime available in the generic python engine, but you're free to fork the engine and add the ruby runtime. All engines are open-source.

Thanks for the heads up! Please keep in mind this is an open-source project in the pre-beta phase. Any contributions are welcomed!

I develop in OSX, Vagrant is entirely too much overhead and hurts more than it helps. It's less work to make the app work cross-platform than to have to deal with the slowdown and the added tool complexity.

The only overhead I notice is the fact that VirtualBox Shared Folders are really slow. If that's the case, using the paid VMWare plugin can help.

Or use NFS. Way better performance.

NFS will be the default adapter for nanobox, but can be disabled.

I just see a blue wall with a logo at the bottom on Edge or IE 11.

This is an issue we just became aware of. Working on a fix as we speak.

Beautiful website. Really. The colors are exquisite.

Magic engine detected Rails 4.2.5 app as nodejs...

There currently isn't a Rails engine so rails won't get auto-detected yet. The nodejs detection is listed in the New column on their trello board: https://trello.com/b/4nVFzmNZ/nanobox-desktop

Looks like it never got added as an issue on the nanobox project. I'll do that now.