Show HN: Unregistry – “docker push” directly to servers without a registry

Overview

• Tool provides a docker pussh-style workflow: push images directly over SSH to remote Docker/containerd daemons, only sending missing layers, no permanent registry required.
• Many commenters say this fills a long-standing gap in the Docker ecosystem, especially for small setups and on-prem/air-gapped environments.

Compose and deployment workflows

• Several people want a docker compose pussh equivalent that:
  • Reads the compose file on the remote host.
  • Pushes only the images actually used there.
  • Then restarts the compose stack.
• Current alternatives:
  • Manually pussh each image or script it (e.g., yq | xargs).
  • Use Docker contexts / DOCKER_HOST=ssh://... so images are built directly on the remote host via docker compose build/up.
• Debate:
  • Building on prod hosts is simple but can be resource-heavy and less “clean”.
  • Building once elsewhere and pushing identical artifacts to prod is preferred by some, especially in more formal CI/CD setups.

How it works vs existing tricks

• Traditional pattern: docker save | ssh | docker load (with or without compression) copies the entire image every time. Many users already rely on this but acknowledge it is inefficient for large images.
• Unregistry:
  • Starts a temporary container on the remote side, exposing the node’s containerd image store as a standard OCI registry.
  • Only missing layers are uploaded; existing layers on the server are reused.
  • Can also run standalone and be used with skopeo, crane, BuildKit, etc.
• Comparisons:
  • Podman has podman image scp, which is similar but integrated natively.
  • Other community tools like docker-pushmi-pullyu and custom reverse-tunnel scripts implement similar flows using the official registry image and SSH tunnels.

Use cases and benefits

• Attractive for:
  • Single-VM or small-cluster deployments (Hetzner VPS, homelabs, IoT devices) where running or paying for a registry is overkill.
  • On-prem or intermittently connected environments that don’t want internet-facing registries.
  • Faster deployment of very large images where only upper layers change.
• Some see it as a good fit for tools like Kamal or Uncloud, potentially removing the registry dependency and enabling “push-to-cluster” semantics.

Concerns, limitations, and extensions

• Requires Docker/containerd on the remote; for now it’s a deployment helper, not a full control plane.
• A few commenters are uneasy about running extra containers on production hosts, though the container is short-lived.
• Disaster recovery and large multi-region clusters are seen as better served by conventional registries; this is viewed more as a targeted, simplicity-first tool.
• Works conceptually with Kubernetes by running unregistry on a node and pulling via its registry endpoint; for full cluster image distribution, tools like Spegel are suggested.
• Image-signing and content-trust integrations are raised as an open question, with some related discussion referencing Docker Content Trust and cosign but no definitive answer for this tool yet.

Naming and ergonomics

• The pussh pun is widely appreciated but some worry it looks like a typo in CI/CD scripts; the plugin can be renamed to a clearer alias (e.g., docker pushoverssh) if desired.