[michaelsbradley]

Okay, but that doesn't answer my question. :-)

I'd like to run a local instance of the "hyper system," fully contained on my laptop, perhaps running atop virtualbox. If I find it appealing, with respect to the usage experience (i.e. deploying/composing containers), I'd be willing to run some apps on the real deal. I am, though, not willing to experiment with the "real deal" as a means of evaluating it.

[arcticfox]

Lol, I think they even give you a free credit to start. It takes like 5 minutes to get set up. Not sure what your hesitation is.

It's like "I absolutely won't try DigitalOcean unless they let me create a VM locally first!" Doesn't make any sense.

[StavrosK]

It takes 5 minutes to get set up, then 15 minutes to make sure you deleted everything afterwards :(

[gnawux]

You may login to your console, and the overview page 'https://console.hyper.sh/overview' shows all what you have.

[StavrosK]

I did, but I still needed to delete every single thing by hand, and some things could not be deleted because other things were using them, even though I had stopped all the things, so it had to be in a specific order that took a while to figure out.

[OJFord]

Not even for the micro-pennies that experimenting with the real deal would cost you?

If you think you might end up using it, why try and replicate it on your machine (any more than Docker already does) rather than just cross the deployment bridge sooner?

[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.