Podman: The Complete Guide to Rootless, Daemonless Containers

Podman is an open-source container engine designed to build, run, manage, and deploy OCI containers and pods. It provides a Docker-compatible CLI experience while taking a fundamentally different approach: Podman is daemonless and can run containers rootlessly as a regular Linux user.

For developers, DevOps engineers, SREs, platform engineers, and administrators, Podman is particularly interesting when you want containerization without depending on a permanently running privileged daemon.

---

1. What is Podman?

Podman originally stands for Pod Manager.

It provides commands for:

• Running containers
• Building images
• Managing images
• Managing pods
• Creating networks
• Managing volumes
• Running containers without root
• Integrating containers with systemd
• Running Kubernetes YAML locally
• Working with OCI-compatible images and runtimes

A major design characteristic is that Podman is daemonless. Unlike the traditional Docker architecture, there isn't a central Docker daemon that all local container operations must go through.

Conceptually:

Traditional Docker-style model

User
  |
  v
Docker CLI
  |
  v
Docker Daemon
  |
  +---- Container
  +---- Container
  +---- Image
  +---- Network

Podman:

User
  |
  v
Podman CLI
  |
  +---- Container
  +---- Container
  +---- Pod
  +---- Image
  +---- Network

That architectural difference becomes especially important for rootless containers and systemd-based deployments.

---

2. Podman vs Docker

HashiCorp Nomad: A Comprehensive Guide to Workload Orchestration

HashiCorp Nomad is a distributed workload orchestrator designed to deploy and manage containers, batch jobs, long-running services, legacy applications, and other workloads across clusters of machines.

If Docker answers:

“How do I run this container?”

and Kubernetes answers:

“How do I orchestrate containers across a cluster?”

Nomad takes a somewhat broader and simpler approach:

“How do I schedule and operate different kinds of workloads across my infrastructure?”

Nomad can run Docker containers, binaries, Java applications, QEMU workloads, and other task-driver-based workloads. HashiCorp describes it as a highly available, distributed, datacenter-aware scheduler designed for services, batch jobs, and more.

---

1. What Is HashiCorp Nomad?

Nomad is a cluster scheduler and workload orchestrator developed by HashiCorp.

Its core responsibilities include:

• Scheduling workloads
• Allocating CPU and memory
• Placing workloads on appropriate nodes
• Running long-lived services
• Running batch jobs
• Running jobs on every node
• Handling workload failures
• Rolling out updates
• Managing task lifecycle
• Service registration
• Integrating with Consul
• Integrating with Vault
• Supporting multiple datacenters
• Supporting heterogeneous workloads

A simplified architecture is:

                    NOMAD
                      │
             ┌────────┴────────┐
             │                 │
        Nomad Servers      Nomad Clients
             │                 │
        Scheduling         Run workloads
        Cluster State      Containers
        Coordination       Binaries
             │             Batch jobs
             │             Services
             ▼
          Allocations

Nomad's servers handle scheduling and cluster management, while clients execute the workloads assigned to them.

---

2. Why Nomad?

Traditional application deployment might look like:

Server 1 → Application A
Server 2 → Application B
Server 3 → Application C
Server 4 → Application D

As infrastructure grows, you need to answer:

• Where should an application run?
• Does the server have enough CPU?
• Does it have enough memory?
• Does it have the required runtime?
• What happens if the server fails?
• How do we deploy five copies?
• How do we update them?
• How do we run a job every night?
• How do we deploy something to every node?
• How do services discover each other?

Nomad provides a scheduling and reconciliation layer.

Desired State
      │
      ▼
   Nomad Job
      │
      ▼
   Scheduler
      │
      ▼
 Allocation Plan
      │
      ▼
 Nomad Clients
      │
      ▼
 Workloads

---

3. Nomad vs Kubernetes

Kubernetes: A Comprehensive Guide to Containers, Pods, Deployments, Services, Networking, Storage, Security & Production

 Kubernetes has become one of the most widely used platforms for running containerized applications at scale.

Docker makes it relatively easy to build and run containers.

Kubernetes answers the much larger question:

