Service Types

Payload detection and installation behavior.

Yeet detects payload type and installs the service accordingly.

Binary

  • ELF or Mach-O binary.
  • Installed as a systemd service on the host.
  • Use yeet run <svc> ./bin/<svc>.

Script

  • Shebang file (e.g., #!/usr/bin/env bash).
  • Treated like a binary; installed as a systemd service.

Docker Compose

  • Any YAML with a top-level services: key.
  • Installed as a docker compose service.
  • Use --pull on yeet run when you want to refresh images; otherwise run reuses existing images.
  • Configure initial port mappings in the compose file. After deployment, use yeet service set <svc> -p HOST:CONTAINER to replace the yeet-managed published-port list for the primary service.
yeet run <svc> ./compose.yml

Docker image

  • If the payload looks like an OCI image ref (e.g. nginx:latest, ghcr.io/org/app:1.2.3), yeet generates a compose file and catch pulls the image on the host.
  • For local images, use yeet docker push <svc> <image>:<tag> --run.
  • For Dockerfiles, use yeet run <svc> ./Dockerfile (builds for the host arch and pushes).
  • Use -p/--publish with yeet run to expose ports (e.g. -p 8000:8000). Yeet saves the mappings and replays them on future runs.

TypeScript

  • .ts files are run via a Deno container.
  • Installed as a docker compose service (via Deno).
  • Use -p/--publish with yeet run to expose ports (e.g. -p 8000:8000). Yeet saves the mappings and replays them on future runs.

Python

  • .py files are run via a uv container image.
  • Installed as a docker compose service (via uv).
  • Use -p/--publish with yeet run to expose ports (e.g. -p 8000:8000). Yeet saves the mappings and replays them on future runs.

Experimental VM

  • vm://ubuntu/26.04 creates a long-lived Ubuntu VM service.
  • Requires a Linux catch host with KVM available.
  • Uses the yeet-owned Ubuntu 26.04 image bundle published at github.com/yeetrun/yeet-vm-images.
  • Saved config uses type = "vm".
yeet run <svc> vm://ubuntu/26.04 --net=svc
yeet vm images
yeet vm images update
yeet vm console <svc>
yeet ssh <svc>

When yeet run starts a VM, it waits for the guest to report readiness and an IPv4 address before printing the next yeet ssh command. If the guest does not report readiness, use yeet vm console <svc> for boot diagnostics.

Use --cpus, --memory, and --disk to override the host-based defaults. VM image bundles are cached per host. Use yeet vm images to inspect the cache and yeet vm images update to refresh the image used for future VM creates. Refreshing the cache does not mutate existing VM disks. A missing image is downloaded automatically on the first VM create. When creating a VM with a stale cached image, interactive runs prompt by default; non-interactive runs require --image-policy=update or --image-policy=cached.

For ZFS-backed VMs, the first VM on a pool and image version prepares a shared ZFS image base. Later VMs on that pool clone the shared base, and yeet rm --clean-data devbox removes the VM clone without deleting the shared base.

Use yeet ssh <svc> for an interactive guest shell. yeet vm console <svc> streams the VM serial output for boot diagnostics. The default ubuntu guest user has passwordless sudo. For yeet-managed VM aliases in ~/.yeet/known_hosts, yeet ssh <svc> repairs a stale host key and retries once after a VM is recreated. Yeet does not edit normal ~/.ssh/known_hosts entries. Use yeet rm --clean-data <svc> when you want to delete the guest disk during removal.

Zstd

  • Zstd-compressed binaries are detected and unpacked.

Cron

  • yeet cron installs a cron-style job as a timer on the host.

Notes

  • File type is detected by extension or content.
  • Architecture must match the target host; mismatches fail early.