ddollar

It is similar to Deis in goals but it differs substantially in implementation. Because Convox runs on AWS we can rely on stable and scalable services only available on that platform such as ELB and DynamoDB. Deis uses its own internal Postgres and implements a custom load balancer, scheduler, etc. We believe using the hosted services will help you keep your operational costs down over time.

Hello! I'm part of the Convox core team and happy to answer any questions.

Convox is an app deployment platform that you can install into your own AWS account. It uses ECS, ELB, Kinesis, and many other great AWS services under the hood but automates it all away to give you a deployment experience even easier than Heroku.

Convox uses Docker under the hood so if you want to customize anything (distro, dependencies, etc) you can simply add a Dockerfile to your project.

Convox is entirely open source. Check it out at https://github.com/convox

To get started with our installer go to: http://docs.convox.com/docs/getting-started-with-convox

> The selling point behind these devices is convenience, but at the cost of security. I don't think I need to explain to HN why an always-on, internet connected voice recording device is something to keep out of your house.

Do you have any computers in your house? A TV made in the last few years? A smartphone?

I have not found myself needing to change those things very often once I have created the initial Dockerfile.

If you've got the time I'd love to hear more about your workflow at david@nitrous.io

I'm really excited about the idea of groups that may be coming to Docker. It seems like a great primitive around which to build tools like fig and tug and perhaps other tools to orchestrate production.

https://www.youtube.com/watch?v=YuSq6bXHnOI

Sorry about that! I'm trying to get the docs into shape as fast as possible.

If a line starts with "docker/" the rest is assumed to be a docker image tag.

Thank you for the kind words and the clarifications Mitchell :)

Tug is a simple tool that I wrote to scratch a personal itch around working with dockerized applications and trying to optimize for startup speed and writing as absolutely little configuration as possible.

I'm hoping to get a few other people to try it out and let me know if it works for them and if it's useful, especially given the existence of so many other tools of this nature.

Awesome :) I think then that the primary difference with Tug is that it can work in a "hybrid" virtualized/local mode if you haven't yet written a Dockerfile/Vagrantfile/other for your app. Tug can start by simply spawning dependencies like Postgres and Redis and let you incrementally move towards a Dockerfile for your app.

Nice :) I believe Vagrant also now has built-in support for Docker which is very useful for starting up ancillary services that your app needs: https://docs.vagrantup.com/v2/provisioning/docker.html

I quite like Vagrant myself but my primary complaint is that I seem to spend a lot of time waiting for VMs to start up and run a lot of bootstrap code.

Tug primarily differs from fig in two ways:

* Less verbose configuration, tries to assume sensible defaults

* Works with apps that do not yet themselves have a Dockerfile

Hello everyone! We created tug as a tool to help people dockerize applications and run them during development.

Please keep in mind that this is a very alpha project still under heavy development. If you try it I'd love to hear how it goes and whether or not it's useful for you (you can reach me at david@nitrous.io or find me on Freenode as ddollar).

There are two reasons I rewrote Foreman in Go. You hit one of them square on the head. A single binary with no dependencies that can be cross-compiled on a Heroku dyno makes things much simpler.

Foreman was originally written in Ruby which ideally means it runs on any machine with a Ruby interpreter. When you get down to it, though, the differences in fork/exec between Ruby 1.8, 1.9, JRuby, Rubinius, etc make this a nightmare scenario of a different sort.

If you go to https://gobuild.herokuapp.com/ddollar/forego/master/darwin/a... you get a working program as a single binary in one step. Using bsdiff I can even ship binary diffs for fast upgrades (this is how `foreman update` works in the new version)

Oh and as a side effect the new Foreman is quite a lot faster to start up (Rubygems initialization is sloooooow)

Thanks for the feedback!

We made the script a link so you could check out what's going on before running it.

The heroku-toolbelt .deb actually depends on system git-core and ruby1.9.1 so we shouldn't be trampling anything.

San Francisco, CA - Heroku

We're looking for an active member of the Node.js community to come own Node.js at Heroku. This position involves both contributing to the Node.js open-source community and working to reduce friction for Node.js users on Heroku.

If you're excited about the promise Node.js and the future of app deployment, come help us to shape it.

Full job description: http://heroku.theresumator.com/apply/gtoHxr/Build-Pack-Maint...

Email: david@heroku.com (please include a link to your Github account)

If you try the latest foreman it should be a lot better about killing things off now. See other comments in this thread about the SIGTERM-pause-SIGKILL approach.

You could also check out something like http://upstart.ubuntu.com/wiki/Stanzas#limit for use in your upstart scripts.

Yes. If you kill foreman with Ctrl-C (or killing its pid externally) it will send SIGTERM to all of the child processes, followed 3 seconds later by SIGKILL to any that haven't terminated yet.