Payloads
What yeet can run and where to start.
A payload is what you pass to yeet run, yeet stage, or yeet cron. Yeet
detects the payload type, ships what needs to be shipped, and asks catch to
install it on the target host.
Containers
Docker Compose files, Dockerfiles, image refs, and container-backed Python or TypeScript apps.
Binaries & Scripts
Host systemd services from local Linux binaries or shebang scripts.
VMs
Long-lived Linux guests using Firecracker, KVM, and yeet-managed VM images.
Cron Jobs
Scheduled jobs installed as systemd timer units on the catch host.
- Use Containers for Compose stacks, Dockerfiles, public image refs, local images, Python apps, and TypeScript apps.
- Use Binaries & Scripts for one long-running host process that does not need a container.
- Use VMs when the workload needs a full Linux guest or stronger isolation than a container.
- Use Cron Jobs for scheduled host jobs.
yeet run <svc> <payload>
yeet logs -f <svc>
yeet restart <svc>
yeet rm <svc>
After the first successful deploy, yeet writes the service configuration to
yeet.toml. For an existing service, a payload-only redeploy reuses saved run
options such as network mode, tags, service root, snapshots, and payload args.
ZFS is optional, but it is useful for services that need named datasets, pre-change snapshots, or fast repeated VM creates on the same pool.
yeet run <svc> ./compose.yml --service-root=tank/apps/<svc> --zfs
yeet run <vm> vm://ubuntu/26.04 --service-root=tank/vms/<vm> --zfs
See ZFS for the shared model across payload types.
- Service Types explains detection rules and high-level install behavior.
- ZFS covers ZFS-backed service roots, snapshots, and VM disk clones.
- Workflows shows common deploy and update flows.
- Networking covers
svc,lan, andts. - Configuration & Prefs covers
yeet.toml,CATCH_HOST, and saved preferences.