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

One of the features I heavily use from fig is controlling the runtime docker parameters in fig.yml, i.e the VOLUME, ENTRYPOINT, EXPOSE, WORKDIR sort of stuff. I see you guys made the decision to maintain the runtime commands in your Dockerfile, requiring a rebuild to change it. Everything except Environment.

I guess my question is, why did you guys choose to do that?

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 [email protected]

Less powerful.

(Disclaimer: I work for Nitrous.IO)

I wouldn't describe tug as less powerful, it's less complicated from my usage of it. For each service I only need to write one line and tug will figure out (from the Dockerfile) what needs to be forwarded.

The mind blowing moment is when you're using boot2docker (or any case where Docker isn't local) and it still forwards the ports to your local (127.0.0.1) host.

> The mind blowing moment is when you're using boot2docker (or any case where Docker isn't local) and it still forwards the ports to your local (127.0.0.1) host.

That's easily achieved with a Vagrantfile for your Docker VM...

I wouldn't say it's that easy, if you add more containers to your Docker VM and need them forwarded you then need to update your Vagrantfile and reload.

With tug any port you expose on the containers is brought locally to you instantly.