Top Related Projects
:warning: This repository is deprecated and will be archived (Docker CE itself is NOT deprecated) see the https://github.com/docker/docker-ce/blob/master/README.md :warning:
The Moby Project - a collaborative project for the container ecosystem to assemble container-based systems
An open and reliable container runtime
Production-Grade Container Scheduling and Management
CLI tool for spawning and running containers according to the OCI specification
Complete container management platform
Quick Overview
Podman is an open-source container engine for developing, managing, and running OCI Containers on Linux systems. It provides a daemonless container engine that can be used as an alternative to Docker, offering similar functionality without requiring root privileges for most operations.
Pros
- Rootless containers: Podman can run containers without root privileges, enhancing security
- Daemonless architecture: No need for a persistent daemon process, reducing system overhead
- Docker-compatible CLI: Easy transition for users familiar with Docker commands
- Support for pods: Can manage groups of containers as a single unit, similar to Kubernetes pods
Cons
- Limited Windows support: Primarily designed for Linux systems, with limited functionality on Windows
- Ecosystem maturity: Smaller ecosystem compared to Docker, with fewer tools and integrations
- Learning curve: Despite Docker compatibility, some concepts and features are unique to Podman
- Performance: In some scenarios, may have slightly lower performance compared to Docker
Getting Started
To get started with Podman, follow these steps:
- Install Podman on your Linux system:
# For Fedora/CentOS/RHEL
sudo dnf install podman
# For Ubuntu
sudo apt-get update
sudo apt-get install -y software-properties-common
sudo add-apt-repository -y ppa:projectatomic/ppa
sudo apt-get install -y podman
- Verify the installation:
podman --version
- Run your first container:
podman run -d --name my-nginx -p 8080:80 nginx
- Check running containers:
podman ps
- Stop and remove the container:
podman stop my-nginx
podman rm my-nginx
For more advanced usage and features, refer to the official Podman documentation.
Competitor Comparisons
:warning: This repository is deprecated and will be archived (Docker CE itself is NOT deprecated) see the https://github.com/docker/docker-ce/blob/master/README.md :warning:
Pros of Docker CE
- Larger ecosystem and wider adoption, leading to more resources and community support
- More extensive documentation and tutorials available
- Better integration with cloud services and orchestration tools
Cons of Docker CE
- Requires root privileges for many operations, potentially increasing security risks
- More resource-intensive due to its daemon-based architecture
- Less focus on security features compared to Podman
Code Comparison
Podman:
podman run -it --name mycontainer ubuntu /bin/bash
podman ps
podman stop mycontainer
podman rm mycontainer
Docker CE:
docker run -it --name mycontainer ubuntu /bin/bash
docker ps
docker stop mycontainer
docker rm mycontainer
Key Differences
- Podman uses a daemonless architecture, while Docker CE relies on a daemon
- Podman can run containers as a non-root user by default
- Docker CE has better support for Windows environments
- Podman offers built-in support for Kubernetes-style pod management
- Docker CE has more mature GUI tools and desktop applications
Both projects aim to provide container management solutions, but they differ in their approach to security, architecture, and target use cases. Podman focuses on security and compatibility with existing container standards, while Docker CE offers a more comprehensive ecosystem and broader platform support.
The Moby Project - a collaborative project for the container ecosystem to assemble container-based systems
Pros of Moby
- Larger ecosystem and community support
- More extensive documentation and resources
- Better integration with cloud services and orchestration tools
Cons of Moby
- Requires root privileges for most operations
- More complex architecture and larger codebase
- Higher resource consumption
Code Comparison
Moby (Docker) command:
docker run -d --name my_container nginx
Podman command:
podman run -d --name my_container nginx
Key Differences
- Podman is daemonless and doesn't require a background service
- Podman supports rootless containers by default
- Moby uses a client-server architecture, while Podman uses a fork-exec model
Use Cases
Moby is often preferred for:
- Large-scale container orchestration
- Cloud-native applications
- Environments with existing Docker infrastructure
Podman is suitable for:
- Security-sensitive environments
- Systems with limited resources
- Individual developers and smaller teams
Both projects aim to provide container management solutions, but Podman focuses on security and simplicity, while Moby (Docker) offers a more comprehensive ecosystem and broader adoption in enterprise environments.
An open and reliable container runtime
Pros of containerd
- More lightweight and focused on container runtime functionality
- Better integration with Kubernetes and cloud-native ecosystems
- Higher adoption rate in enterprise and cloud environments
Cons of containerd
- Less user-friendly for direct interaction compared to Podman
- Requires additional tools for full container management functionality
- Limited built-in image building capabilities
Code Comparison
containerd:
client, err := containerd.New("/run/containerd/containerd.sock")
container, err := client.NewContainer(ctx, "redis", spec)
task, err := container.NewTask(ctx, cio.NewCreator(cio.WithStdio))
Podman:
podman run -d --name redis redis
podman ps
podman stop redis
Key Differences
- Podman is more user-friendly and CLI-oriented, while containerd is designed as a lower-level runtime
- Podman offers rootless containers by default, containerd requires additional configuration
- containerd is more tightly integrated with Kubernetes, while Podman focuses on standalone environments
Use Cases
- containerd: Ideal for Kubernetes environments and cloud-native applications
- Podman: Better suited for desktop users, developers, and traditional container workflows
Production-Grade Container Scheduling and Management
Pros of Kubernetes
- Designed for orchestrating and managing large-scale container deployments
- Offers advanced features like automatic scaling, load balancing, and self-healing
- Extensive ecosystem with a wide range of tools and integrations
Cons of Kubernetes
- Steeper learning curve and more complex setup compared to Podman
- Requires more resources to run, especially for small-scale deployments
- Can be overkill for simple container management tasks
Code Comparison
Podman:
podman run -d --name myapp -p 8080:80 nginx
Kubernetes:
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 1
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp
image: nginx
ports:
- containerPort: 80
The Podman example shows a simple command to run a container, while the Kubernetes example demonstrates a more complex deployment configuration. This highlights the difference in complexity and flexibility between the two systems.
CLI tool for spawning and running containers according to the OCI specification
Pros of runc
- Lower-level container runtime, providing more direct control over container execution
- Lightweight and focused on core container runtime functionality
- Widely adopted as the reference implementation for OCI runtime specification
Cons of runc
- Requires additional tools for higher-level container management tasks
- Less user-friendly for those seeking an all-in-one container solution
- Limited built-in features compared to more comprehensive tools like Podman
Code Comparison
runc:
spec, err := loadSpec(context)
if err != nil {
return err
}
status, err := startContainer(context, spec)
Podman:
container, err := runtime.NewContainer(ctx, name, options...)
if err != nil {
return err
}
err = container.Start(ctx)
Key Differences
- runc focuses on low-level container runtime operations, while Podman provides a more comprehensive container management solution
- Podman offers a Docker-compatible CLI and additional features like pod management, while runc is primarily used as a backend runtime
- runc is often integrated into higher-level tools (including Podman), whereas Podman can be used directly by end-users for container operations
Complete container management platform
Pros of Rancher
- Provides a comprehensive container management platform with a user-friendly web interface
- Supports multi-cluster management and offers advanced features like load balancing and service discovery
- Integrates well with various cloud providers and on-premises infrastructure
Cons of Rancher
- More complex setup and resource-intensive compared to Podman
- Requires additional infrastructure components, which may increase operational overhead
- Less suitable for individual developers or small-scale deployments
Code Comparison
Podman:
podman run -d --name nginx -p 8080:80 nginx
Rancher:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
The Podman example shows a simple command to run an Nginx container, while the Rancher example demonstrates a Kubernetes deployment configuration, highlighting the difference in complexity and abstraction level between the two tools.
Convert 
designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
Podman: A tool for managing OCI containers and pods
Podman (the POD MANager) is a tool for managing containers and images, volumes mounted into those containers, and pods made from groups of containers. Podman runs containers on Linux, but can also be used on Mac and Windows systems using a Podman-managed virtual machine. Podman is based on libpod, a library for container lifecycle management that is also contained in this repository. The libpod library provides APIs for managing containers, pods, container images, and volumes.
All releases are PGP signed. Public keys of members of the team approved to make releases are located here.
Overview and scope
At a high level, the scope of Podman and libpod is the following:
- Support for multiple container image formats, including OCI and Docker images.
- Full management of those images, including pulling from various sources (including trust and verification), creating (built via Containerfile or Dockerfile or committed from a container), and pushing to registries and other storage backends.
- Full management of container lifecycle, including creation (both from an image and from an exploded root filesystem), running, checkpointing and restoring (via CRIU), and removal.
- Full management of container networking, using Netavark.
- Support for pods, groups of containers that share resources and are managed together.
- Support for running containers and pods without root or other elevated privileges.
- Resource isolation of containers and pods.
- Support for a Docker-compatible CLI interface, which can both run containers locally and on remote systems.
- No manager daemon, for improved security and lower resource utilization at idle.
- Support for a REST API providing both a Docker-compatible interface and an improved interface exposing advanced Podman functionality.
- Support for running on Windows and Mac via virtual machines run by
podman machine.
Roadmap
- Further improvements to
podman machineto better support Podman Desktop and other developer usecases. - Support for conmon-rs, which will improve container logging.
- Support for the BuildKit API.
- Performance and stability improvements.
- Reductions to the size of the Podman binary.
Communications
If you think you've identified a security issue in the project, please DO NOT report the issue publicly via the GitHub issue tracker, mailing list, or IRC.
Instead, send an email with as many details as possible to security@lists.podman.io. This is a private mailing list for the core maintainers.
For general questions and discussion, please use Podman's channels.
For discussions around issues/bugs and features, you can use the GitHub issues and PRs tracking system.
There is also a mailing list at lists.podman.io.
You can subscribe by sending a message to podman-join@lists.podman.io with the subject subscribe.
Rootless
Podman can be easily run as a normal user, without requiring a setuid binary.
When run without root, Podman containers use user namespaces to set root in the container to the user running Podman.
Rootless Podman runs locked-down containers with no privileges that the user running the container does not have.
Some of these restrictions can be lifted (via --privileged, for example), but rootless containers will never have more privileges than the user that launched them.
If you run Podman as your user and mount in /etc/passwd from the host, you still won't be able to change it, since your user doesn't have permission to do so.
Almost all normal Podman functionality is available, though there are some shortcomings. Any recent Podman release should be able to run rootless without any additional configuration, though your operating system may require some additional configuration detailed in the install guide.
A little configuration by an administrator is required before rootless Podman can be used, the necessary setup is documented here.
Podman Desktop
Podman Desktop provides a local development environment for Podman and Kubernetes on Linux, Windows, and Mac machines.
It is a full-featured desktop UI frontend for Podman which uses the podman machine backend on non-Linux operating systems to run containers.
It supports full container lifecycle management (building, pulling, and pushing images, creating and managing containers, creating and managing pods, and working with Kubernetes YAML).
The project develops on GitHub and contributions are welcome.
Out of scope
- Specialized signing and pushing of images to various storage backends. See Skopeo for those tasks.
- Support for the Kubernetes CRI interface for container management. The CRI-O daemon specializes in that.
OCI Projects Plans
Podman uses OCI projects and best of breed libraries for different aspects:
- Runtime: We use the OCI runtime tools to generate OCI runtime configurations that can be used with any OCI-compliant runtime, like crun and runc.
- Images: Image management uses the containers/image library.
- Storage: Container and image storage is managed by containers/storage.
- Networking: Networking support through use of Netavark and Aardvark. Rootless networking is handled via slirp4netns.
- Builds: Builds are supported via Buildah.
- Conmon: Conmon is a tool for monitoring OCI runtimes, used by both Podman and CRI-O.
- Seccomp: A unified Seccomp policy for Podman, Buildah, and CRI-O.
Podman Information for Developers
For blogs, release announcements and more, please checkout the podman.io website!
Installation notes Information on how to install Podman in your environment.
OCI Hooks Support Information on how Podman configures OCI Hooks to run when launching a container.
Podman API Documentation on the Podman REST API.
Podman Commands A list of the Podman commands with links to their man pages and in many cases videos showing the commands in use.
Podman Container Images Information on the Podman Container Images found on quay.io.
Podman Troubleshooting Guide A list of common issues and solutions for Podman.
Podman Usage Transfer Useful information for ops and dev transfer as it relates to infrastructure that utilizes Podman. This page includes tables showing Docker commands and their Podman equivalent commands.
Tutorials Tutorials on using Podman.
Remote Client A brief how-to on using the Podman remote client.
Basic Setup and Use of Podman in a Rootless environment A tutorial showing the setup and configuration necessary to run Rootless Podman.
Release Notes Release notes for recent Podman versions.
Contributing Information about contributing to this project.
Buildah and Podman relationship
Buildah and Podman are two complementary open-source projects that are available on most Linux platforms and both projects reside at GitHub.com with Buildah here and Podman here. Both, Buildah and Podman are command line tools that work on Open Container Initiative (OCI) images and containers. The two projects differentiate in their specialization.
Buildah specializes in building OCI images. Buildah's commands replicate all of the commands that are found in a Dockerfile. This allows building images with and without Dockerfiles while not requiring any root privileges. Buildahâs ultimate goal is to provide a lower-level coreutils interface to build images. The flexibility of building images without Dockerfiles allows for the integration of other scripting languages into the build process. Buildah follows a simple fork-exec model and does not run as a daemon but it is based on a comprehensive API in golang, which can be vendored into other tools.
Podman specializes in all of the commands and functions that help you to maintain and modify OCI images, such as pulling and tagging. It also allows you to create, run, and maintain those containers created from those images. For building container images via Dockerfiles, Podman uses Buildah's golang API and can be installed independently from Buildah.
A major difference between Podman and Buildah is their concept of a container. Podman
allows users to create "traditional containers" where the intent of these containers is
to be long lived. While Buildah containers are really just created to allow content
to be added back to the container image. An easy way to think of it is the
buildah run command emulates the RUN command in a Dockerfile while the podman run
command emulates the docker run command in functionality. Because of this and their underlying
storage differences, you can not see Podman containers from within Buildah or vice versa.
In short, Buildah is an efficient way to create OCI images while Podman allows you to manage and maintain those images and containers in a production environment using familiar container cli commands. For more details, see the Container Tools Guide.
Podman Hello
$ podman run quay.io/podman/hello
Trying to pull quay.io/podman/hello:latest...
Getting image source signatures
Copying blob a6b3126f3807 done
Copying config 25c667d086 done
Writing manifest to image destination
Storing signatures
!... Hello Podman World ...!
.--"--.
/ - - \
/ (O) (O) \
~~~| -=(,Y,)=- |
.---. /` \ |~~
~/ o o \~~~~.----. ~~
| =(X)= |~ / (O (O) \
~~~~~~~ ~| =(Y_)=- |
~~~~ ~~~| U |~~
Project: https://github.com/containers/podman
Website: https://podman.io
Documents: https://docs.podman.io
Twitter: @Podman_io
Top Related Projects
:warning: This repository is deprecated and will be archived (Docker CE itself is NOT deprecated) see the https://github.com/docker/docker-ce/blob/master/README.md :warning:
The Moby Project - a collaborative project for the container ecosystem to assemble container-based systems
An open and reliable container runtime
Production-Grade Container Scheduling and Management
CLI tool for spawning and running containers according to the OCI specification
Complete container management platform
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot