#podman

How to Safely Run Claude Code on Ubuntu 24.04

Let’s have a brutal engineering reality check about your AI terminal agents.

If you are switching users locally in your terminal using su, you are destroying your DBus session variables. If you aren't enabling loginctl enable-linger, the Linux kernel is mercilessly killing your rootless Podman containers the exact second you close your SSH client.

And if you haven't set a hard API billing limit? Claude Code is going to read your massive unoptimized repository in a loop and generate an API invoice that will genuinely ruin your week. It is not a flat-fee subscription.

At ServerMO, we just dropped the definitive SRE playbook for running Claude Code securely on Ubuntu bare metal. No SELinux hallucinations in our Quadlet configs—just pristine AppArmor execution, zombie-container prevention, and zero-amnesia headless authentication.

Container technology has revolutionized how we develop, deploy, and manage applications. When choosing between containerization tools, the Podman vs Docker debate often takes center stage. Both are powerful container management platforms, but they offer distinct approaches to containerization that can significantly impact your development workflow and production deployments.

Understanding the differences between these two technologies is crucial for making informed decisions about your container strategy. Whether you're a developer looking to streamline your workflow or a DevOps engineer planning enterprise deployments, this comprehensive comparison will help you navigate the key distinctions and choose the right tool for your needs.

Understanding Docker: The Container Pioneer

Docker emerged as the technology that popularized containerization, making it accessible to developers worldwide. It introduced a simple yet powerful way to package applications with their dependencies into lightweight, portable containers.

Docker's architecture centers around a client-server model with the Docker daemon running as a background service. This daemon manages containers, images, networks, and volumes, while the Docker CLI communicates with the daemon through REST APIs. The platform has become synonymous with containerization due to its user-friendly interface and extensive ecosystem.

Key features that made Docker popular include its straightforward command-line interface, comprehensive image registry (Docker Hub), and robust networking capabilities. Docker Compose allows developers to define multi-container applications using YAML files, while Docker Swarm provides basic orchestration capabilities for production deployments.

Introducing Podman: The Daemon-Free Alternative

Podman (Pod Manager) was developed by Red Hat as a daemonless alternative to Docker. It aims to provide similar functionality while addressing some of Docker's architectural limitations and security concerns.

The most significant difference lies in Podman's architecture. Unlike Docker, Podman doesn't require a central daemon running with root privileges. Instead, it uses a fork-exec model where each container runs as a child process of the Podman command. This approach eliminates single points of failure and reduces security risks associated with privileged daemon processes.

Podman maintains compatibility with Docker commands and Dockerfiles, making migration relatively straightforward. It also introduces the concept of pods, inspired by Kubernetes, allowing you to group related containers together with shared networking and storage.

Architecture Comparison: Daemon vs Daemonless

The architectural differences between Docker and Podman represent fundamentally different approaches to container management.

Docker's daemon-based architecture provides centralized management but comes with trade-offs. The Docker daemon runs with root privileges, creating potential security vulnerabilities. If the daemon fails, all running containers are affected. However, this centralized approach enables features like background container management and system-wide resource monitoring.

Podman's daemonless architecture offers enhanced security and stability. Without a central daemon, there's no single point of failure. Each container process runs with the user's privileges, improving security isolation. The fork-exec model means containers can outlive the Podman process that created them, providing better resilience.

This architectural difference impacts how each tool handles container lifecycle management, networking, and system integration. While Docker's daemon provides convenience features, Podman's approach aligns better with traditional Unix process models and security principles.

Security Considerations

Security represents one of the most significant differentiators between these platforms.

Docker's daemon runs with root privileges by default, which creates potential attack vectors. If an attacker compromises the Docker daemon, they gain root access to the host system. While Docker has introduced rootless mode, it's not the default configuration and has some limitations.

