Right now there is a `actool build` subcommand that will build an ACI given a root filesystem. That tool is used to build the validation ACI's and the etcd ACI. It is rough right now and we will make it simpler to use overtime; and as rkt gets better people can run the build tool from inside of a container given source code.

Nice. It occurs to me that since an ACI is just a tarball, the build process is decoupled from the runtime engine, unlike in Docker. I've found the Docker build process to be unsuitable for creating minimal images (though I've read that nested builds plus layer squashing will fix this). It'll be interesting to watch the exploration of different build tools and processes that Rocket's decoupled approach will enable, if it catches on.

> Nice. It occurs to me that since an ACI is just a tarball, the build process is decoupled from the runtime engine, unlike in Docker.

Yep, this is _exactly_ one of our design goals. ACIs are trivially buildable and inspectable with standard Unix tools.

Docker can import any tarball as a rootfs for a container, essentially allowing you to use whatever build tool you want.

Dockerfiles/`docker build` is an implementation of a build system which uses the docker engine to make said rootfs.

Yes, but the actual container image that is being distributed can only be created by Docker. The ability to import is nice, but irrelevant here.

Docker already supports alternative build systems via docker import.

Realistically, if the stack is broken into a dozen pieces then somebody will create a bundle with sensible defaults (let's call it "CoreOS") and then we'll be back in the same situation.