[jaytaylor]

When we first began creating ShipBuilder several months ago, Docker was too unstable to develop against. We then looked at using bare LXC instead and realized it was very straightforward (basically as simple as: lxc-clone, lxc-start, lxc-stop, and lxc-destroy). In fact, most of the LXC functionality is encapsulated in this 50-line file: https://github.com/Sendhub/shipbuilder/blob/master/src/execu...

I am certainly open to the possibility of adding docker compatibility, especially in the form of a pull-request ;)

[zobzu]

You know what, I kinda like it the way it is now anyway. It's simple, straight-forward, doesn't have too many layers, etc.. I can read it, understand it, hack it, all this quite easily - rare enough to mention.

That's much closer to the kind of stuff I like to use than the pile of layers + apis docker-based solutions are.

[shykes]

In docker's defense, it does much more than simply wrap lxc. It also handles logging, port allocation, container versioning, building containers from source code, data persistence, etc. Shipyard will have to re-implement all this (and probably already has, at least partially), and we're definitely not talking about 50 lines.

Not that there anything wrong with that. Docker is quite recent, so it was probably very unstable when shipyard was started, if it was usable at all.

And frankly, even if it weren't: "let he who is without NiH cast the first stone" :)

[rdpfeffer]

ShipBuilder does most of the things you mentioned. Though, its been a while since I played with Docker, it may have overcome some of the challenges shipbuilder has yet to face. What I do like though, is after having been a Heroku user, using ShipBuilder seems like a walk in the park. No need to learn anything new.

[crashoverdrive]

Calling it by the wrong name certainly sounds like the first stone to me.

[retr0h]

IMO, Docker is the standard platform to build these types of apps on. With all the tooling and projects rallying around Docker, I'd definitely board that ship.