Dagger: Portable CI/CD Pipelines as Code

By Kokil Thapa | Last reviewed: August 2026

Maintaining separate pipeline configurations for GitHub Actions, GitLab CI, and local development creates massive technical debt that slows down delivery. Dagger: Portable CI/CD Pipelines as Code solves this fragmentation by defining your entire build, test, and deployment logic in a standard programming language like Go, Python, or TypeScript rather than proprietary YAML. This approach allows you to debug complex workflows on your laptop with the exact same environment used in production, eliminating the "works on my machine" problem entirely. For teams managing multiple projects or migrating infrastructure, adopting this unified model is often more sustainable than maintaining parallel automation stacks, a challenge I frequently address when consulting on CI/CD pipeline setup for diverse client environments.

What Makes Dagger: Portable CI/CD Pipelines as Code Different from Traditional YAML?

Traditional CI/CD systems rely on declarative configuration files that are interpreted differently by each vendor. A GitHub Actions workflow cannot run natively on a GitLab runner without significant translation, and neither can be executed directly on a developer's workstation without mocking large parts of the runtime. This limitation forces engineers into a slow feedback cycle: push code, wait for queue, read logs, fix syntax, repeat. In contrast, treating automation as software means your pipeline logic lives in actual source code with type safety, IDE autocompletion, and unit testing capabilities.

The core differentiator is the Dagger Engine. Instead of parsing static definitions, the engine constructs a directed acyclic graph (DAG) of container operations. When you invoke a function via the SDK, Dagger determines the optimal execution path, caches intermediate layers automatically, and executes tasks in parallel where dependencies allow. This architecture provides three concrete advantages over legacy approaches:

• True Local Parity: The exact same binary and container images used in your remote CI runner execute on your laptop. There is no emulation layer or "local mode" that differs from production behavior.
• Language-Native Development: You write pipelines in Go, Python, Node.js, or PHP using familiar constructs like loops, conditionals, and classes. This eliminates the cognitive load of learning yet another domain-specific language.
• Automatic Caching: Dagger caches every operation based on content hashing. If you re-run a pipeline after changing only the final deployment step, all previous build and test steps are skipped instantly because their inputs haven't changed.

For agencies or freelancers managing diverse client stacks, this distinction matters practically. On one recent Laravel project, we reduced pipeline debugging time from hours to minutes simply by moving validation logic out of GitLab CI YAML and into a typed PHP module. The ability to step through pipeline code with a debugger, rather than adding echo statements to a remote runner, fundamentally changes the development experience.

How Do You Configure Dagger: Portable CI/CD Pipelines as Code for a Laravel Application?

Setting up Dagger for a PHP/Laravel application involves initializing a module and defining your build targets as functions. As of 2026, Dagger supports PHP natively alongside Go, Python, and TypeScript. The following example assumes you are running PHP 8.4 and Laravel 12.x, which are current stable versions.

Initialize the Dagger Module

Navigate to your project root and initialize a new Dagger module. This creates a dagger/ directory containing your pipeline logic and configuration.

dagger init --sdk=php --source=dagger --name=laravel-pipeline

This command scaffolds a Composer-managed PHP project inside dagger/. Unlike YAML files scattered in .github/ or .gitlab-ci.yml, your entire automation stack is now a versioned, testable PHP package.

Define Build and Test Functions

Create a main pipeline class that encapsulates your Laravel workflow. The key insight is that every operation returns a new immutable state, allowing Dagger to cache aggressively.

<?php

declare(strict_types=1);

namespace Main;

use Dagger\Attribute\DaggerFunction;
use Dagger\Attribute\DaggerObject;
use Dagger\Container;
use Dagger\Client\dagger;

#[DaggerObject]
class LaravelPipeline
{
    #[DaggerFunction]
    public function test(Dagger $dagger): Container
    {
        return $dagger->container()
            ->from('php:8.4-cli')
            ->withExec(['apt-get', 'update'])
            ->withExec(['apt-get', 'install', '-y', 'libzip-dev', 'unzip'])
            ->withExec(['docker-php-ext-install', 'zip', 'pdo_mysql'])
            ->withMountedCache('/root/.composer/cache', $dagger->cacheVolume('composer-cache'))
            ->withDirectory('/app', $dagger->directory()->withGlob('./*'))
            ->withWorkdir('/app')
            ->withExec(['composer', 'install', '--no-interaction', '--prefer-dist'])
            ->withExec(['php', 'artisan', 'test']);
    }

    #[DaggerFunction]
    public function build(Dagger $dagger): Container
    {
        return $this->test($dagger)
            ->withExec(['npm', 'ci'])
            ->withExec(['npm', 'run', 'build'])
            ->withExec(['php', 'artisan', 'optimize']);
    }
}

Note the use of withMountedCache for Composer dependencies. This ensures that subsequent runs skip downloading packages unless composer.json changes. On a typical Laravel e-commerce site with heavy dependencies, this alone can reduce CI time from 4 minutes to under 30 seconds for unchanged dependency sets.

Execute Locally and Remotely

