Forem: DiPhyx

You Just Want Containers — Why Is Installing Docker & Podman Still This Hard?

Amir Reza Dalir — Mon, 23 Feb 2026 11:14:47 +0000

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

Eliminate 80% of Nuxt store boilerplate with a single createStore call

Amir Reza Dalir — Tue, 10 Feb 2026 20:00:29 +0000

Every Nuxt app has the same problem.

For every API resource — users, posts, products, orders — the same code gets written:

Define a TypeScript interface
Create reactive state (ref, reactive)
Create a loading ref
Create an error ref
Write a fetch function with try/catch/finally
Repeat for create, update, delete
Repeat for the next resource

Harlemify is an open-source Nuxt module by Diphyx that eliminates this repetition. It's built on top of Harlem, a powerful and extensible state management library for Vue 3 — so the reactive store layer is solid and battle-tested.

Define your data shape once, get everything else for free

Harlemify generates typed stores from Zod schemas. Here's what a full CRUD store looks like:

import { createStore, shape, ModelOneMode, ModelManyMode } from "@diphyx/harlemify/runtime";

const userShape = shape((factory) => {
    return {
        id: factory.number().meta({
            identifier: true,
        }),
        name: factory.string(),
        email: factory.email(),
    };
});

export const userStore = createStore({
    name: "users",
    model({ one, many }) {
        return {
            current: one(userShape),
            list: many(userShape),
        };
    },
    view({ from }) {
        return {
            user: from("current"),
            users: from("list"),
        };
    },
    action({ api }) {
        return {
            list: api.get(
                {
                    url: "/users",
                },
                { model: "list", mode: ModelManyMode.SET },
            ),
            get: api.get(
                {
                    url: "/users/:id",
                },
                { model: "current", mode: ModelOneMode.SET },
            ),
            create: api.post(
                {
                    url: "/users",
                },
                { model: "list", mode: ModelManyMode.ADD },
            ),
            delete: api.delete(
                {
                    url: "/users/:id",
                },
                { model: "list", mode: ModelManyMode.REMOVE },
            ),
        };
    },
});

No separate type definitions. No manual loading/error refs. No try/catch boilerplate.

What comes out of this single definition

Typed models — current holds a single user, list holds a collection. Both are fully typed from the Zod shape.

Reactive views — user and users are computed refs that update whenever the underlying model changes. Powered by Harlem's reactive store engine under the hood.

API actions with auto-commit — Each action knows which model to update and how (SET replaces, ADD appends, REMOVE deletes by identifier).

Automatic status tracking — Every action exposes loading, error, and status without writing a single ref.

Using it in components

<script setup>
const { execute, loading, error } = useStoreAction(userStore, "list");
const { data: users } = useStoreView(userStore, "users");

await execute();
</script>

<template>
    <p v-if="error">{{ error.message }}</p>
    <ul v-else-if="!loading">
        <li v-for="user in users" :key="user.id">{{ user.name }}</li>
    </ul>
</template>

Three composables cover everything:

useStoreAction — execute actions, track loading/error/status
useStoreView — access reactive computed state
useStoreModel — mutate state directly (set, patch, add, remove, reset)

Beyond basic state management

Concurrency control

Every action can be configured with a concurrency strategy:

BLOCK — throw if the action is already running
SKIP — return the existing promise
CANCEL — abort the previous call, start a new one
ALLOW — run both in parallel

No more debouncing hacks or manual AbortController wiring.

Record collections

For grouped data (e.g., users by team), use record mode:

model({ many }) {
    return {
        byTeam: many(userShape, { kind: ModelManyKind.RECORD }),
    };
},

This gives you { teamA: [...users], teamB: [...users] } with typed CRUD operations per key.

Handler actions

Not every action is an API call. Custom logic gets first-class support:

action({ handler }) {
    return {
        sortByName: handler(async ({ model }) => {
            const sorted = [...model.list].sort((a, b) => a.name.localeCompare(b.name));
            model.list = sorted;
        }),
    };
},

Handlers have full access to models and views, with the same status tracking as API actions.

SSR with automatic hydration

Harlemify uses Harlem's SSR plugin (@harlem/plugin-ssr) under the hood. Server-rendered state is automatically hydrated on the client — no manual transfer or serialization needed.

How it compares

	Manual / Pinia	Harlemify
Schema	Separate TypeScript interfaces	Zod shape — types + validation
API calls	Manual fetch + state updates	Declarative with auto-commit
Loading/error	Manual refs per action	Automatic per action
Concurrency	Not built-in	Block, Skip, Cancel, Allow
Collections	Manual array management	Built-in modes (SET, ADD, PATCH, REMOVE)
SSR	Plugin required	Built-in via Harlem SSR
Lines per resource	~50-60	~15-20

Harlemify is not a Pinia replacement. Pinia is great for general-purpose client state. Harlemify is built on top of Harlem and optimized for API-driven data — the CRUD resources that make up 80% of most apps.

Try it

npm install @diphyx/harlemify

// nuxt.config.ts
export default defineNuxtConfig({
    modules: ["@diphyx/harlemify"],
});

Feedback and contributions are welcome — star the repo if it's useful, or open an issue for anything that's missing.