A container runtime should run containers. That is the entire job. It should not run a persistent background daemon with root access. It should not embed an AI agent that phones home to cloud servers. It should not collect telemetry on how you use it. It should not require a paid license for the basic act of running a container.

Podman does the job and nothing else.

What Podman Is

Podman is an open source container engine that runs OCI-compliant container images. Same images. Same registries. Same Dockerfile format. Same CLI commands you already know. It was built by Red Hat and is developed by a broad open source community under the Apache 2.0 license.

But the architecture is different from what most developers are used to. And those differences matter for privacy, security, and ownership of your own machine.

No Daemon

Podman has no background process. There is no service running on boot. When you start a container, Podman forks a process directly. When the container stops, the process exits. Nothing sits in the background waiting. Nothing persists between commands. Nothing phones home. There is nothing to phone home from.

This is the fork-exec model. You run a command, it executes, it finishes. No long-running process with elevated access sitting between you and your work. No central broker that routes every container operation through a single service. No intermediary that can be instrumented, logged, or used as a telemetry collection point.

When Podman is not running containers, Podman is not running. Period.

Rootless by Default

Podman runs containers as your regular user account. No root. No elevated privileges. No hypervisor VM with broad filesystem access. Your containers run in a user namespace with only the permissions you already have.

This is not an optional configuration. It is the default. Out of the box, Podman does not ask for root and does not need it. Your containers are isolated to your user account’s permissions. If a container is compromised, the attacker has the privileges of an unprivileged user. Not root. Not the system.

Security teams have spent decades telling developers to follow the principle of least privilege. Podman actually implements it at the container runtime level. The secure choice is the default choice. That distinction matters because defaults are what ship.

No Telemetry

Podman does not phone home. There is no analytics collection. No usage reporting. No AI agent embedded in the runtime. No network connections to vendor servers. It runs your containers and does nothing else.

In 2026 that should be unremarkable. It is practically revolutionary. Developer tools have become surveillance platforms. Container runtimes shipping with AI agents that communicate with cloud backends. Package managers collecting usage data. IDEs tracking every keystroke. The bar has dropped so low that “does not spy on you” is now a feature.

Podman does not spy on you. It never has. There is no opt-out because there is nothing to opt out of.

Genuinely Open Source

Podman is Apache 2.0 licensed. No dual licensing. No enterprise-only features behind a paywall. No licensing change that turns your workflow into a subscription two years from now. The same tool works for a solo developer and a Fortune 500 company. No sales call required.

Red Hat contributes heavily to Podman’s development, but the project is not locked to Red Hat. It runs on Fedora, Ubuntu, Debian, Arch, macOS, and Windows. The codebase is public. The roadmap is public. The governance is open.

When a company changes their container runtime’s licensing terms and suddenly every organization over a certain size owes them money, Podman users are unaffected. Because the license was never the product. The tool is the product.

Getting Started

Install on macOS

brew install podman

On macOS, Podman uses a lightweight Linux VM for running Linux containers. You initialize it once and start it when you need it.

podman machine init
podman machine start

Install on Linux

Podman is in the default repositories for most distributions. No VM needed. Containers run natively.

# Fedora / RHEL
sudo dnf install podman

# Ubuntu / Debian
sudo apt install podman

Run a container

podman run -d -p 8080:80 nginx

Same syntax. Same images. Same result. Except no root daemon sitting in the background and no AI agent phoning home to anyone.

Build from a Dockerfile

podman build -t myapp .

Podman reads Dockerfiles natively. Your existing images, your existing build scripts, your existing workflows. The migration is a tool swap, not a rewrite.

Alias it

alias docker=podman

Scripts, CI pipelines, muscle memory. Everything that calls docker now calls podman. No other changes required.

Podman Compose

Multi-container setups defined in a YAML file work with podman-compose, a drop-in replacement that reads the same docker-compose.yml files.

pip install podman-compose
podman-compose up -d

Same file. Same syntax. No daemon underneath.

Pods

Podman has a concept that most container runtimes do not: pods. A pod is a group of containers that share the same network namespace. They can talk to each other on localhost. If you run a web application with a database, put them in a pod. They communicate directly without exposing ports to the host.

podman pod create --name myapp -p 8080:80
podman run --pod myapp -d nginx
podman run --pod myapp -d postgres

This is the same pod concept used in Kubernetes. If you are building containers that will eventually run in a cluster, Podman lets you develop with the same architecture locally. No Kubernetes install required.

Running on a Server

Podman is not just a local development tool. It runs production workloads on servers the same way it runs containers on your laptop. On Linux there is no VM layer. Containers run natively on the host kernel. Install it, run your containers, done.

systemd integration

Podman generates systemd unit files directly from running containers. You do not need to write them by hand. Run your container, then tell Podman to create the service file.

podman run -d --name webapp -p 8080:80 myapp:latest
podman generate systemd --new --name webapp > ~/.config/systemd/user/webapp.service
systemctl --user enable --now webapp.service

The container starts on boot, restarts on failure, and is managed by systemd like any other service. No daemon required. No orchestration layer. Just systemd doing what it already does.

For rootful services that need to start before any user logs in, generate the unit file under /etc/systemd/system/ and manage it with systemctl without the --user flag.

Auto-updates

Podman has built-in auto-update support. Label a container with io.containers.autoupdate=registry and Podman will check the registry for a newer image, pull it, and restart the container automatically.

podman run -d --name webapp \
  --label io.containers.autoupdate=registry \
  -p 8080:80 myapp:latest

podman auto-update

Set that on a systemd timer or a cron job and your server pulls updated images without manual intervention. If the new image fails health checks, Podman rolls back to the previous version.

No daemon on the server either

The same architecture that makes Podman clean on a developer machine makes it clean on a server. No long-running daemon consuming resources when nothing is happening. No single point of failure that takes down every container if it crashes. Each container is its own process, managed by the init system your server already runs.

If you are running containers on your own hardware, whether a VPS, a dedicated server, or a mini PC in your office, Podman gives you production container management without adding a surveillance layer to your infrastructure. Your server. Your containers. Nothing phoning home.

The Principle

Your machine is yours. Whether it is a laptop on your desk or a server in a rack. The tools you run on it should respect that. They should do the job you installed them for and nothing else. No background daemons. No telemetry. No AI agents. No licensing surprises.

Podman runs containers. That is all it does. And that is exactly what it should do.

Run your containers. Own your machine. Use Podman.