Firecracker (and by extension, herd) is currently optimized for blisteringly fast CPU and network isolation—specifically. We do not currently support PCIe GPU passthrough at the moment.
If you need fast serverless GPU deployments, look into platforms like Modal. Once we tackle GPU scheduling in herd, I will make a lot of noise about it, but right now it is not the right tool for your specific job.
Quick question for your setup: Coder workspaces usually require persistent state for the developer. Are you looking to map local NVMe LVM volumes to the microVMs for speed, or are you relying on network-attached storage? herd's devmapper pipeline handles the ephemeral rootfs beautifully right now, but I'd love to hear what your specific persistence requirements are for those workspaces.
If you're open to chatting about how the Terraform provider should be structured to fit your team's workflow, shoot me an email: hackstrix99@gmail.com
Sprites are fantastic for persistent, hardware-isolated sandboxes. But to achieve those instant creation speeds, they start from a minimal base Linux environment rather than a standard OCI image.
herd solves the same problem (sub-second Firecracker cold boots) but optimizes for a different workflow:
I wanted to keep the standard Dockerfile developer experience. herd uses a containerd devmapper pipeline to instantly carve out copy-on-write snapshots directly from standard OCI images. You get the microVM isolation and speed, but you bring your existing containers.
Sprites are a managed cloud primitive. herd is built as an embeddable control plane, it's a single Go binary you can deploy directly onto your own servers or inside an air-gapped enterprise VPC.
It's the same core Firecracker magic, just optimized for teams who want to keep their Dockerfiles and own their metal.