Unregistry

The rsync of container deployment — no registry setup, no subscriptions, just layers over SSH.

TL;DR

• What it is: A Docker CLI plugin (docker pussh) that transfers images directly to remote servers over SSH, spinning up a temporary registry on the target and transferring only the missing layers [README][3].
• Who it’s for: Developers and small teams deploying to VPS or dedicated servers who are tired of paying for Docker Hub private repos, setting up Harbor, or watching docker save | ssh server docker load transfer a 2GB image when only 200MB changed.
• Cost savings: Docker Hub Team plan runs $11/user/month for private repos. GitHub Container Registry charges for bandwidth above free tier limits. AWS ECR costs $0.10/GB storage plus data transfer. Unregistry is free — no storage, no bandwidth fees, no registry infrastructure at all.
• Key strength: Genuinely solves a gap in the Docker toolbox. The docker save | ssh | docker load workaround is universally hated because it transfers every layer every time. Unregistry does layer deduplication, making repeated deploys fast [README][3].
• Key weakness: Developer-facing CLI tool. If you’ve never touched a terminal, this isn’t your tool. And your remote server needs internet access to pull the unregistry image from ghcr.io on first run — which creates a catch-22 for air-gapped environments [README].

---

What is Unregistry

Unregistry is a lightweight container image registry that stores and serves images directly from your Docker daemon’s storage. The actual useful part is the docker pussh CLI plugin (note the extra ‘s’ — for SSH) that uses this registry to move images between machines efficiently.

The core README pitch is blunt: “You’ve built a Docker image locally. Now you need it on your server. Your options suck.” The four options it lists — Docker Hub/GHCR, self-hosted registry, save/load, rebuild remotely — all have real friction for small deployments. Docker Hub private repos cost money. A self-hosted registry (Harbor, Zot, plain Docker Registry v2) is another service to maintain with its own storage, TLS, and authentication. The save/load pipe approach is notorious for transferring full images every time, even when 90% of the layers already exist on the target. And rebuilding on the server wastes build time and can produce different results than local.

Unregistry takes a different approach. When you run docker pussh myapp:latest user@server:

1. An SSH tunnel is established to the remote server
2. A temporary unregistry container is started on the server (pulled from ghcr.io/psviderski/unregistry:latest)
3. A random localhost port is forwarded to the unregistry port through the tunnel
4. docker push runs to unregistry through that forwarded port — transferring only layers that don’t already exist on the remote
5. The container shuts down, the tunnel closes

The transferred image is immediately available on the remote Docker daemon. No intermediate storage. No registry running permanently. No open ports on your server [README].

The project was created as a component of Uncloud, a lightweight tool for deploying containers across multiple Docker hosts, when the team needed something simpler than a full registry but smarter than save/load [README]. It’s now a standalone tool with 4,692 GitHub stars.

---

Why people choose it

The use cases that show up consistently across the README and DevOps tool roundups:

Replacing the save/load pipe. The docker save | ssh <remote> docker load pattern works but is genuinely inefficient. If your image is 1.5GB and you changed one application layer of 50MB, save/load still transfers all 1.5GB. Unregistry only transfers the delta — the layers that don’t exist remotely [README][3].

Avoiding registry infrastructure for small deployments. A DevOps tools roundup on ide.com [3] summarizes the fit: “Ideal for small-to-medium deployments on dedicated servers or VPS where registry overhead feels excessive.” Running Harbor or a plain Docker Registry v2 for a single app on a single server is genuine overkill. Unregistry gives you the efficiency of a registry push (layer deduplication) without the operational overhead of keeping one running.

Skipping Docker Hub private repos. If you’re shipping proprietary code, putting your image on Docker Hub public is obviously out. Private repos on Docker Hub start at the Team plan ($11/user/month). For a solo developer or two-person startup deploying to a personal VPS, that’s a recurring cost to avoid something that Unregistry handles for free.

Multi-server deployments. The README lists pushing to multiple servers as a use case. If you’re deploying to 3 servers, you run docker pussh three times (or script it). Each push is efficient because the layers from the first push are already on all servers if they share a base image.

---

Features

Core mechanism:

• Layer-aware transfer — only missing layers are sent, like rsync for Docker images [README]
• Temporary registry lifecycle — spun up per-push, no persistent service required [README]
• SSH tunneling — no open ports required on the remote server, no extra firewall rules [README]
• Works with standard docker push protocol under the hood — the remote sees it as a normal push [README]

Installation methods:

• Homebrew tap: brew install psviderski/tap/docker-pussh (macOS/Linux) [README]
• Direct binary download via script [README]
• Linux apt package (listed in features) [README]
• Docker CLI plugin symlink setup required after Homebrew install [README]

Air-gapped / restricted environments:

