VM Snapshot vs Volume Snapshot

I’ve been porting applications over to fly, but I’ve been finding it more difficult to move non dockerized apps over.

I’m thinking of just spinning up a base image fly server and setting these non dockerized apps myself. But then I’m worried I won’t be able to scale these apps, and I could easily lose server config.

Is there a workflow for saving a snapshot of a VM and then spinning up a new VM from a snapshot? That would make me feel a lot less nervous about “manually” configuring servers.

Apologies if I missed this, but when I search for snapshots and restoring it seems to always focus on volume snapshots and DB restores. But I am just interested in general VM snapshots.

Also just wanted to bump this Different statics paths for different domains? - Questions / Help - Fly.io

We don’t have any VM snapshot features yet. Hopefully sometime this year! The first hack is going to make it very fast to resume a machine, though. Creating entirely new machines from snapshots is more complicated. We may never ship that (we’ll see!)

For what you’re doing, I think you may be better off with Docker tooling. If I understand right, you want to start with an image, shell into it, then run a bunch of commands to make it work like a non-dockerized system.

The docker commit command will create an image from a container. Which means you can start from scratch with something like this:

docker run --name my-custom-image debian:stable-slim /bin/bash

Then run all the commands you want. Then exit. Then you can run:

docker stop my-custom-image
flyctl auth docker
docker commit my-custom-image registry.fly.io/my-app:build-1234
docker push registry.fly.io/my-app:build-1234

Does that do what you need?

The caveat here is that you need to be running x86 Docker. If you’re running Docker on an m1 Mac, this won’t produce a Docker image you can run on Fly.

3 Likes

That’s a great solution!