Earlier quoted context omitted.
I prefer an "always local first" approach. Before Docker, it was Vagrant + VirtualBox for dev, some VPS hosting company for prod. With docker, it's basically the same thing (better, though, imo), but I no longer think much about the virtual machine on which the docker daemon is hosted and instead rely on boot2docker , Docker Machine , and now Docker for Mac for the local side. For prod, I've used Docker Machine to se…
Taking the vagrant example, you'd typically play with vagrant locally and then move to AWS you mean? You can do exactly the same with Hyper. Play with Docker locally and then move to Hyper. The CLI commands are pretty much identical, docker compose works in the same way. Of course it's not exactly indentic, neither is a vagrant image and an AMI.
Yes there are important differences between running a dev server on VirtualBox and a prod server on one of the above, but there is parity in the workflow. The same is true when thinking about docker-machine + docker, locally then remotely.
I understand that Hyper's cli is quite similar to docker's cli. But my preference is to not consider it seriously until I can bang against a version of the Hyper backend running locally. If that's not forthcoming, fine, Hyper's not for me. :-) If it is, then great! I can't wait to play with it, locally, on my personal computer/s.