• Manual preload path documented for environments where the remote can’t reach ghcr.io [README]
• Use docker pussh --version to get the exact image tag needed, then docker save | ssh server docker load the unregistry image itself as a one-time bootstrap [README]

Containerd image store compatibility:

• Warning in README: if Docker is configured to use containerd image store (containerdImageStore: true in Docker Desktop), there are known limitations — the README flags this as a separate configuration concern [README]

Third-party integrations:

• Used internally by Uncloud for multi-host container deployment [README]
• Referenced in DevOps tooling lists as an alternative to full registry infrastructure [3]

What it doesn’t do: no image scanning, no retention policies, no web UI, no RBAC, no image tags browsing. It’s a point-to-point transfer tool, not a registry platform.

---

Pricing: Registry costs vs. Unregistry

Unregistry itself has no pricing tiers. It’s free, Apache-2.0 licensed, runs from a shell command. The relevant cost comparison is what you’d otherwise pay.

Docker Hub:

• Free: 1 private repo, public repos unlimited, rate-limited pulls (100 pulls/6hrs for unauthenticated)
• Personal: $5/month — 5 private repos
• Team: $11/user/month — unlimited private repos, required for team access

GitHub Container Registry (GHCR):

• Free for public packages; private packages consume GitHub Actions storage and bandwidth
• GitHub Free: 500MB storage, 1GB/month data transfer for private packages
• GitHub Pro/Team: 2GB storage, 10GB transfer — above that, $0.008/GB storage, $0.50/GB transfer

AWS Elastic Container Registry (ECR):

• $0.10/GB/month storage
• $0.09/GB data transfer out (to EC2 in same region is free; cross-region or internet isn’t)
• For an active deployment pipeline, costs accumulate quietly

Self-hosted Docker Registry v2 or Harbor:

• Software is free; you pay for the VPS to run it, storage, and your time maintaining TLS/auth/backups
• Hetzner smallest VPS for a dedicated registry: ~$4–5/month
• Harbor adds Kubernetes complexity and operational overhead beyond a simple registry

Unregistry:

• $0 — no storage, no bandwidth fees, no running service
• Your only cost is the SSH connection time during a push

For a solo developer or two-person startup doing 5–20 deploys per day to one or two servers, the math is trivial: Unregistry is free and requires no infrastructure decision. The break-even comparison against Docker Hub Personal ($5/month) is basically instant.

---

Deployment reality check

Local requirements:

• Docker CLI 19.03+ with plugin support (standard on any modern Docker Desktop or Engine install)
• OpenSSH client (standard on macOS and Linux; Windows users need WSL or Git Bash)

Remote server requirements:

• Docker installed and running
• SSH user with docker group membership (or root) — passwordless sudo docker also works [README]
• Internet access to ghcr.io for the first push (to pull the unregistry container image)

What can go sideways:

The air-gapped bootstrap problem is real. If your server is behind a corporate proxy or in an air-gapped environment, the first docker pussh will fail silently-ish because the server can’t pull ghcr.io/psviderski/unregistry:latest. The workaround is documented and works, but it’s a speed bump if you discover it mid-deployment: you need to manually pre-load the unregistry image using the very docker save | ssh | docker load pattern you were trying to avoid [README].

The containerd image store flag is another edge case. Docker Desktop with "containerdImageStore": true in daemon config has known compatibility issues flagged in the README. Most users won’t hit this, but if you’ve been following Docker’s recommendations for enabling new features, double-check your config before assuming it’ll work [README].

Realistic setup time:

• For a developer who uses Docker regularly: under 5 minutes from brew install to first successful push
• For someone setting up on a new remote server (creating the docker group, adding the SSH user): 15–20 minutes including testing

---

Pros and Cons

Pros

• Solves a real gap cleanly. The docker save | ssh | docker load inefficiency is a genuine daily frustration for anyone deploying to VPS. Unregistry fixes exactly that, nothing more [README][3].
• Apache-2.0 license. Permissive — you can embed it in internal tooling, CI pipelines, or commercial deployment scripts without license concerns.
• Zero persistent infrastructure. No registry service running permanently, no storage to manage, no TLS certificates to renew, no authentication system to maintain [README][3].
• No open ports on remote. Everything runs over the existing SSH connection. No new firewall rules, no exposed registry ports [README].
• Layer deduplication works. The mechanism is sound — it uses the standard Docker push protocol which inherently skips existing layers. Not a reimplementation; it delegates to Docker’s own logic [README].
• Created for real production use. It was built as a component of Uncloud, not as a demo project — which means the hard edge cases (layer transfer failures, SSH timeout handling) were encountered and fixed during actual use [README].
• 4,692 GitHub stars for a very narrow-scope utility is a strong signal of genuine usefulness.

Cons

