The AI DevOps Engineer for CI/CD

The deployment pipeline is the part of the engineering stack that every team eventually inherits but nobody fully owns. It accretes over time: a GitHub Actions workflow added in a weekend sprint, a Dockerfile that was "good enough" when the team was three people, a deployment strategy that is still "rolling" because nobody has had the time to implement the canary release that was on the roadmap for two quarters. The result is a CI/CD system that works right up until it does not, and when it does not, the failure always happens at the worst possible moment. Generalist AI tools can answer questions about YAML syntax, but they cannot design a deployment pipeline that is boring enough never to cause incidents. That is the standard Relay holds itself to.

Why the generalist approach breaks down

Ask a generalist chatbot to write you a GitHub Actions workflow and you will get something that runs. Ask a DevOps engineer to review it and they will find the secrets hardcoded in the YAML instead of stored in GitHub Secrets, the build cache that resets on every run because the key is wrong, the deployment step that pushes directly to production with no smoke test gate, and the Docker image that runs as root because nobody specified a non-root user. These are not edge cases, they are the default output of any generalist tool that has seen a thousand YAML examples without understanding why each element is there. The pipeline looks complete because the structure is correct. The security holes and reliability gaps are invisible until something goes wrong.

Cursor and GitHub Copilot make the problem subtler. Their YAML completions are often syntactically correct and structurally plausible, but they complete patterns without building pipelines. They will suggest a docker/build-push-action step without asking whether you need multi-stage builds, without noting that your image will be 2.1 GB if you do not specify the right base, and without mentioning that you need a .dockerignore file or the build context will send your entire node_modules directory to the Docker daemon. The gap between a syntactically correct pipeline and a production-grade pipeline is all the judgment calls that autocomplete skips.

The challenge with CI/CD specifically is that the pipeline is the gatekeeper for everything else. A pipeline with secrets in plain text exposes the production environment. A pipeline without proper caching slows every engineer's feedback loop by five minutes per run. A deployment step without rollback procedures means that every bad deploy is a manual intervention and a potential incident. These are not abstract concerns, they are the accumulated cost of pipelines built to work rather than built to last. Relay is built for the second standard.

What a DevOps engineer actually does

On a human engineering team, the DevOps engineer is the person who owns the path from a developer's commit to running production code. They build the pipeline stages that automate testing, security scanning, artifact publishing, and deployment promotion. They write Dockerfiles that are small, secure, and reproducible, not just containers that work, but containers that do not expose root access, do not contain build tooling in the production image, and do not balloon in size because nobody thought about layer ordering. They design deployment strategies that minimize blast radius: canary releases that shift a small percentage of traffic to the new version and roll back automatically if the error rate climbs, blue-green deployments that allow instant cutover with zero downtime, rolling updates that replace instances gradually with health checks ensuring each replacement is healthy before proceeding.

The DevOps engineer is also the person who audits existing pipelines and tells you which parts are security liabilities and which are slowing the team down. A pipeline that takes twenty-five minutes to run but could take eight with proper caching has a measurable cost in developer time and morale. A deployment workflow that has no smoke test gate will eventually ship a bad deploy to production. These are the concerns that live in the intersection of engineering and operations, the ones that matter most and get addressed last. Relay owns that intersection.

Meet Relay

Relay is Tonone's DevOps engineer, the specialist agent for CI/CD pipelines, production Dockerfiles, and deployment strategies. Relay's working philosophy is the same as a senior DevOps engineer's: deployments should be too boring to cause incidents. That means pipelines with proper secret management, dependency caching, and deployment gates. Dockerfiles with multi-stage builds, non-root users, and minimal attack surface. Deployment strategies with explicit rollback procedures and automatic rollback on error rate thresholds. Relay does not produce pipelines that look correct; it produces pipelines that are correct.

Tonone's Relay builds CI/CD pipelines that are too boring to cause incidents, with secret management, caching, deployment gates, and rollback procedures built in from the start.

What Relay actually does

Building a complete CI/CD pipeline from scratch

The relay-pipeline skill is the core of Relay's build capability. You describe your stack, your test framework, and your deployment target, and Relay produces a complete pipeline configuration for GitHub Actions, GitLab CI, Cloud Build, or CircleCI, with proper stage sequencing, dependency caching keyed correctly, environment variable management via secrets (never inline), and deployment gates that prevent a broken build from reaching production. The output is not a skeleton, it is a working pipeline configured for your stack, with cache keys that actually hit, test parallelization if the suite is large enough to benefit, and a deployment step that only runs when the build and test stages both pass. For teams standing up a new service or migrating to a new CI platform, relay-pipeline compresses the trial-and-error of pipeline configuration into a single output that runs correctly on the first try. The pipeline configuration includes inline comments explaining why each element is structured the way it is, which means the team can maintain it without needing to reverse-engineer the original intent.

Building production-ready Docker images

The relay-docker skill produces Dockerfiles that are production-grade in three ways that generalist tools consistently miss. First, multi-stage builds: a build stage with the full toolchain installed, a production stage that copies only the compiled artifacts, resulting in images that are tens to hundreds of megabytes smaller than single-stage builds. Second, security hardening: the production stage drops root privileges, removes unnecessary packages, and sets a non-root USER directive, so even if the container is compromised, the attacker does not have root access to the underlying system. Third, Docker Compose for local development that mirrors production behavior, reducing the class of bugs that only appear in production because the local environment is configured differently. The output always includes a .dockerignore file to prevent the build context from including node_modules, .git, and other directories that inflate build time and surface area. Build cache layers are ordered for maximum hit rate, which compounds over time into meaningful reductions in CI build duration.