What happens when you have hundreds or thousands of containers running across multiple servers and those applications need to be deployed, scaled, monitored, updated, and recovered automatically?

Kubernetes provides an orchestration layer for that problem.

This guide starts with the fundamentals and progresses toward production architecture, networking, storage, security, troubleshooting, and real-world deployment patterns.

---

1. What Is Kubernetes?

Kubernetes, often abbreviated as K8s, is an open-source container orchestration platform.

It helps automate:

• Container deployment
• Scheduling
• Scaling
• Service discovery
• Load balancing
• Rolling updates
• Rollbacks
• Self-healing
• Configuration management
• Secret management
• Storage orchestration
• Workload placement

Without Kubernetes, you might manually manage:

Server 1
 ├── Container A
 ├── Container B
 └── Container C

Server 2
 ├── Container D
 ├── Container E
 └── Container F

Server 3
 ├── Container G
 └── Container H

Kubernetes turns this into a cluster that can manage workloads declaratively.

                  Kubernetes Cluster
                         │
        ┌────────────────┼────────────────┐
        ▼                ▼                ▼
      Node 1            Node 2            Node 3
        │                │                │
      Pods             Pods             Pods

---

2. Why Do We Need Kubernetes?

Imagine you have an application with:

Frontend
Backend API
Authentication
Payment
Redis
PostgreSQL
Kafka
Workers
Monitoring

Initially you might run:

10 containers

Then your application grows:

100 containers

Eventually:

1,000+ containers

Now several questions appear:

• Which server should run each container?
• What happens if a server fails?
• What happens if a container crashes?
• How do we deploy a new application version?
• How do we roll back?
• How do we expose applications to users?
• How do containers discover each other?
• How do we scale based on traffic?
• How do we manage configuration?
• How do we attach persistent storage?

Kubernetes automates many of these operations.

---

3. Kubernetes vs Docker

This distinction is extremely important.

Docker

Docker primarily provides container tooling:

Build image
    ↓
Store image
    ↓
Run container

Kubernetes

Kubernetes orchestrates containerized workloads:

Deploy
   ↓
Schedule
   ↓
Run
   ↓
Monitor
   ↓
Scale
   ↓
Replace failed workloads
   ↓
Update
   ↓
Rollback

A simplified relationship:

Docker / Build Tools
        │
        ▼
Container Image
        │
        ▼
Container Runtime
        │
        ▼
Kubernetes
        │
        ├── Scheduling
        ├── Networking
        ├── Scaling
        ├── Storage
        ├── Self-healing
        └── Deployments

Modern Kubernetes clusters commonly use containerd or another Kubernetes-compatible container runtime. Docker Engine itself is no longer required as Kubernetes' runtime.

---

4. Kubernetes Architecture

A Kubernetes cluster has two major conceptual parts:

Control Plane
      │
      ▼
Worker Nodes

For example:

                 Kubernetes Cluster
                         │
              ┌──────────┴──────────┐
              │                     │
         Control Plane          Worker Nodes
              │              ┌──────┼──────┐
              │              │      │      │
              ▼              ▼      ▼      ▼
         API Server         Node   Node   Node
         etcd
         Scheduler
         Controllers

---

5. Control Plane

Docker: A Comprehensive Guide to Containers, Images, Dockerfiles, Networking, Volumes, Compose, Security & Production

Docker has fundamentally changed how applications are developed, packaged, deployed, and operated.

Before containers became mainstream, deploying an application often meant dealing with differences between development, testing, staging, and production environments:

“It works on my machine.”

Docker's answer is simple:

Package the application together with its dependencies and run it consistently wherever Docker is available.

But Docker is much more than a command-line tool for running containers. It is an ecosystem involving images, containers, registries, networking, storage, Dockerfiles, Docker Compose, security, resource management, observability, and deployment strategies.

This guide takes you from Docker fundamentals to production-oriented concepts.

---

1. What Is Docker?

Docker is a platform for developing, packaging, distributing, and running applications using containers.

A container packages:

• Application code
• Runtime
• Libraries
• System utilities
• Configuration
• Dependencies

into an isolated execution environment.