Podman was designed with security as a primary concern. It runs containers without requiring root privileges, using user namespaces to provide isolation. This rootless operation significantly reduces the attack surface. Additionally, Podman integrates with SELinux and other security frameworks more seamlessly than Docker.

For organizations prioritizing security, especially in multi-tenant environments, Podman's security model provides substantial advantages. However, Docker's security has improved over time, and proper configuration can mitigate many risks.

Performance and Resource Usage

Performance characteristics differ between the two platforms due to their architectural approaches.

Docker's daemon-based model can introduce slight overhead in certain scenarios, particularly when managing large numbers of containers. The daemon itself consumes system resources, and communication through the REST API adds minimal latency.

Podman's direct process model typically results in lower resource overhead since there's no persistent daemon consuming memory and CPU cycles. Container startup times can be slightly faster due to reduced layers of abstraction.

However, performance differences are often negligible in real-world applications. Both tools are optimized for container operations, and the choice between them rarely depends solely on performance considerations.

Ecosystem and Compatibility

Docker's mature ecosystem provides extensive tooling, integrations, and community support. Docker Hub hosts millions of container images, and most CI/CD platforms have native Docker integration. The Docker ecosystem includes Docker Desktop for local development, Docker Enterprise for production, and numerous third-party tools.

Podman maintains strong compatibility with Docker commands and workflows. Most Docker commands work identically with Podman, and existing Dockerfiles require no modifications. This compatibility reduces migration friction and allows teams to switch gradually.

However, some Docker-specific features may not have direct Podman equivalents. Docker Compose, while compatible with Podman, requires additional setup. The Podman ecosystem is growing but hasn't yet reached Docker's maturity level.

Use Cases and Recommendations

Choose Docker when you need:

Maximum ecosystem compatibility and tooling support

Docker Desktop for local development on Windows or macOS

Extensive CI/CD integrations and third-party tooling

Teams already invested in Docker workflows and knowledge

Choose Podman when you prioritize:

Enhanced security through rootless containers

Integration with systemd and traditional Linux service management

Kubernetes-compatible pod concepts for development

Red Hat Enterprise Linux environments where Podman is the default

Integration with Testing and Development Workflows

Modern container workflows require robust testing strategies to ensure application reliability. Both Docker and Podman integrate well with various testing frameworks and development tools.

Container testing often involves verifying application behavior across different environments and configurations. This is where specialized testing tools become valuable for maintaining code quality and reducing deployment risks.

For teams looking to enhance their container testing capabilities, Keploy offers innovative approaches to API testing and test generation that work seamlessly with both Docker and Podman environments, helping developers create more reliable containerized applications.

Conclusion

The choice between Podman and Docker depends on your specific requirements, security posture, and existing infrastructure. Docker remains the more mature option with broader ecosystem support, making it suitable for teams prioritizing compatibility and extensive tooling. Podman offers compelling advantages in security and system integration, particularly for Linux-centric environments.

What Docker Got Right

Docker revolutionized how we approached infrastructure. It swapped out traditional VMs for lightweight containers — portable, repeatable, and incredibly fast (at the time).

Between 2013 and 2018, Docker’s impact was undeniable:

Developers could Dockerize their apps and easily ship them.

CI/CD pipelines became simpler and more efficient.

Kubernetes adopted Docker as its default container runtime.

Nearly every developer had a Dockerfile in their project.

It worked — until it didn’t.

What Went Wrong?

1. The Docker Daemon Dilemma

Docker relies on a single, long-running process known as the Docker Daemon. This comes with a few big downsides:

Single Point of Failure: If the Daemon crashes, everything crashes.

Security Risks: Running the Daemon as root creates a major security vulnerability.

Debugging Nightmares: Killing the Daemon takes everything down, making debugging a pain.

Alternatives like containerd don’t have this central Daemon. They’re smaller, faster, and don’t require “God-mode” to operate.

Docker Run Exampledocker run nginx

With containerdctr run --rm docker.io/library/nginx:latest nginx /bin/sh

