Argo Workflows for CI Pipelines

By Kokil Thapa | Last reviewed: September 2026

Teams outgrow single-server CI when builds compete for CPU, deploy targets multiply, and you already run workloads on Kubernetes. Argo Workflows for CI Pipelines gives you a container-native orchestrator: each lint, test, and build step runs in its own pod, chained as a directed acyclic graph (DAG). If you maintain Laravel CI with GitLab CI today but want runners colocated with staging clusters, Argo Workflows is a credible next step—not a drop-in replacement, but a strong fit when Kubernetes is already part of your stack.

What is Argo Workflows and why use it for CI pipelines?

Argo Workflows is a CNCF-graduated workflow engine for Kubernetes. It extends the API with Custom Resources such as Workflow, WorkflowTemplate, and CronWorkflow. Each step is a container spec the controller schedules like any other pod.

That model differs from a traditional CI server. Jenkins and GitLab Runner keep long-lived agents. Argo spins up ephemeral pods, runs one step, then tears them down. You pay only for compute during the job. On a busy monorepo, that isolation also stops a flaky integration test from starving unrelated builds.

In practice, Argo Workflows shines when:

• Kubernetes already hosts your apps, so CI pods land near the cluster they deploy to.
• You need DAG parallelism—lint and unit tests in parallel, then integration tests, then image build.
• You want one orchestrator for CI, data pipelines, and batch jobs instead of three tools.
• Your team accepts YAML-first pipelines and kubectl-level debugging.

It is a weaker default when your team has no cluster ops capacity. A managed GitLab CI or GitHub Actions setup is simpler if Kubernetes is not in your roadmap. For teams shipping custom software on Kubernetes, the trade-off often tilts toward Argo.

How do you install Argo Workflows on a Kubernetes cluster?

Install Argo Workflows into a dedicated namespace—argo is the usual choice. The official manifest bundle pins a controller version; check the Argo Workflows installation docs for the current release before you apply YAML in production.

Quick install with kubectl

# Create namespace
kubectl create namespace argo

# Install Argo Workflows (check docs for latest version tag)
kubectl apply -n argo -f https://github.com/argoproj/argo-workflows/releases/download/v3.6.2/install.yaml

# Install Argo CLI (Linux amd64 example)
curl -sLO https://github.com/argoproj/argo-workflows/releases/download/v3.6.2/argo-linux-amd64.gz
gunzip argo-linux-amd64.gz
chmod +x argo-linux-amd64
sudo mv argo-linux-amd64 /usr/local/bin/argo

After install, patch the workflow controller ConfigMap if you need artifact storage. The default config uses the in-cluster argo-server artifact repository, which is fine for experiments but not for production CI artifacts.

Configure artifact storage for CI outputs

CI pipelines produce test reports, coverage files, and built images. Argo Workflows supports S3-compatible storage, GCS, Azure Blob, and Artifactory. For AWS or MinIO:

apiVersion: v1
kind: ConfigMap
metadata:
  name: workflow-controller-configmap
  namespace: argo
data:
  artifactRepository: |
    s3:
      bucket: my-ci-artifacts
      endpoint: s3.amazonaws.com
      region: ap-south-1
      accessKeySecret:
        name: my-s3-credentials
        key: accessKey
      secretKeySecret:
        name: my-s3-credentials
        key: secretKey

Reload the controller after editing the ConfigMap. Without durable artifact storage, later DAG steps cannot consume outputs from earlier steps running in different pods.

If your team manages the cluster in-house, Linux and Kubernetes administration skills matter as much as the YAML itself. Misconfigured RBAC is the most common first-week blocker.

How do you write an Argo Workflow for a CI pipeline?

A CI Workflow is a YAML file with a spec.templates array and an entrypoint. Templates can be container, script, resource, or dag. For CI, you will use dag templates most often.

Example: Laravel PHP 8.3 CI pipeline

This example mirrors a typical database migration CI check plus test and build stages. It assumes a private registry and a Composer cache volume.

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: laravel-ci-
  namespace: argo
