It's 11 PM. Your deadline is tomorrow. The model is ready, the compose file is written, and all you need is docker compose up. But you're staring at a fresh Ubuntu VM and Docker isn't installed.
No problem, right? Just install it.
sudo apt-get install docker.io
Except the version in the repo is two years old. The docs say to add Docker's official repository. So you start adding GPG keys, configuring apt sources, updating package lists... fifteen minutes later, Docker is running. You pull your image, start the stack, and finally get to work.
That was the easy version. 😅
What if you could just type docker + podman and have it work — anywhere?
When the easy version doesn't exist
🔬 The researcher. You're on a university HPC cluster with a containerized pipeline — a deep learning training job, a genomics workflow, a physics simulation. You need Docker or Podman. But you don't have sudo. You can't install packages. The sysadmin takes days to respond to tickets. Your deadline doesn't care.
🧠 The ML engineer. You're spinning up GPU instances on a cloud provider. The VM comes with a minimal OS — no apt, no yum, no package manager at all. Just a kernel and a shell. You need Docker, but the official install script assumes you have a full distro underneath.
🔒 The restricted environment. You're working in a secure facility. The machines are air-gapped — no internet. You can transfer files in via USB, but every tool you need has to be bundled and self-contained.
🔀 The mixed-runtime team. Your team standardized on Podman for security reasons, but half your tooling still expects Docker. You need both, and switching between them shouldn't require reconfiguring everything.
These aren't edge cases. For researchers, data scientists, and engineers working outside the typical cloud-native setup — this is everyday reality.
The official path is paved, but narrow
Docker does provide a convenience script:
curl -fsSL https://get.docker.com | sh
It's well-maintained and it works. But it needs sudo. It needs a package manager. It needs internet access. It only supports specific distributions. And it only installs Docker — no Podman, no rootless mode out of the box.
For Podman, the story is worse. There's no get.podman.com. Your options are distro packages (often outdated, sometimes missing entirely) or building from source. That means cloning seven separate repositories — Podman itself, plus crun, conmon, netavark, aardvark-dns, slirp4netns, and fuse-overlayfs — and compiling Go, Rust, and C code. On a machine where you can't even sudo apt install gcc, that's a dead end. 🛑
And Compose? That's another installation step on top of everything else.
The tools exist. The documentation exists. But the path from "I need containers" to "I have containers" is full of assumptions about your environment that don't always hold.
Removing the assumptions
dockpod (docker + podman, quick setup) was built around a simple idea: installing a container runtime should work the same way everywhere.
curl -fsSL diphyx.github.io/dockpod/setup.sh | bash
dockpod install
That's the entire setup. An interactive menu asks which runtime you want — Docker, Podman, or both. Compose is included automatically with either choice. No sudo required. No package manager. No GPG keys. No repository configuration.
It works on any Linux system with kernel 4.18+ and systemd — which covers essentially every modern distro and cloud image. ✅
Under the hood
When you run dockpod install, it checks your system, detects your architecture, and pulls prebuilt static binaries — the same ones compiled from the official upstream sources. It places them in the right directories, writes configuration files, sets up systemd services, and verifies the installation by actually running a container.
🛡️ If you have root, binaries go to /usr/local/bin/ and services run system-wide. If you don't, everything goes into ~/.local/bin/ and runs as user-scoped systemd services. Docker uses its rootless mode, Podman works rootless natively. Either way, you end up with a fully working runtime without ever typing sudo.
🔌 Compose is included out of the box — installed as both a standalone docker-compose binary and a Docker CLI plugin (docker compose). When Podman is installed, dockpod creates a podman-compose symlink automatically, so your existing compose files work with either runtime:
docker compose up -d # with Docker
podman-compose up -d # with Podman — same file, no changes
🔀 Need both Docker and Podman? Install both, then switch between them instantly. Your compose files, your scripts, your muscle memory — everything stays the same. Only the engine underneath changes.
dockpod switch podman
dockpod switch docker
No internet? No problem
This is the part that matters most for restricted environments.
dockpod publishes architecture-specific tarballs with every release. Each one is self-contained — Docker, Podman, Compose, and all their dependencies bundled together. Nothing is downloaded during installation.
Grab the tarball on a connected machine, transfer it however you can — USB, scp, a shared drive — and install on the target without a single network call:
tar -xzf dockpod-v2.0.0-amd64.tar.gz && cd dockpod-v2.0.0-amd64
./dockpod.sh install --offline
For labs, secure facilities, and isolated clusters, this is often the only practical way to get containers running without a lengthy approval process.
Give it a try
If you've ever spent more time installing a container runtime than actually using it — that's exactly what dockpod is for.
If it saves you time, share it with your team, your lab, or that colleague who's still struggling to get containers running.
GitHub · MIT licensed · Built by DiPhyx
Top comments (0)