2. The Docker Desktop Paywall

Docker’s move to charge for Docker Desktop in enterprise environments was a major misstep. Teams started looking for alternatives like Podman, Rancher Desktop, and Colima. Developers don’t like surprises in their toolchain, and this was a big one.

3. Kubernetes Dropped Docker

Let’s clarify: Kubernetes didn’t abandon containers. It dropped Docker as a runtime, opting instead for containerd and CRI-O.

Why? Kubernetes prefers runtimes that natively implement the Container Runtime Interface (CRI). Docker doesn’t. The additional shim layers Docker needed to function with Kubernetes added unnecessary complexity.

UML Diagram: Container Lifecycle in Kubernetes Pre and Post Docker Deprecation

+------------------+ +------------------+ | kubelet | | kubelet | +--------+---------+ +--------+---------+ | | +-------v--------+ +---------v--------+ | Docker Daemon | | containerd / CRI-O| +-------+--------+ +---------+--------+ | | +----v-----+ +---v-----+ | container | | container | +----------+ +-----------+

4. Podman > Docker (for Most Use Cases)

Enter Podman — a more streamlined, feature-packed alternative to Docker:

Daemonless: No single long-running process.

Rootless: More secure.

Docker Command-Compatible: Just alias docker to podman, and you won’t even know the difference.

Docker Commanddocker build -t my-app .

Podman (same)podman build -t my-app .

You can even alias it for seamless integration:alias docker=podman

The result? Podman is faster, more secure, and just as easy to use.

What Should You Use Instead?

For Local Development: Try Podman, Colima, or NerdCTL. They’re lightweight, fast, and don’t require Docker Desktop.

For CI/CD Pipelines: Go with containerd. It’s more efficient, integrates better with Kubernetes, and avoids relying on a Daemon.

For Kubernetes Runtime: Choose CRI-O or containerd. They’re Kubernetes-native and don’t need extra layers.

For Desktop Users: Use Rancher Desktop (GUI) or Podman (CLI) as great alternatives.

Docker Hub? Yes, Docker Hub is still a major player in the world of image hosting. You can pull images from Docker Hub using tools like skopeo or ctr.

Example:skopeo copy docker://nginx:latest dir:/tmp/nginx

A Real-World Migration

We used Docker and Docker Compose for local development with multiple microservices. But we hit a few issues:

Inconsistent dev environments.

CI builds timing out due to Docker’s caching quirks.

Docker Desktop licensing problems.

What We Did:

Switched from Docker Compose to podman-compose.

Replaced Docker with nerdctl + containerd in CI.

Introduced Rancher Desktop for team members who needed a GUI.

Outcome?

CI builds were 30% faster.

No more licensing headaches.

The team adopted Podman with zero friction.

Conclusion

Docker isn’t dead, but it’s no longer the go-to solution for everything. Like jQuery — it was the best tool for a problem that’s now better solved by alternatives.

Containers have revolutionized software deployment by providing lightweight, portable, and scalable environments. Docker has long been the dominant containerization tool, simplifying the way developers package and distribute applications. However, Podman has emerged as a strong alternative, offering a daemonless and rootless approach to container management.

In this article, we’ll explore the differences between Podman vs Docker, comparing their features, security models, and use cases to help you determine which tool best suits your needs.

What is Docker?

Docker is a widely used containerization platform that allows developers to create, deploy, and manage containers efficiently. It provides a simple and consistent workflow for building containerized applications using images stored in registries such as Docker Hub.

Docker introduced containerization to the mainstream by offering an easy-to-use interface and a rich ecosystem of tools. It is built around a client-server architecture, where the Docker daemon (dockerd) runs in the background to manage container lifecycles.

What is Podman?

Podman is an open-source container management tool developed by Red Hat as a more secure alternative to Docker. It provides a daemonless and rootless approach, allowing users to run containers without requiring a central service.

