[michaelsbradley]

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 setup docker daemon hosts on Digital Ocean, et al.

I'd like to worry even less about the container host and get comfortable with a system like Hyper, but it's important to me to get used to it running locally for dev prior to employing it "in the cloud" for prod.

[mrmrcoleman]

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.

[michaelsbradley]

I've not spent much time with AWS. I was thinking more along the lines of Rackspace, Linode, Digital Ocean, those kinds of hosts.

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.

[mrmrcoleman]

If it's really about workflow parity then I would encourage you to give it a spin. I think the parity gap will be similar to your previous experiences with VMs all things considered.