Compared to other tools

Yoink lives in a populated neighborhood. Pick the tool that fits your scale, your operator headcount, and how much always-on infrastructure you want to operate just to run your apps.

At-a-glance matrix

A high-level cross-section before the per-tool deep dives. ✓ = built-in, ◐ = partial / requires opt-in, ✗ = not in scope.

The columns yoink wins on: single-binary operation, drift detection, sealed in-repo secrets, hardened container defaults, pre-merge diff, standalone (no-registry) mode, port-forwarding to services that don't publish host ports (a kubectl-style affordance only Kubernetes itself otherwise offers in this peer group), and one-line templates (yoink add postgres, yoink add openclaw, yoink add gh:acme/templates/foo; see the templates guide). The columns it deliberately doesn't fight on: auto-scaling, multi-tenancy, web UIs.

vs. Kamal

Kamal is the closest neighbor. Both ship a Rust/Ruby binary over SSH into hosts and drive Docker. The differences:

Pick Kamal when: you have a Rails/Phoenix/Hanami app, you want one tool that builds + deploys + routes, and you don't need replicas or per-tier network isolation.

Pick yoink when: you've got several services with different shapes (Rust API + Node web + Postgres), you want drift detection, sealed in-repo secrets, and a k9s-style TUI for inspect/rollback. Or when you want the no-registry, no-CI standalone loop for a hobby project.

vs. Coolify

Coolify is a self-hosted PaaS (think open-source Heroku/Render) running as a long-lived web app on one of your servers. It manages everything: build pipelines, databases, env vars, auto-deploys from git, a UI for non-engineers. Yoink is a much narrower tool that handles the "deploy these containers to these hosts" piece without any of the PaaS surface area.

Pick Coolify when: you want batteries-included PaaS (build, deploy, database, web UI, multi-user) and you're comfortable operating Coolify itself as a long-running service on one of your boxes.

Pick yoink when: you already have CI + git for the build pipeline, you want the deploy layer to be a thin CLI you run on demand, and you'd rather not run another web app + database to deploy your apps.

vs. Dokku

Dokku is the original "Heroku in a box": a single host runs Dokku, you git push dokku main, and a buildpack/Dockerfile flow ships your app behind nginx with auto-TLS. Light on infrastructure, deeply opinionated about the "git push to deploy" loop.

Pick Dokku when: one host is enough, the buildpack ergonomics fit your stack, and "git push to deploy" is the user experience you want.

Pick yoink when: you want the same "drop a config and run a command" simplicity but across multiple hosts, with replicas, drift detection, and sealed in-repo secrets, and you'd rather not maintain a Dokku install on each box.

vs. Komodo

Komodo is a fellow Rust-built deploy/management tool for self-hosted containers, with a sizable feature overlap with yoink. The biggest split is ceremony: Komodo is a long-running web service with a control plane and per-host agents; yoink is a single binary you run from your laptop or CI.

Pick Komodo when: you want a UI for non-CLI users, you're managing more hosts than fit in one operator's head, RBAC matters, and the overhead of running a database + a web service + per-host agents is worth it for the control-plane affordances.

Pick yoink when: a single binary on your laptop is the entire control surface, the git repo is the source of truth, and you'd rather not operate yet another service-with-database to deploy your services. The CLI/TUI shape works best for 1–3 operators (or for AI agents and CI runners) who are already comfortable in a terminal.

vs. Uncloud

Uncloud is in the same neighborhood as yoink: small fleet, multi-service, deliberate-not-Kubernetes. The biggest split is again ceremony: Uncloud installs a per-host daemon (uncloudd) on every managed machine and stitches them into a WireGuard mesh; yoink is a one-binary client that talks to docker over plain ssh.

Pick Uncloud when: cross-host service-to-service networking matters (your api on one box talking to your worker on another), and you're OK with running a daemon per host as the price of that affordance.

Pick yoink when: you already have a routing answer (Tailscale, a single edge box, public-DNS-everywhere), you don't want any always-on yoink-specific service running on the host, and the per-host docker daemon over ssh is enough surface area to manage from. The two tools converge on "small fleet of containers, opinionated defaults" and diverge on whether the deploy tool also owns the network fabric.

vs. plain docker compose

Compose is a YAML schema for declaring a stack on a single host. yoink is a deploy tool that runs against any number of hosts.

Pick compose when: dev-machine local stack, single-host hobby project, or you're already comfortable scripting around compose for deploys.

Pick yoink when: you want compose's "declarative containers" model with a real deploy story (rolling, multi-host, drift detection, secrets, hardened defaults, bundled proxy).

vs. Kubernetes

Yoink is for people who don't want a control plane.

Pick Kubernetes when: you have a real infrastructure team, you need autoscaling or multi-tenancy, you're operating across many regions, your engineering org standardized on it, you want a service mesh.

Pick yoink when: you want the Kubernetes ideas that pay off at small scale (drift detection, per-tier networks, healthcheck-gated rolls, declarative config, in-repo secrets) without the control plane and the team to operate it.

vs. nothing: just ssh + docker run

The honest baseline. Many small deployments are exactly this and that's fine.

Pick "just ssh + docker run" when: you have one container, you only need to deploy occasionally, and you don't mind that docker run doesn't roll, doesn't healthcheck, doesn't drain, doesn't track who deployed what when.

Pick yoink when: you've started writing shell scripts wrapping ssh + docker run and you'd like to stop. The yoink config is roughly the shape of those scripts but declarative, and the tool gives you the rolling/healthcheck/drift/history pieces you'd otherwise build yourself.

See also

• What and why — the design philosophy in one page.
• Start: first deploy — five-minute hands-on if the matrix above lands you on yoink.
• Architecture — drift detection, deploy lock, healthcheck-gated swap.