Unlike Docker, which operates as a single daemon process, Podman runs containers as independent processes, making it more modular and reducing security risks. Podman is also fully compatible with the Open Container Initiative (OCI) standards, enabling seamless integration with Kubernetes and other container orchestration platforms.

Key Differences Between Podman and Docker

While both Podman and Docker enable container management, they have fundamental differences in their architecture, security model, and usability.

Daemon vs. Daemonless Architecture

Docker: Relies on a central daemon (dockerd) that runs as a background service, managing all container operations.

Podman: Is daemonless, meaning each container runs as an independent process. This eliminates a single point of failure and reduces security vulnerabilities.

Rootless Security Model

Docker: By default, requires root privileges to manage containers, making it a potential security risk in shared environments.

Podman: Supports rootless containers, allowing users to run containers without administrative privileges. This enhances security and reduces the risk of privilege escalation attacks.

CLI and Command Compatibility

Docker: Offers a well-known command-line interface (docker run, docker build, etc.) that developers are familiar with.

Podman: Maintains CLI compatibility with Docker, meaning most Docker commands work the same way in Podman. However, Podman does not natively support docker-compose, requiring additional tools like podman-compose for multi-container management.

Image Handling and Registries

Docker: Uses Docker Hub as its default registry and manages images through docker build and docker pull.

Podman: Also supports Docker Hub and other OCI-compliant registries but offers additional flexibility in managing local container images.

Container Management and Orchestration

Docker: Includes native support for Docker Swarm, a built-in container orchestration tool.

Podman: Integrates seamlessly with Kubernetes via podman generate kube, making it a preferred choice for Kubernetes-native workflows.

When to Use Docker

Docker remains the go-to choice for many developers and DevOps teams due to its widespread adoption and robust ecosystem. You should consider using Docker if:

You need a simple, all-in-one solution for container management.

Your workflow heavily relies on Docker Compose for multi-container applications.

You are already using Docker-based CI/CD pipelines and want to avoid additional configuration.

When to Use Podman

Podman is an excellent alternative for users looking for a secure and flexible container management solution. It is ideal for:

Organizations that prioritize security and want to run containers without root access.

Developers working in Kubernetes environments who need a seamless transition from local development to production.

Users who want a daemonless approach to container execution.

Conclusion

A ver, esto que explico es para Podman (supongo que en Docker tienen algo parecido, pero como ahora es de pago, ya no le dedico tiempo ni lo uso).

Aqui me estoy refiriendo a mover los datos del contenedor que no están en un volumen, para exportar el fileystem del contenedor se hace con podman export. Pero los datos del contenedor (sobre todo si es una BBDD esta alojada en un volumen externo). Obtener la información de cual es el volumen de ese contenedor:

podman container inspect nonprod "Type": "volume", "Name": "96ba830cfdc14f4758df5c7a06de5b716f4a415fecf1abdde3a27ebd989bd640", "Source": "/home/user/.local/share/containers/storage/volumes/2d062d3174a4a694427da5c102edf1731c5ca9f20e8ee7b229e04d4cb4a5bc69/_data", "Destination": "/var/lib/postgresql/data",

Vale, el volumen se llama "96ba830cfdc14f4758df5c7a06de5b716f4a415fecf1abdde3a27ebd989bd640".

Entramos por ssh en la máquina:

podman machine ssh --username user Connecting to vm podman-machine-default. To close connection, use ~. or exit Last login: Fri Jan 31 13:45:48 2025 from ::1 [user@MYCOMPUTER ~]$

Exportamos el contenido del volumen a un tar:

podman volume export 96ba830cfdc14f4758df5c7a06de5b716f4a415fecf1abdde3a27ebd989bd640 -o volume.tar

Como lo voy a hacer en local y no hay problemas de velocidad ni espacio, lo dejo así sin comprimir. Así me ahorro pasos. Pero si quereis compartirlo por red con otro ordenador o compañero pues le pasais un gzip o bzip2.