Tonone's Relay relay-docker skill produces Dockerfiles with multi-stage builds, non-root security hardening, and build cache optimization, not just containers that run, but containers that are safe and efficient to run in production.

Setting up deployment strategies with rollback

The relay-deploy skill produces deployment strategies with an explicit rollback procedure for each, not as an afterthought, but as a first-class output. For rolling updates, this means health check configuration that ensures each replacement instance is healthy before the next one is replaced, with rollback triggered automatically if the health check failure rate exceeds a threshold. For canary releases, it means a traffic-shifting configuration that routes a configurable percentage (typically five or ten percent) to the new version, monitors error rate and latency, and rolls back automatically if either exceeds the defined threshold, no manual intervention required during business hours. For blue-green deployments, it means a complete switch configuration with an instant-cutover mechanism, smoke test suite that validates the green environment before any traffic is shifted, and a one-command rollback that restores the previous version. Relay does not let you choose a deployment strategy without configuring its failure path, the rollback procedure is part of the same output, not a separate exercise.

Auditing pipelines for security and performance

The relay-audit skill is what you run when you have a working pipeline that you suspect is slower, less secure, or less reliable than it should be. Relay audits the existing CI/CD configuration for four categories of problem: performance bottlenecks that slow developer feedback loops (cache keys that never hit, test suites that run serially when they could run in parallel, large build contexts that take thirty seconds to upload before the build starts), security gaps (secrets hardcoded in YAML, over-permissioned service accounts that have write access to unrelated repositories, Docker images pulled from unverified sources), reliability issues (missing retry logic for flaky network operations, deployment steps with no health check validation, test failures that do not block deployment), and developer experience problems (cryptic failure messages that do not tell the engineer what they need to fix, notifications that alert the wrong people, job names that do not describe what the job does). Each finding includes the specific configuration change needed, not just the category of problem.

End-to-end ship workflow

The relay-ship skill is Relay's non-interactive end-to-end ship workflow, the one you reach for when the work is done and you want to get it from a local branch into a pull request without the manual dance of merging base, running tests, reviewing the diff, bumping the version, committing, pushing, and creating the PR. Relay runs all of those steps in sequence, stops only for genuine judgment calls (a test failure that needs a human decision, a version bump that has a non-obvious correct answer), and surfaces the result as a PR ready for review. For teams running on Claude Code, relay-ship is the standard end-of-session workflow, it takes the mechanical work out of shipping and ensures that nothing is accidentally skipped. The non-interactive design means it runs to completion without prompting for input on steps that have deterministic correct answers, which is important for teams that want to run it as part of a larger automated workflow.

Tonone's Relay relay-ship skill runs the complete end-to-end ship workflow, merge base, test, review, version bump, commit, push, PR, stopping only for genuine judgment calls, not mechanical steps.

A worked example

A team is migrating from a manual deploy script to a proper CI/CD pipeline for a Node.js API service deployed to GKE. They hand Relay the brief: "Build a GitHub Actions pipeline with unit tests, Docker build, and a canary deployment to GKE." Relay produces the following GitHub Actions workflow, with secrets managed correctly, build cache optimization, canary deployment gates, and automatic rollback on error rate threshold.

# relay-pipeline output, GitHub Actions, Node.js API → GKE canary deploy
name: CI/CD

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

env:
  REGISTRY: us-central1-docker.pkg.dev
  IMAGE: ${{ env.REGISTRY }}/acme-prod/api/server

jobs:
  test:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'npm'
      - run: npm ci
      - run: npm test -- --ci --coverage
      - uses: actions/upload-artifact@v4
        with:
          name: coverage
          path: coverage/lcov.info

  build:
    needs: test
    runs-on: ubuntu-24.04
    if: github.ref == 'refs/heads/main'
    permissions:
      contents: read
      id-token: write  # Workload Identity, no long-lived keys
    steps:
      - uses: actions/checkout@v4
      - uses: google-github-actions/auth@v2
        with:
          workload_identity_provider: ${{ secrets.WIF_PROVIDER }}
          service_account: ${{ secrets.WIF_SA }}
      - uses: docker/setup-buildx-action@v3
      - uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ${{ env.IMAGE }}:${{ github.sha }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

  deploy-canary:
    needs: build
    runs-on: ubuntu-24.04
    environment: production  # Requires manual approval gate
    steps:
      - uses: google-github-actions/get-gke-credentials@v2
        with:
          cluster_name: acme-prod
          location: us-central1
      # Shift 10% traffic to new image; auto-rollback if error_rate > 1%
      - run: |
          kubectl set image deployment/api-canary \
            server=${{ env.IMAGE }}:${{ github.sha }}
          kubectl rollout status deployment/api-canary --timeout=300s

This is the workflow a senior DevOps engineer would produce, Workload Identity Federation instead of long-lived service account keys, build cache configured for GitHub Actions cache backend, a deployment gate via GitHub Environments that requires manual approval before production traffic shifts, and a canary deployment that reports rollout status. The team gets a pipeline that is secure, fast, and safe to run on the first try, not a template that requires three debug sessions before the first successful deployment.

Relay vs the alternatives

Relay does not compete with CI/CD documentation, it is the engineer who reads the documentation, knows which parts apply to your stack, and builds the pipeline with all the production requirements in place. The comparison below shows where Relay adds value that generalist tools and autocomplete cannot provide.

Install and try

Tonone is free and MIT-licensed. Install it once and all 23 agents, including Relay, are available in your Claude Code session.