
Nanobox: Local development done right - numo16
https://desktop.nanobox.io/
======
jonathankau
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.

~~~
sdomino
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.

~~~
Glide
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.

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

~~~
sanderson1
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.

~~~
thawkins
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.

~~~
sanderson1
There's currently only one php engine, other than the generic php engine,
listed on
[https://engines.nanobox.io/languages/php](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-...](https://engines.nanobox.io/releases/3b30f069-bb16-4f1a-9c36-10ac20580799).
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...](https://github.com/nanobox-io/nanobox-engine-
php/blob/master/doc/advanced-php-config.md)

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

~~~
rdsubhas
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.

~~~
tylerflint
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/](https://docs.nanobox.io/getting-started/boxfile/))

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

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

~~~
thecopy
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...

~~~
sdegutis
>> 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.

~~~
fu86
.. 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.

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

~~~
codebeaker
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.

~~~
edw
_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/](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.

------
lucadom
What makes it different from [https://ottoproject.io](https://ottoproject.io)
?

~~~
sanderson1
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.

------
odiroot
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?

~~~
aeze
To work with other operating systems?

~~~
odiroot
Then why not have it optional?

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

~~~
mikewhy
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](https://www.docker.com/docker-
compose)

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

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

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

~~~
sdegutis
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.

~~~
creshal
Seems to be the solarized colour palette (or was inspired by it, at least):
[http://ethanschoonover.com/solarized](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](https://github.com/nielsmadan/harlequin)
).

~~~
sdegutis
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!)

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

~~~
sanderson1
Full disclosure: I work for Nanobox. We're prepping Nanobox Cloud for release
likely in 2016 [https://nanobox.io/cloud/](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.

~~~
arsalanb
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.

~~~
sanderson1
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/](https://nanobox.io/cloud/) (Just click "Sign up
for the Private Beta" and submit your email).

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

~~~
davexunit
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.

~~~
random778
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](http://nixos.org/~eelco/pubs/phd-thesis.pdf)

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

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

~~~
davexunit
>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.

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

~~~
sdomino
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/](https://nanobox.io/cloud/)) that will use nanobox
desktop to help streamline deploying production code to a provider of your
choice.

~~~
Dangeranger
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/](https://nanobox.io/open-source/) . I had never heard of anything you
all made until today.

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

~~~
sanderson1
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.

~~~
gmisra
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.

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

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

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

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

~~~
zeckalpha
That one's not unreasonable.

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

~~~
sanderson1
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.

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

~~~
sfilipov
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.

~~~
boundlessdreamz
Or use NFS. Way better performance.

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

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

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

------
marknutter
Beautiful website. Really. The colors are exquisite.

------
Gedrovits
Magic engine detected Rails 4.2.5 app as nodejs...

~~~
sanderson1
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](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.