spec:
  entrypoint: ci-pipeline
  serviceAccountName: argo-workflow
  arguments:
    parameters:
      - name: git-revision
        value: main
      - name: repo-url
        value: https://github.com/myorg/myapp.git

  templates:
    - name: ci-pipeline
      dag:
        tasks:
          - name: checkout
            template: git-clone
          - name: composer-install
            dependencies: [checkout]
            template: composer
          - name: lint
            dependencies: [composer-install]
            template: php-lint
          - name: test
            dependencies: [composer-install]
            template: phpunit
          - name: build-image
            dependencies: [lint, test]
            template: kaniko-build

    - name: git-clone
      container:
        image: alpine/git:latest
        command: [sh, -c]
        args:
          - git clone --depth 1 --branch {{workflow.parameters.git-revision}}
            {{workflow.parameters.repo-url}} /workspace/src
        volumeMounts:
          - name: workspace
            mountPath: /workspace

    - name: composer
      container:
        image: composer:2.10
        command: [sh, -c]
        args:
          - cd /workspace/src && composer install --no-interaction --prefer-dist
        volumeMounts:
          - name: workspace
            mountPath: /workspace

    - name: php-lint
      container:
        image: php:8.3-cli
        command: [sh, -c]
        args:
          - cd /workspace/src && vendor/bin/pint --test
        volumeMounts:
          - name: workspace
            mountPath: /workspace

    - name: phpunit
      container:
        image: php:8.3-cli
        env:
          - name: DB_CONNECTION
            value: sqlite
          - name: DB_DATABASE
            value: ":memory:"
        command: [sh, -c]
        args:
          - cd /workspace/src && cp .env.testing .env && php artisan test
        volumeMounts:
          - name: workspace
            mountPath: /workspace

    - name: kaniko-build
      container:
        image: gcr.io/kaniko-project/executor:latest
        args:
          - --dockerfile=/workspace/src/Dockerfile
          - --context=/workspace/src
          - --destination=registry.example.com/myapp:{{workflow.uid}}
        volumeMounts:
          - name: workspace
            mountPath: /workspace

  volumeClaimTemplates:
    - metadata:
        name: workspace
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 2Gi

Submit the Workflow:

argo submit -n argo laravel-ci-workflow.yaml --watch
argo logs -n argo @latest

Promote this to a reusable WorkflowTemplate once the DAG stabilises. Templates accept parameters for branch name, PHP version, and deploy target. That pattern matches how I structure pipeline automation best practices on GitLab—one template, many parameterised runs.

How does Argo Workflows compare to Tekton and GitLab CI for CI pipelines?

Pick the tool that matches where your code runs today—not the one with the most GitHub stars. All three can lint, test, and deploy a Laravel 13 app on PHP 8.3. The operational model differs.

Argo Workflows and Tekton overlap heavily. Tekton integrates cleanly with OpenShift and supply-chain signing via Chains. Argo Workflows pairs naturally with Argo Rollouts and Argo CD in a single Argo ecosystem. GitLab CI remains my default for client projects on shared EC2 with Deployer 7—it needs no cluster.

For a greenfield platform team running multiple microservices on Kubernetes, Argo Workflows reduces tool sprawl. For a law-firm portal on a single VPS, it adds complexity you do not need.

How do you trigger and secure Argo Workflows CI pipelines?

Manual argo submit works for testing. Production CI needs event-driven triggers and tight secret handling.

Trigger from Git with Argo Events

Argo Events watches webhooks from GitHub or GitLab. A Sensor resource maps the payload to a Workflow submission:

1. Install Argo Events in the same cluster.
2. Create an EventSource with a Git webhook endpoint.
3. Define a Sensor that submits your WorkflowTemplate on push to main.
4. Expose the webhook through an Ingress with TLS.
5. Validate webhook signatures before the Sensor fires.