Unlike a traditional virtual machine, a container normally does not contain an entire guest operating system.

Traditional VM

Physical Server
│
├── Hypervisor
│
├── VM 1
│   ├── Guest OS
│   └── Application
│
├── VM 2
│   ├── Guest OS
│   └── Application
│
└── VM 3
    ├── Guest OS
    └── Application

Docker containers

Physical Server
│
├── Linux Kernel
│
├── Docker Engine
│
├── Container 1
│   └── Application
│
├── Container 2
│   └── Application
│
└── Container 3
    └── Application

Containers share the host kernel, which generally makes them lighter and faster to start than full virtual machines.

---

2. Why Docker Became So Popular

Consider a Python application.

Your developer has:

Python 3.12
Flask 3.x
Requests
NumPy
PostgreSQL client

But production has:

Python 3.10
Older libraries
Different OS packages
Different environment variables
Different system configuration

The application works perfectly in development but fails in production.

Docker lets you define the environment explicitly.

Application
     +
Dependencies
     +
Runtime
     +
Configuration
     ↓
Docker Image
     ↓
Container

The same image can then be used across environments.

Developer Laptop
       ↓
      Test
       ↓
    Staging
       ↓
   Production

This improves consistency and simplifies deployment.

---

3. Docker vs Virtual Machines

Docker containers and virtual machines solve related but different problems.

Feature	Containers	Virtual Machines
Virtualization	OS-level	Hardware-level
Guest OS	Usually no	Yes
Startup	Usually seconds or less	Usually slower
Resource overhead	Low	Higher
Isolation	Process/kernel mechanisms	Stronger hardware/OS boundary
Density	High	Lower
Typical use	Microservices, CI/CD, applications	Full OS isolation, legacy workloads

A container is not simply a lightweight VM.

That distinction matters.

---

4. Docker Architecture

The Docker ecosystem can be understood through several components.

                 Docker CLI
                    │
                    ▼
              Docker Engine
                    │
          ┌─────────┼─────────┐
          ▼         ▼         ▼
       Images   Containers  Networks
                    │
                    ▼
                 Volumes

The major pieces are:

Docker CLI

The command-line interface used to interact with Docker.

Example:

docker ps

Docker Engine

The engine responsible for creating and managing containers, images, networks, volumes, and related resources.

Docker Image

A read-only template used to create containers.

Docker Container

A running or stopped instance created from an image.

Docker Registry

A repository for storing and distributing images.

Examples include Docker Hub and private registries.

Docker Compose

A tool for defining and running multi-container applications.

---

5. Docker Images

A Docker image is essentially a packaged filesystem and metadata used to create containers.

For example:

ubuntu
nginx
redis
postgres
python
node

You can download an image using:

docker pull nginx

Then list images:

docker images

or:

docker image ls

---

6. Image Layers

Build Your Own Local AI Coding Agent: A Complete Multi-Platform Development System

 Imagine telling your computer:

“Build me a Python application, test it, fix the errors and package it.”

Or:

“Create an Android application and generate the APK.”

Or even:

“Build this .NET application for Windows.”

Instead of sending your source code to a cloud AI service, you could have your own local AI coding agent running on your computer.

The agent can understand requirements, write code, execute commands, run tests, debug errors, build applications and manage Git repositories.

Even better, the system can support multiple programming languages and platforms.

The practical way to build such a system is to use Windows as the host, an Ubuntu virtual machine as the development environment, local AI through Ollama, and specialized build machines for Windows and Apple platforms.

The Architecture

The overall architecture looks like this:

                         WINDOWS 11 PRO
                              │
              ┌───────────────┴────────────────┐
              │                                │
         NVIDIA GPU                       Windows Tools
              │                                │
           Ollama                    Visual Studio / MSBuild
              │                                │
              └──────────────┬─────────────────┘
                             │
                       Hyper-V Network
                             │
                    ┌────────▼────────┐
                    │   UBUNTU VM    │
                    │                │
                    │ OpenHands      │
                    │ Cline          │
                    │ Aider          │
                    │ Docker         │
                    │ Git            │
                    │ Python         │
                    │ Java           │
                    │ .NET           │
                    │ C/C++          │
                    │ Rust           │
                    │ Go             │
                    │ Node.js        │
                    │ Android        │
                    │ Flutter        │
                    └────────┬───────┘
                             │
                             │ SSH
                             ▼
                       OPTIONAL MAC
                             │
                       Xcode / Swift
                             │
                         iOS / macOS