• CLI-only, developer-facing. There’s no web UI, no API, no management dashboard. If you need non-technical team members to trigger deployments, you’ll need to wrap this in a script or CI job.
• Internet access required on remote (first run). The bootstrap problem with ghcr.io is a real friction point for constrained environments [README].
• Containerd image store incompatibility. An increasingly common Docker Desktop configuration that breaks the tool [README].
• Single-purpose — no registry features. No image scanning, no retention policies, no vulnerability alerts, no registry UI. If you need any of those, you need a real registry on top of or instead of this.
• Runs unregistry container as root on remote. Required for containerd socket access — acceptable for most VPS setups but worth knowing if your environment has strict security policies [README].
• Small project surface. One primary maintainer, 141 commits. The GitHub org is the creator’s personal account. Not a concern for a simple utility, but worth noting if you’re evaluating it for a larger team deployment dependency.
• Limited third-party coverage. Outside of DevOps tool roundups [3] and mentions in the Uncloud ecosystem, there aren’t many independent reviews or long-term production reports to draw from.

---

Who should use this / who shouldn’t

Use Unregistry if:

• You deploy Docker images to one or more VPS/dedicated servers via SSH and are currently using docker save | ssh | docker load
• You want to avoid Docker Hub private repo costs or GHCR storage fees for images that never need to be publicly accessible
• You’re building a small deployment pipeline and don’t want to operate registry infrastructure
• You use Uncloud for multi-host container orchestration — Unregistry is its native image transport [README]
• Your team is comfortable with CLI tools and SSH

Skip it (use a real registry) if:

• You need image scanning, vulnerability alerts, or retention policies
• Multiple team members need to pull images from a central location (Unregistry is push-only, point-to-point)
• You’re deploying to Kubernetes or container platforms that need to pull images from a registry endpoint
• You have non-technical team members who need to trigger or monitor deployments through a UI
• Your security policy prohibits running containers as root on servers

Skip it (stay on Docker Hub/GHCR) if:

• You’re already on a GitHub Team plan and GHCR private packages are included in your existing bill
• You need pull access from multiple machines or environments, not just pushes from your local machine

---

Alternatives worth considering

• Docker Hub — the default. Free for public, paid for private. Rate limits on pulls are increasingly painful for CI pipelines. Makes sense if you need centralized pull access.
• GitHub Container Registry (GHCR) — free for public packages, included in GitHub paid plans. Best choice if your team is already on GitHub and needs pull access from CI/CD.
• AWS ECR / GCP Artifact Registry / Azure ACR — cloud-native options. Sensible if you’re already in that cloud’s ecosystem. Add up the storage and transfer costs; they’re not trivial at volume.
• Zot — lightweight open-source OCI-native registry, Apache-2.0, designed for minimal footprint. If you actually want a persistent registry without Harbor’s complexity, this is the current best option.
• Harbor — full-featured enterprise registry with scanning, RBAC, replication, web UI. The right choice at organizational scale; overkill for a single-app VPS deployment.
• Uncloud — if Unregistry solves the image transfer piece but you also need multi-host container orchestration, Unregistry’s parent project handles the whole workflow [README][1].

The realistic decision tree for a solo developer or small team: if you deploy to servers you SSH into directly, try Unregistry first. If you need centralized pull access (CI/CD clusters, multiple team members pulling), GHCR or ECR depending on your existing cloud footprint. If you’re at the scale where you need image scanning and governance, Harbor.

---

Bottom line

Unregistry does one thing: it makes docker pussh work the way you always wished docker save | ssh | docker load worked — sending only the missing layers, using your existing SSH access, without standing up registry infrastructure. It’s not trying to replace Docker Hub for teams that need centralized pull access, and it’s not trying to compete with Harbor for enterprise image governance. It’s filling the gap between “manual and slow” and “full registry overhead” that exists for exactly the kind of developer deploying to a handful of servers they own or rent. For that use case, at 4,692 stars, it’s clearly hitting the mark.

---

Sources

1. allesnurgecloud.com Newsletter #215 — “Cloudflare Ausfall, Fixit Week, Shopify Black Friday Rekorde & Vorbereitung, 8 Stunden Mythos, GitHub Exodus und mehr” (December 7, 2025). Mentions Uncloud (parent project). https://allesnurgecloud.com/newsletter/cloudflare-ausfall-fixit-week-shopify-black-friday-rekorde-vorbereitung-8-stunden-mythos-github-exodus-und-mehr-215/
2. ide.com — “12 DevOps Tools You Should Be Using in 2026 (SREs Included)”. Lists Unregistry under Infrastructure & Application Platform with usage description and star count. https://ide.com/12-devops-tools-you-should-be-using-in-2026-sres-included/

Primary sources:

• GitHub repository and README: https://github.com/psviderski/unregistry (4,692 stars, Apache-2.0 license)
• Uncloud (parent project): https://github.com/psviderski/uncloud