Filter by path if you run a monorepo. Only rebuild the API service when services/api/** changes. That saves cluster CPU and keeps queue times predictable.

Secrets and RBAC

Never embed registry passwords or API keys in Workflow YAML. Mount Kubernetes Secrets as env vars or files. For production, integrate HashiCorp Vault or your cloud provider's secret manager—the same principles as handling secrets in CI/CD pipelines safely apply here.

    - name: deploy-staging
      container:
        image: bitnami/kubectl:latest
        env:
          - name: KUBECONFIG
            value: /secrets/kubeconfig
        volumeMounts:
          - name: kubeconfig-secret
            mountPath: /secrets
            readOnly: true
      volumes:
        - name: kubeconfig-secret
          secret:
            secretName: staging-kubeconfig

Create a dedicated ServiceAccount per pipeline class. A CI account that deploys to staging should not carry production cluster-admin rights. Run shift-left security checks—Trivy image scans and gitleaks secret scans—as early DAG tasks before any deploy step.

How do you debug failed Argo Workflow CI runs in production?

Failed CI on Kubernetes feels opaque until you learn three commands. Treat Argo like any other production service—you need logs, events, and a retry path.

Essential debugging commands

# List recent workflows
argo list -n argo

# Stream logs from a failed step
argo logs -n argo my-workflow-abc123 --step test

# Describe the workflow for node-level errors
argo get -n argo my-workflow-abc123

# Inspect the underlying pod
kubectl describe pod -n argo my-workflow-abc123-test-1234567

Common failure modes I have seen on client Kubernetes migrations:

• Image pull errors — private registry credentials missing from the namespace.
• OOMKilled test pods — PHPUnit or npm test exceeds default memory limits; raise resources.limits.memory.
• Volume mount races — parallel tasks writing to the same ReadWriteOnce PVC; use artifacts instead.
• Stale workflow controller — ConfigMap change without controller restart.
• RBAC denied — ServiceAccount lacks permission to create pods or read secrets.

Enable workflow archiving to S3 so you can compare failed and successful runs side by side. The Argo UI—installed via the same manifest bundle—shows DAG status with red/green nodes. It beats parsing JSON in a terminal during a Friday deploy.

For JSON log payloads from test runners, paste them into the JSON formatter to spot assertion failures quickly. Regex-heavy PHPUnit output sometimes benefits from the regex tester when you build log-parsing scripts.

On projects like Adventure Third Pole Trek, where Laravel and Livewire power booking flows, reliable CI is non-negotiable. A broken pipeline that blocks a hotfix during trekking season costs real revenue. Invest in alerting—Prometheus metrics from the workflow controller plus Slack notifications on failure.

Key Takeaways

• Argo Workflows for CI pipelines maps each build stage to an ephemeral Kubernetes pod orchestrated by a DAG.
• Install the controller in a dedicated namespace, configure S3-compatible artifact storage, and promote tested YAML to WorkflowTemplates.
• Pair Argo Events with Git webhooks for automatic runs; never store secrets in plain Workflow specs.
• Choose Argo over GitLab CI when Kubernetes is your deployment plane; keep GitLab CI for VM-based Laravel deploys with Deployer.
• Debug with argo logs, argo get, and kubectl describe pod—most failures are infra, not code.
• Align CI clusters with staging/production regions to cut image pull latency and simplify RBAC boundaries.

People Also Ask

Can Argo Workflows replace Jenkins or GitLab CI entirely?

It can replace the execution layer if every build runs on Kubernetes. Most teams keep GitLab or GitHub for code review and use Argo only for cluster-native build and deploy steps. Full replacement makes sense when you standardise on the Argo suite—Workflows, Events, CD, and Rollouts—and have staff to operate it.

Does Argo Workflows support Docker-in-Docker builds?

Yes, but Kaniko or BuildKit sidecars are safer on locked-down clusters. DinD requires privileged pods, which many security policies block. Kaniko builds images without a Docker daemon and fits the ephemeral pod model better.

How much does running CI on Argo Workflows cost?

Cost follows Kubernetes node usage. A small team running ten five-minute pipelines daily on three spot-instance nodes might spend USD 30–80/month (~Rs 4,000–11,000). Heavy parallel test suites on on-demand instances cost more. Compare that to managed CI minutes before you migrate.

Is Argo Workflows the same as Argo CD?

No. Argo Workflows orchestrates jobs—CI steps, data pipelines, batch tasks. Argo CD syncs Kubernetes manifests from Git—a deploy tool. They complement each other: Workflows builds and tests the image; CD promotes the manifest pointing to that image tag.

Ship Kubernetes-native CI with confidence

Argo Workflows for CI Pipelines earns its place when Kubernetes is already your runtime and you want DAG parallelism without maintaining a farm of CI VMs. Start with one service, a clone-test-build WorkflowTemplate, and S3 artifacts. Add Argo Events once manual submits work. Keep GitLab CI for projects that deploy to single servers until a cluster migration is real—not aspirational.

If you want help designing a CI path—from GitLab CI on EC2 to Argo on Kubernetes—contact us or review our enterprise application development and testing and optimization services. Read related guides on GitHub Actions vs GitLab CI, CI/CD secrets management, and Bitbucket Pipelines to pick the right entry point for your team.