Run the pipeline directly from your terminal. No Docker Compose file or local server setup required:

dagger call test

To integrate with GitLab CI or GitHub Actions, replace your existing job scripts with a single invocation. The CI system merely becomes a scheduler; the logic remains in your repository.

# .gitlab-ci.yml example
test:
  image: alpine:latest
  script:
    - apk add curl
    - curl -L https://dl.dagger.io/dagger/install.sh | BIN_DIR=/usr/local/bin sh
    - dagger call test

This pattern decouples your build logic from the CI provider. If you migrate from GitLab to GitHub or vice versa, the pipeline code doesn't change at all. I've applied this exact strategy when helping clients consolidate multiple legacy repositories into modern monorepos, where maintaining separate YAML for each sub-project was unsustainable.

How Does Dagger Compare to GitHub Actions and GitLab CI in 2026?

Choosing between native CI tools and Dagger depends on team size, complexity, and portability requirements. While GitHub Actions and GitLab CI remain excellent for simple workflows, they fall short when logic grows complex or multi-platform support is needed. The following comparison reflects real-world usage patterns observed across production deployments in 2026.

In practice, many teams adopt a hybrid approach. They keep trivial checks (linting, PR labeling) in native YAML but move integration tests, staging deployments, and release packaging to Dagger. This balances convenience with portability. For Nepali businesses operating on tighter budgets, avoiding vendor lock-in also means retaining flexibility to switch hosting providers or CI services without rewriting automation—a consideration that frequently arises during website development cost planning discussions.

What Are Common Pitfalls When Adopting Dagger: Portable CI/CD Pipelines as Code?

Despite its strengths, Dagger introduces operational considerations that catch teams off guard. Recognizing these early prevents frustration during adoption.

Over-Engineering Simple Tasks

Not everything needs to be a Dagger function. Trivial shell commands like echo $VERSION don't benefit from containerization overhead. Reserve Dagger for tasks involving dependency installation, compilation, testing, or artifact generation. Using it for simple variable substitution adds latency without value.

Neglecting Cache Volume Management

Dagger's automatic caching is powerful but not magic. Named cache volumes persist across runs, but anonymous caches do not. Always explicitly name caches for expensive operations like composer install, npm ci, or pip install. Without explicit naming, you lose the primary performance benefit.

// Bad: Anonymous cache, lost between runs
->withMountedCache('/root/.cache', $dagger->cacheVolume())

// Good: Named cache, persists across invocations
->withMountedCache('/root/.cache', $dagger->cacheVolume('composer-deps-v1'))

Ignoring Platform Architecture Differences

If your team uses Apple Silicon laptops but deploys to x86_64 servers, container builds may behave differently. Dagger handles cross-compilation well, but you must specify platform constraints explicitly when building production artifacts. Test both architectures locally using --platform linux/amd64 flags before pushing to CI.

Treating Dagger as a Replacement for Infrastructure Provisioning

Dagger excels at application build and test workflows. It does not replace Terraform, Pulumi, or Ansible for provisioning cloud resources. Attempting to manage AWS VPCs or Kubernetes clusters through Dagger functions leads to fragile, hard-to-debug infrastructure code. Keep infrastructure-as-code separate and invoke it from Dagger only when necessary for integration testing.

Is Dagger: Portable CI/CD Pipelines as Code Worth the Migration Effort?

Adopting Dagger requires upfront investment in learning the SDK and restructuring existing pipelines. However, the long-term payoff compounds with each additional project and team member. Teams report 40–60% reduction in CI debugging time and near-zero divergence between local and remote environments after migration. For organizations managing more than three active repositories or supporting multiple CI platforms, the break-even point typically arrives within two months.

The decision ultimately hinges on pain tolerance. If your current YAML pipelines are stable, simple, and confined to one ecosystem, migration urgency is low. But if you're spending significant time troubleshooting environment differences, duplicating logic across platforms, or onboarding developers who struggle with opaque CI failures, Dagger addresses these problems structurally rather than symptomatically.

Start small. Migrate your most painful pipeline first—usually integration tests or staging deployments. Validate the workflow locally before integrating with your CI provider. Measure cycle time improvements objectively. This incremental approach de-risks adoption while delivering immediate value. For teams evaluating broader infrastructure modernization, combining Dagger with disciplined Laravel API best practices creates a cohesive development experience where application and automation code share the same quality standards.

Next Steps for Implementing Portable Automation

Dagger: Portable CI/CD Pipelines as Code represents a maturation of DevOps philosophy—treating automation as first-class software rather than configuration afterthought. Begin by installing the CLI (curl -L https://dl.dagger.io/dagger/install.sh | sh) and initializing a module in an existing project. Run your test suite locally with dagger call test and compare execution time against your current CI. Document the delta. Share results with stakeholders using concrete metrics, not abstract promises.

If you need guidance implementing portable pipelines for Laravel, WordPress, or custom PHP applications, or want to audit your existing CI/CD setup for portability gaps, reach out to discuss your specific automation challenges. Practical, battle-tested advice beats theoretical perfection every time.