Skip to main content
In this lesson we examine the Argo Workflow specification and how to author reusable automation pipelines as Kubernetes custom resources. Argo Workflows is implemented as a Kubernetes Custom Resource Definition (CRD), which lets you define complex CI/CD and automation pipelines using familiar YAML files. A workflow is a structured sequence of automated tasks that together accomplish a goal — commonly used in DevOps for application deployment, testing, and promotion. Key components of an Argo Workflow manifest:
  • Header: Kubernetes metadata (apiVersion, kind, metadata).
  • spec: Describes workflow behavior and templates that perform work.
The following sections explain the structure, common template types, and how to submit a workflow.

​
Workflow file structure

A typical workflow YAML contains the following top-level parts:
  • Header: apiVersion, kind, and metadata.
  • Metadata: you can specify name or generateName. Use generateName to avoid collisions when submitting the same manifest multiple times — Argo appends a unique suffix.
  • spec: the core of the workflow. Important fields:
    • entrypoint: the name of the template that starts execution.
    • templates: a list of reusable templates. Templates describe tasks and can reference each other.
Use generateName when you want to submit the same workflow multiple times without name collisions. Each submission will get a unique suffix appended to the provided generateName.

​
Template types (overview)

Templates are the building blocks of workflows. Argo supports several template types for different use cases:
Template TypeUse CaseNotes
containerRun a container imageMaps directly to a Kubernetes container spec (image, command, args, env, volumeMounts, resources)
scriptRun inline scripts in various runtimesUseful for quick logic without building a container image
stepsDefine sequential stepsA list of templates executed in sequence
dagDefine directed acyclic graph executionSupports complex dependency graphs and parallelism
resourceCreate or modify Kubernetes resourcesUseful for applying manifests or CRs as part of the workflow
Templates can be composed — steps or dag templates reference container/script/resource templates to perform tasks.

​
Container templates

Container templates accept the same fields as a Kubernetes Pod container spec. This means you can use:
  • image
  • command and args
  • env and envFrom
  • volumeMounts and volumes
  • resources
Because the container template mirrors Kubernetes, you can use existing YAML knowledge when defining tasks. Example container-template workflow: 
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: cowsay-
spec:
  entrypoint: cowsay-template
  templates:
  - name: cowsay-template
    container:
      image: rancher/cowsay
      command: ["cowsay"]
      args: ["Argo Workflow!!!!"]

​
Submitting a workflow

You can submit workflows with either the Argo UI or the CLI. CLI example (submits to the argo namespace): 
# submit workflow.yml to the 'argo' namespace
argo submit -n argo workflow.yml
The Argo UI is available if your Argo server is exposed; it provides a visual representation of templates, DAGs, and steps.
The entrypoint must match one of the template names defined under templates. If it does not, the workflow will fail to start.

​
Practical tips and best practices

  • Use generateName for recurring or CI-driven workflow submissions to avoid manual name management.
  • Keep templates small and reusable — compose complex workflows from simple building blocks (container/script/steps/dag).
  • Use resources and resourceLimits to avoid noisy scheduling and to communicate expected resource usage.
  • Version control your workflow manifests alongside application code or infrastructure repositories for traceability.

​
Quick reference: spec fields

FieldDescription
entrypointName of the template to execute first
templatesList of named templates used by the workflow
argumentsPass parameters into templates and workflows
volumesShared volumes available to templates
serviceAccountNameService account used by workflow pods
Notes:
  • The container section within a template maps directly to a Kubernetes container spec and supports env, volumeMounts, and resources.
  • Always ensure the entrypoint value matches a defined template name under templates.

Watch Video