Why are you trying to tackle some small little market of staging servers for the handful of companies that actually care about this?

Take your Hypervisor and sell it to companies that want to efficiently lift-and-shift legacy systems in to the cloud and make your investors super happy.

You should probably be selling that if it works well. That is something I have not seen.

<mostly sarcastic>

Bakevm with tooling > create userdata script for cloud init to copy payload to server > create systemd oneshot service to run payload && shutdown

You should try it! Our baking interface looks more like Docker than a traditional VM provision (ala Packer)

Also, we keep the baked images around for a week and trigger them whenever they are requested (with, say, HTTP, or terminal access)

I may be misunderstanding the product, but it seems to be able to run a webserver on each "server".

More info on that would be cool. Something like Amazon's FireCracker?

Sort of - FireCracker is less suited for testing use-cases because it still cold-boots. We use the same kernel features that let laptops resume when the lid is opened instead, they're less mature for production but much faster for staging and testing.

Are you using socket activation or something similar? I think there are really interesting use cases around that paradigm for packing services onto one host.

Some blog posts I remember from when I was exploring this idea a few years ago:

http://0pointer.de/blog/projects/socket-activated-containers...

https://www.ctl.io/developers/blog/post/running-drupal-in-li...

Sort of, you can think of it as an entire socket-activated OS.

Our hypervisor does the logic though, we don't rely on the OS of the staging server itself for anything (think PXE)

Ah. VMware does something similar for hot provisioning VMs from a point in time memory snapshot.

So you guys boot the image in the background, then capture a memory dump of it so you can quickly launch VMs from that snapshot? Or you boot the VMs the traditional way the first time, and then just suspend them when not in use?

We do even more, we take snapshots as the "Layerfile" runs - this basically lets you merge the memory dump semantics you mention with the interface of Docker.

Also, we monitor which files are read by any step in the process, and let you skip setup chunks that don't need to run (i.e., installing libraries) without needing to micromanage what files you copy into the staging server.

Man that sounds cool. I don't have any use for something like that, but I would love to see it opensourced to play with it (which I assume you guys won't be doing anytime soon)