This is my first use of docker's multi-stage build.
Constructing the Dockerfile was easier than figuring out how to get docker web properties to build it. github 
I use 1) a node container to compile the apparatus code. I use 2) an alpine container to download and setcap Caddy. The final container 3) uses alpine as a base with Caddy as the web server hosting the compiled static web assets. If I were to rely on an external Caddy, the final container could be a volume-only container holding the statically compiled assets.
# dependence or independence
Today (2017-08-23) in the fedwiki chat room, one person reported success installing the local farm on their laptop. In the brief discussion I learned that an earlier revision of that farm was forked into github.com/fedwiki. github
On the one hand that feels a bit like a promotion. And on the other hand, I've split that early work into a bunch of tiny repos and arranged for hub.docker.com to build and host the containers by name. The difference between dependency in the new vs independence in the old leaped out at me. As recently as May or June I had ambitions of a wholly self-hosted containerized wiki farm. It was a bit surprising to notice how I've hitched my cart to hub.docker.com for resolving the names to containers. I'm not sure this is good nor bad. But interesting turn of events in my own development.
# fast or slow
Docker ecosystem and tools change fast. In the few years I have been going along for the ride, I haven't had the same experience of breakage when following a young project on their bleeding edge. But getting these containers to build has felt rough around the edges.
hub.docker.com is where things come from when you say 'docker pull dobbs/proxy'. I created that docker repository by linking from the github repo where I committed the code. The automated build part has not worked as advertised. (As it happens, I think I discovered the missing piece to engage the actual automation while looking for other things today.) What's more, hub.docker.com does not (yet) know how to handle multi-stage builds. I found github issues to that effect which had the workaround of using cloud.docker.com. I did get that working for 'dobbs/apparatus', but I cannot seem to find a way to offer a public link to the cloud repo for learning about dobbs/apparatus, and the one that can be found publicly at hub.docker.com shows builds failing which would not reassure me as a consumer of other people's open source code
Much of current hype around containerization pitches the ability to accelerate and move fast, faster than ever. By contrast, I see in wiki a sense of patience. Let what we have stew a bit. Live with it a while and learn what it wants to be.
Tortoise and Hare (or perhaps Achilles in a strange loop)