This architecture separates AI, development and platform-specific compilation.

That separation is important.

Linux does not need to do everything.

Why Use an Ubuntu VM?

You could install everything directly on Windows, but a dedicated Linux development environment provides several advantages.

Ubuntu gives you:

• A clean development environment
• Native Linux tooling
• Docker
• Python
• Java
• C/C++
• Rust
• Go
• Node.js
• .NET
• Android development
• Flutter
• Linux builds
• Easy automation
• Easier agent sandboxing

Most importantly, the AI agent can operate inside a controlled environment without modifying your main Windows installation.

Your Windows machine remains your everyday desktop.

Ubuntu becomes your AI software factory.

Windows Remains Your Main Desktop

You don't have to sit inside the Ubuntu desktop all day.

Install VS Code on Windows and connect to Ubuntu using Remote SSH.

The experience looks like this:

Windows
   │
   ▼
VS Code
   │
   ▼
Ubuntu VM
   │
   ├── Source code
   ├── Git
   ├── Docker
   ├── Compilers
   └── AI agents

You see the familiar Windows VS Code interface.

But the code executes inside Ubuntu.

This gives you the best of both worlds.

Step 1: Enable Hyper-V

Windows 11 Pro includes Hyper-V.

Open PowerShell as Administrator and run:

Enable-WindowsOptionalFeature `
    -Online `
    -FeatureName Microsoft-Hyper-V `
    -All

Restart Windows after installation.

Then open:

Hyper-V Manager

Hyper-V will be the virtualization layer for your Ubuntu development machine.

Step 2: Create a Virtual Network

Open:

Hyper-V Manager
→ Virtual Switch Manager

Create an:

External Virtual Switch

Name it:

DevAgentSwitch

Connect it to your physical Ethernet or Wi-Fi adapter.

This allows your Ubuntu VM to communicate with:

• Windows
• Ollama
• Other computers
• Build servers
• Future Mac machines

Step 3: Create the Ubuntu VM

Download the current Ubuntu LTS desktop ISO.

Create a new Hyper-V VM with approximately:

Resource	Recommended
Generation	Generation 2
CPU	12 virtual CPUs
RAM	32 GB
Disk	500 GB
Network	DevAgentSwitch
OS	Ubuntu LTS

If your system has 64 GB RAM, 32 GB allocated to the development VM is a good starting point.

You can change the allocation later.

Step 4: Install Ubuntu

Install Ubuntu normally.

A simple hostname is:

localdev

After installation:

sudo apt update
sudo apt upgrade -y

Reboot:

sudo reboot

Verify the resources:

nproc
free -h
df -h

Step 5: Enable SSH

SSH allows Windows to access Ubuntu directly.

Inside Ubuntu:

sudo apt install -y openssh-server

Enable the service:

sudo systemctl enable --now ssh

Find the Ubuntu IP:

hostname -I

For example:

192.168.1.50

From Windows PowerShell:

ssh dev@192.168.1.50

Now you can control Ubuntu directly from Windows.

Step 6: Use VS Code From Windows

Install VS Code on Windows and add the:

Remote - SSH

extension.

Connect to:

dev@192.168.1.50

Now your workflow becomes:

Windows Desktop
      ↓
VS Code
      ↓
Ubuntu VM
      ↓
Development Environment

You can open, edit, compile and test Linux projects without leaving Windows.

Step 7: Install Docker

Docker is critical because it allows the AI agent to work in isolated environments.

Install Docker Engine and Compose in Ubuntu.

After installation:

docker run hello-world

The objective is to eventually have separate development environments such as:

Python container
Java container
Node container
.NET container
Rust container
C++ container
Android container

This prevents dependencies from different projects from interfering with each other.

Step 8: Keep Ollama on Windows

This is an important architectural decision.

Your NVIDIA GPU is physically installed in the Windows machine.

Instead of making GPU passthrough work inside Hyper-V, initially keep Ollama on Windows.

The architecture becomes:

                NVIDIA GPU
                    │
                    ▼
               Windows
                 Ollama
                    │
                    │ HTTP
                    ▼
              Ubuntu VM
                    │
                OpenHands

This is considerably simpler than configuring GPU passthrough.

Install Ollama on Windows and download a suitable coding model.

For example:

ollama run qwen3-coder:30b

The exact model/quantization you choose should depend on your available VRAM and system RAM.

Step 9: Connect Ubuntu to Ollama

The Ubuntu VM needs to communicate with Ollama running on Windows.

Conceptually:

Ubuntu
  │
  │ HTTP
  ▼
Windows:11434
  │
  ▼
Ollama
  │
  ▼
NVIDIA GPU

From Ubuntu, test the connection:

curl http://WINDOWS_IP:11434/api/tags

If the connection works, Ubuntu can use the Windows-hosted local model.

Do not expose Ollama's port to the public internet.

Keep it restricted to your private network.

Step 10: Install OpenHands

OpenHands will become the primary autonomous coding agent.

Install the required Python environment and OpenHands inside Ubuntu.

The resulting workflow is:

User
  ↓
OpenHands
  ↓
Local LLM
  ↓
Planning
  ↓
Code generation
  ↓
Terminal commands
  ↓
Testing
  ↓
Debugging
  ↓
Build

Unlike a simple autocomplete tool, an agent can perform multiple actions to accomplish a task.

Step 11: Add Cline

Cline can be used from VS Code for interactive development.

This gives you two different working modes:

OpenHands

Best for:

Autonomous tasks
Large projects
Long-running workflows
Testing
Debugging
Automation

Cline

Best for:

Interactive coding
Working directly inside VS Code
Reviewing changes
Making targeted modifications

You can connect both to your local Ollama instance.

Step 12: Add Aider

Aider gives you a powerful terminal-based interface.

For example:

aider --model ollama_chat/qwen3-coder:30b

You now have three interfaces:

              Local LLM
                  │
        ┌─────────┼─────────┐
        │         │         │
     OpenHands  Cline     Aider
        │         │         │
        └─────────┼─────────┘
                  │
              Git Project

Step 13: Install Programming Languages

The Ubuntu VM can become your universal development environment.

Install:

Python

sudo apt install python3 python3-venv python3-pip

Java

sudo apt install openjdk-21-jdk maven gradle

C/C++

sudo apt install build-essential gcc g++ clang cmake ninja-build

Go

sudo apt install golang-go

Rust

sudo apt install rustc cargo

Node.js

Install a current Node.js LTS environment.

.NET

Install the appropriate .NET SDK for the Ubuntu release.

The result is a single environment capable of working with:

Python
Java
Kotlin
C
C++
C#
.NET
Go
Rust
JavaScript
TypeScript
PHP
Ruby
and many others

Step 14: Android Development

Android is one of the major advantages of using Linux.

Install:

Android Studio
Android SDK
Android SDK Platform Tools
Android Emulator
Gradle

Then verify:

adb devices

The AI agent can eventually perform:

Generate project
      ↓
Write code
      ↓
Compile APK
      ↓
Launch emulator
      ↓
Install APK
      ↓
Run tests
      ↓
Read logcat
      ↓
Fix bugs
      ↓
Build final APK

This is where the system starts becoming genuinely autonomous.

Step 15: Flutter

Flutter is another important component.

A single Flutter project can target multiple platforms:

Android
iOS
Windows
Linux
macOS
Web

Linux can handle Android and Linux builds.

Windows can handle Windows builds.

A Mac can handle iOS and macOS builds.

This makes Flutter an excellent framework for the agent to use when cross-platform applications are required.

Step 16: Windows Application Builds

Your Windows host can act as the Windows build machine.

Install:

Visual Studio
MSBuild
Windows SDK
.NET SDK
CMake
Flutter

The architecture becomes:

Ubuntu Agent
      │
      │ Build request
      ▼
Windows Host
      │
      ▼
MSBuild / Visual Studio
      │
      ▼
EXE / MSIX

This means the AI can write code in Ubuntu while the native Windows toolchain performs the final build.

Step 17: macOS and iPhone

Apple platforms are different.

For genuine iOS/macOS builds, you eventually need a Mac running macOS and Xcode.

The architecture becomes:

Ubuntu
   │
   │ SSH
   ▼
Mac
   │
   ├── Xcode
   ├── Swift
   ├── CocoaPods
   └── iOS Simulator
          │
          ▼
       iOS build

The Mac doesn't need to run the AI.

It simply becomes your Apple build worker.

The Complete Build Pipeline

Once everything is implemented, a request such as:

Build an expense management application for Android and Windows.

could become:

USER REQUEST
     │
     ▼
AI PLANNER
     │
     ▼
Architecture
     │
     ▼
Technology Selection
     │
     ▼
CODE GENERATOR
     │
     ▼
Git Repository
     │
     ▼
Implementation
     │
     ▼
UNIT TESTS
     │
     ▼
BUILD
     │
 ┌───┴────┐
 │        │
Android  Windows
 │        │
 ▼        ▼
APK      EXE
 │        │
 └───┬────┘
     ▼
INTEGRATION TESTS
     │
     ▼
SECURITY REVIEW
     │
     ▼
DOCUMENTATION
     │
     ▼
RELEASE ARTIFACTS

The AI becomes more than a code generator.

It becomes a software engineering system.

The Project Structure

A useful directory structure is:

~/local-agent/

├── core/
│   ├── planner/
│   ├── coder/
│   ├── reviewer/
│   ├── debugger/
│   └── tester/
│
├── orchestrator/
│
├── builders/
│   ├── linux/
│   ├── windows/
│   ├── android/
│   └── macos/
│
├── runtimes/
│   ├── python/
│   ├── java/
│   ├── dotnet/
│   ├── node/
│   ├── rust/
│   └── cpp/
│
├── projects/
├── artifacts/
├── logs/
└── config/

This gives us a foundation for building a custom orchestration layer.

Add Git to Everything

Every project should be managed through Git.

The agent should follow a workflow such as:

Create branch
     ↓
Understand project
     ↓
Modify code
     ↓
Run formatter
     ↓
Run tests
     ↓
Build
     ↓
Review diff
     ↓
Commit

You should never allow an autonomous agent to blindly modify your only copy of a project.

Git becomes the safety net.

Add Agent Rules

Every repository can contain an AGENTS.md file.

For example:

Before modifying code:

1. Read the project documentation.
2. Inspect the existing architecture.
3. Do not delete working functionality unnecessarily.
4. Create a Git branch.
5. Implement the requested change.
6. Run formatting.
7. Run static analysis.
8. Run unit tests.
9. Build the application.
10. Fix failures.
11. Review the Git diff.
12. Commit only when validation succeeds.

This makes agent behavior considerably more predictable.

The Final System

Ultimately your computer becomes a local development platform:

                       LOCAL AI SOFTWARE FACTORY

                              USER
                               │
                               ▼
                        WEB DASHBOARD
                               │
                               ▼
                         AI ORCHESTRATOR
                               │
               ┌───────────────┼────────────────┐
               │               │                │
            Planner          Coder           Reviewer
               │               │                │
               └───────────────┼────────────────┘
                               │
                         Local LLM
                          Ollama
                               │
                               ▼
                         OpenHands
                               │
                     ┌─────────┴─────────┐
                     │                   │
                  Docker               Git
                     │                   │
                     ▼                   ▼
              Development             Repository
              environments
                     │
        ┌────────────┼─────────────┐
        │            │             │
      Linux       Windows         Mac
        │            │             │
      Build        Build          Xcode
        │            │             │
       APK         EXE           IPA

What Makes This Different?

A normal AI coding assistant might give you:

code

A local coding agent can potentially give you:

requirements
→ architecture
→ source code
→ dependencies
→ tests
→ debugging
→ builds
→ artifacts
→ documentation

And because the entire development environment can remain local, your source code and internal projects don't have to be sent to a third-party AI API.