Me salgo.

exit

Ahora obtengo los datos de conexión de la máquina de podman para poder copiar el fichero al exterior usando SCP.

podman system connection list Name URI Identity Default ReadWrite podman-machine-default ssh://[email protected]:56086/run/user/1000/podman/podman.sock C:\Users\xmanoel.local\share\containers\podman\machine\machine true true podman-machine-default-root ssh://[email protected]:56086/run/podman/podman.sock C:\Users\xmanoel.local\share\containers\podman\machine\machine false true

De aqui lo importante es el fichero donde estan las idendidades y el puerto para hacer el SCP.

scp -i C:\Users\xmanoel.local\share\containers\podman\machine\machine -P 56086 user@localhost:~/volume.tar .

Ya esta, ya lo tenemos en la máquina local. Aquí lo puedes compartir con otro equipo, enviarlo por la red o lo que quieras. Ahora para crear otro contenedor vacío y usarlo para recibir los datos de este volumen...

podman run -d --name nonprod -p 5432:5432 postgres podman stop nonprod

Como veis lo creo pero inmediatamente lo detengo. No croe que sea buena idea tener ejecutando el contenedor cuando vamos a sobreescribir los datos.

Vemos cual era el volumen que se creó este contenedor: podman container inspect nonprod

"Type": "volume", "Name": "2d062d3174a4a694427da5c102edf1731c5ca9f20e8ee7b229e04d4cb4a5bc69", "Source": "/home/user/.local/share/containers/storage/volumes/2d062d3174a4a694427da5c102edf1731c5ca9f20e8ee7b229e04d4cb4a5bc69/_data", "Destination": "/var/lib/postgresql/data",

En este caos el volumen se llama "2d062d3174a4a694427da5c102edf1731c5ca9f20e8ee7b229e04d4cb4a5bc69". Pues ahora a la inversa. Una vez más vemos cual es el puerto y el fichero de identidad del podman:

podman system connection list Name URI Identity Default ReadWrite podman-machine-default ssh://[email protected]:56086/run/user/1000/podman/podman.sock C:\Users\xmanoel.local\share\containers\podman\machine\machine true true podman-machine-default-root ssh://[email protected]:56086/run/podman/podman.sock C:\Users\xmanoel.local\share\containers\podman\machine\machine false true

En este caso este paso no era necesario porque como veis estoy copiando de vuelta en mi propia máquina. Pero bueno, es que yo lo estoy haciendo de ejemplo. En vuestro caso esto lo tendríais que hacer en la otra máquina y os saldrían cosas diferentes. Copiamos el tar adentro. Que es la inversa de lo de antes:

scp -i C:\Users\xmanoel.local\share\containers\podman\machine\machine -P 56086 user@localhost:~/volume.tar . Y entramos otra vez con ssh.

podman machine ssh --username user Connecting to vm podman-machine-default. To close connection, use ~. or exit Last login: Fri Jan 31 16:21:41 2025 from ::1 [user@HEREWEARE ~]$

Y simplemente ahora es importar el contenido del tar en el volumen. Cuidado aquí porque claro, lo que va a pasar es que se va a cargar lo que haya en el volumen de antes. Por eso, si recordais hace un rato hemos creado un contenedor nuevo, para no fastidiar nada de lo existente. Si vosotros quereis expresamente reutilizar un volumen ya existente, pues ya sabeis ahí todo vuestro.

podman volume import 2d062d3174a4a694427da5c102edf1731c5ca9f20e8ee7b229e04d4cb4a5bc69 volume.tar

Ahora ya podemos salirnos:

exit

Y levantar el contenedor que habíamos creado. Ese contenedor ahora leerá el volumen que hemos importado, por tanto los datos que estaban en el contenedor inicial estarán dentro.

podman start nonprod

Y nada, espero que os sea util.