Building a Runnerless, Serverless CI/CD Architecture with Dagger and Podman Quadlets
Introduction: The Evolution Past Traditional CI/CD Runners
For years, enterprise DevOps teams have accepted a standard compromise: to run automated CI/CD pipelines, one must maintain a dedicated fleet of virtual machines or Kubernetes nodes acting as continuous integration runners. Whether utilizing Jenkins agents, GitHub Actions self-hosted runners, or GitLab Runners, this infrastructure introduces persistent management overhead. These environments require constant patching, scale inefficiently during peak hours, and incur substantial idle runtime costs.
As organizations push toward cloud-native efficiency, the concept of "runnerless" or serverless CI/CD has emerged as the next logical milestone. By decoupling the execution logic from a permanent daemon or virtual machine, engineering teams can execute pipeline steps on-demand, securely, and with zero leftover footprint. This comprehensive guide explores how to architect a modern, runnerless CI/CD system by combining two pioneering technologies: Dagger, the programmable container-native pipeline engine, and Podman Quadlets, Red Hat’s systemd-native container management framework.
---Understanding the Core Components
Before diving into the integration architecture, it is essential to understand why these two specific tools complement each other perfectly within a serverless ecosystem.
Dagger: Pipelines as Code, Executed Anywhere
Traditional CI systems rely heavily on complex, proprietary YAML configurations that are notoriously difficult to test locally. Dagger fundamentally changes this paradigm by allowing developers to write pipeline logic in standard programming languages such as Go, Python, or TypeScript. Dagger wraps these execution steps into an optimized directed acyclic graph (DAG) and executes them entirely within containers via Buildkit.
Because Dagger runs anywhere a container runtime exists, it removes vendor lock-in. The exact same script that runs on a developer's laptop can execute seamlessly in production without alterations.
Podman Quadlets: Declarative, Daemonless Container Management
While Podman famously introduced daemonless, rootless container execution to replace Docker, managing complex container lifecycles via standard systemd unit files remained cumbersome. Enter Quadlets. Introduced in recent versions of Podman, Quadlets act as a smart translator. They allow administrators to write simple, declarative configuration files (with a .container or .volume extension) that Podman automatically compiles into native systemd service units at runtime.
This approach gives teams the best of both worlds: the lightweight, secure, rootless nature of Podman combined with the robust process management, dependency mapping, and automated recovery features of standard Linux systemd.
---The Architecture of a Runnerless CI/CD System
In a traditional architecture, a CI runner pollutes the host environment, requires root privileges (or a vulnerable Docker socket), and continuously listens for incoming network webhooks. In contrast, a runnerless Dagger and Podman Quadlet architecture operates under an ephemeral, event-driven model.
Key Architectural Principle: Infrastructure should only exist for the exact duration of the workload execution. When a code commit occurs, an ephemeral cloud instance or systemd process initializes, triggers the Quadlet configuration, executes the Dagger pipeline, and immediately terminates.
The operational workflow follows these specific phases:
- Trigger Event: A webhook from a code repository (e.g., GitHub, GitLab, or an internal Git server) triggers a lightweight, serverless function or an event listener.
- Quadlet Initialization: The event listener provisions an ephemeral Linux environment or leverages an existing minimal host, dropping a declarative Quadlet file into the systemd configuration directory.
- Systemd Execution: Systemd parses the Quadlet, automatically spins up the necessary rootless Podman containers, and mounts the required volumes securely.
- Dagger Engine Execution: Inside the secure, isolated environment, the Dagger engine executes the multi-stage pipeline (e.g., linting, compilation, integration testing, container image building) compiled from standard code.
- Teardown: Upon pipeline completion (success or failure), systemd stops the service, Podman removes the containers automatically, and the host resources are immediately reclaimed.
Implementation Blueprint: Configuring Dagger with Quadlets
To successfully implement this serverless setup, DevOps engineers need to structure the systemd services using Quadlet definitions to invoke Dagger correctly. Below is a conceptual breakdown of how a Quadlet configuration file handles a Dagger workflow.
The Quadlet Configuration (dagger-pipeline.container)
Instead of manual podman run commands, engineers create a declarative file under /etc/containers/systemd/. The file structures the container runtime environment with precise constraints:
- [Container] Section: Specifies the baseline engine image, environment variables, and automated cleanup flags (
RemapUsers=keep-idto maintain file permissions securely without root privileges). - Volume Mapping: Mounts the local source code repository and caches Dagger's build layers across execution cycles using Podman volumes, significantly speeding up subsequent runs.
- Exec Commands: Defines the entrypoint that triggers the Dagger CLI or executes a compiled Dagger pipeline script written in Go or Python.
By leveraging systemd's native dependency management (Wants= and After=), engineers can ensure that dependency services, such as localized database containers or mock APIs needed for integration tests, spin up and spin down in the exact sequence required by the Dagger engine.
Key Business and Technical Advantages
Transitioning from heavily managed CI runner clusters to a Dagger and Podman Quadlet architecture yields significant advantages across multiple domains:
| Operational Vector | Traditional CI/CD Runners | Dagger + Podman Quadlets |
|---|---|---|
| Security Profile | Requires privileged Docker daemons; high blast radius. | Rootless, daemonless isolation natively enforced by systemd. |
| Resource Efficiency | Continuous idle CPU/Memory consumption to maintain readiness. | Zero footprint when idle; absolute scale-to-zero capability. |
| Local Reproducibility | Extremely difficult to test complex YAML steps locally. | Flawless execution; local developer run matches cloud run exactly. |
| Maintenance Burden | High patching, agent updates, and custom plugin scaling. | Immutable, declarative files managed by Linux core utilities. |
1. Uncompromising Enterprise Security
Traditional CI engines often require access to the host's Docker socket (/var/run/docker.sock). If a malicious actor compromises a pipeline container, they gain effective root access to the underlying host. Because Podman operates entirely without a root daemon and supports user namespaces natively, the entire Dagger pipeline runs within a strict unprivileged sandbox. Even if a build dependency is compromised, the host system remains fully protected.
2. Extreme Cost Optimization via Scale-to-Zero
By utilizing Podman Quadlets on ephemeral instances, organizations only pay for computing power exactly when code is being verified. Eliminating fixed clusters of standby nodes directly reduces cloud infrastructure spending. For massive engineering groups, removing idle runner capacity can result in thousands of dollars saved monthly.
---Conclusion and Next Steps
The combination of Dagger and Podman Quadlets represents a paradigm shift in modern DevOps engineering. It successfully detaches the execution of continuous integration pipelines from the underlying platform provider, moving the industry closer to a highly secure, cost-effective, and fully repeatable serverless future.
To begin adopting this architecture within your organization, consider migrating a single non-critical microservice pipeline. Rewrite the manual CI steps into a programmable Dagger script, test it on a local workstation, and deploy it onto a minimal Linux instance managed by Podman Quadlets. The results in speed, stability, and security will speak for themselves.