GitHub Actions vs Argo Workflows: Key Differences

DEV Community

GitHub Actions vs Argo Workflows: which one runs what

GitHub Actions vs Argo Workflows is usually a false choice, because the two are not sold the same unit of work: Actions runs a workflow file in response to a git event, and Argo Workflows reconciles a Kubernetes custom resource that models a DAG of containers. The place they genuinely collide is fan-out, where Actions caps a job matrix at 256 jobs per run and Argo is bounded by the cluster. The same five steps on each engine. Actions shares one runner and one filesystem; Argo generates a pod per step, historically with an init and a wait container around your own image. Argo Workflows is a container-native workflow engine implemented as a Kubernetes CRD, and a graduated project in the Cloud Native Computing Foundation. Its own documentation lists its use cases in this order: machine learning pipelines, data and batch processing, infrastructure automation, and CI/CD. CI/CD is fourth on that list for a reason. GitHub Actions is triggered by repository events, runs on machines somebody else keeps warm, and reports back into the pull request. Argo has no git trigger of its own; event-driven triggering is a separate project, Argo Events, that you also deploy. The comparison below is drawn from the argoproj/argo-workflows repository and from GitHub's published limits, read on 21 September 2026 against Argo Workflows v4.1.4. Where a number depends on your cluster, the cell says so. Comparison GitHub Actions Argo Workflows The unit you write A workflow file in .github/workflows, up to 500 KB, discovered automatically from the repository A Workflow custom resource applied to a cluster, with steps or a DAG of tasks What triggers it Push, pull request, schedule, manual dispatch and the rest of the repository event set The API, the argo CLI, a schedule, or sensors from the separate Argo Events project What runs a step All steps of a job share one runner and one filesystem Every step and every DAG task becomes its own Pod, historically three containers: main, init and wait Fan-out ceiling A job matrix generates at most 256 jobs per workflow run, on hosted and self-hosted runners alike Your cluster. The controller processes one Workflow at a time, so the ceiling moves from the API to the reconciler What you pay per minute $0.006 at 2 vCPU on Linux, or $0.0025 on a managed runner at the same size Nothing to Argo. Your cluster bills for the pods and the nodes under them Free tier $12 of included compute a month on Free, $18 on Team, $300 on Enterprise Cloud (2,000, 3,000 and 50,000 minutes at the $0.006 Linux rate, read 12 November 2026), and free and unlimited on public repositories Apache 2.0 software, no allowance, because there is no meter Where it runs GitHub's fleet, a vendor's fleet, or your own self-hosted runners A Kubernetes cluster you operate, with the controller and server in their own namespace Time limits 6 hours per job on hosted runners, 5 days self-hosted, 35 days per workflow run Whatever you configure. The quick-start instructions say in as many words that they are not suitable for production Self-healing or retries None built in on GitHub-hosted runners; transient failures diagnosed and retried inside the run on Latchkey Retry strategies you declare per template, which is real retry logic and the most convincing thing on this row Setup change required Commit a file. On a managed runner, an app install and a runs-on label A Kubernetes cluster, kubectl, the quick-start or production manifests, and the argo CLI What a step costs on each side This is the difference that surprises people who try to run CI on Argo. In GitHub Actions a job is one machine: checkout, install, build and test all see the same working directory, and passing data between steps costs nothing. In Argo, each step and each DAG task causes a Pod to be generated. Historically each of those pods carries three containers: main runs your image, an init container fetches artifacts and parameters, and a wait container handles clean-up and saves parameters an...

Powered by Readybot.io