Skip to main content

CircleCI Config: config.yml, Orbs & Workflow Guide

CircleCI is built around speed — its test splitting and parallelism features can cut a 20-minute test suite to under 5 minutes. This guide walks through the complete config.yml structure, orbs for reusable logic, executor choices, and caching patterns — with practical examples you can drop into your project today.

✓ config.yml version/jobs/workflows ✓ Orbs (versioned reusable packages) ✓ Docker vs machine executor ✓ Parallelism & test splitting ✓ CircleCI vs GitHub Actions vs Travis
Share this tool: X / Twitter LinkedIn
✓ 60,000+ developers use DevPlaybook ★★★★★ 4.8 / 5 on Gumroad ✓ MIT licensed · Instant download ✓ No login required

Related Products

on Gumroad

You Might Also Need

More Free Tools

Enjoying this tool? Get more like it.

Weekly developer tool guides, productivity playbooks & AI tricks. Free. No spam.

DevPlaybook Pro 7 days free

Unlock AI-Powered Dev Tools

  • ⚡ AI Code Review, Doc Generator & SQL Builder
  • ⚡ All premium templates & early access
  • ⚡ Member discounts on Gumroad products
Start Free Trial →

$9/mo after trial · Cancel anytime

Want the full toolkit?

Get DevPlaybook Pro

Every template, guide, boilerplate, and automation script in one bundle. 13 premium products — grab them all at once and save big.

$79
$241 separately Save $162 (67% off)
Get DevPlaybook Pro — $79 →

MIT licensed · Instant download · No subscription

See what's included → Browse all deals →

config.yml Structure

CircleCI configuration lives at .circleci/config.yml. Use version: 2.1 to access orbs, commands, and executors. Jobs define the work; workflows orchestrate job order and conditions.

version: 2.1

orbs:
  node: circleci/[email protected]
  slack: circleci/[email protected]

executors:
  node-executor:
    docker:
      - image: cimg/node:20.0
    resource_class: medium

jobs:
  test:
    executor: node-executor
    parallelism: 4
    steps:
      - checkout
      - node/install-packages:
          pkg-manager: npm
      - run:
          name: Split and run tests
          command: |
            TESTFILES=$(circleci tests glob "src/**/*.test.ts" | \
              circleci tests split --split-by=timings)
            npx jest $TESTFILES --ci --runInBand
      - store_test_results:
          path: test-results/
      - slack/notify:
          event: fail
          template: basic_fail_1

  build:
    executor: node-executor
    steps:
      - checkout
      - node/install-packages
      - run: npm run build
      - persist_to_workspace:
          root: .
          paths: [dist]

workflows:
  ci-cd:
    jobs:
      - test
      - build:
          requires: [test]
          filters:
            branches:
              only: main

Caching Strategies

Proper caching is the single biggest lever for build speed in CircleCI. Cache dependencies on the lockfile checksum and always provide a fallback key to avoid cold-cache runs on every dependency change.

steps:
  - restore_cache:
      keys:
        # Exact match on lockfile — fastest cache hit
        - node-deps-v2-{{ checksum "package-lock.json" }}
        # Fallback: restore most recent cache for this branch
        - node-deps-v2-{{ .Branch }}-
        # Final fallback: any cache
        - node-deps-v2-

  - run: npm ci

  - save_cache:
      key: node-deps-v2-{{ checksum "package-lock.json" }}
      paths:
        - ~/.npm
        - node_modules/

  # Workspaces pass artifacts between jobs in the same workflow
  - persist_to_workspace:
      root: ~/project
      paths: [dist/]

# In a downstream job:
  - attach_workspace:
      at: ~/project

Machine Executor for Docker Builds

When you need to build Docker images or run Docker Compose services, switch to the machine executor. It gives you a full Ubuntu VM with Docker pre-installed and support for Docker layer caching — which can reduce image build time by up to 80%.

build-image:
  machine:
    image: ubuntu-2204:current
    docker_layer_caching: true   # requires Performance plan
  steps:
    - checkout
    - run:
        name: Build and push Docker image
        command: |
          echo "$DOCKER_PASSWORD" | docker login -u "$DOCKER_USERNAME" --password-stdin
          docker build -t myorg/myapp:$CIRCLE_SHA1 .
          docker tag myorg/myapp:$CIRCLE_SHA1 myorg/myapp:latest
          docker push myorg/myapp:$CIRCLE_SHA1
          docker push myorg/myapp:latest

CircleCI vs GitHub Actions vs Travis CI

Feature CircleCI GitHub Actions Travis CI
Test parallelism Best-in-class (time-based splitting) matrix strategy Limited
Reusable packages Orbs (versioned) Actions Marketplace None
Docker layer cache Yes (Performance plan) actions/cache (manual setup) No
Free tier 6,000 credits/mo 2,000 min/mo (private) Very limited (post-acquisition)
GitHub integration Via OAuth app Native, first-class Via OAuth app
Best for Large test suites, speed-critical CI GitHub-hosted projects Legacy projects (migrating away)

Frequently Asked Questions

How do I validate my CircleCI config.yml locally?▼

Use the CircleCI CLI: circleci config validate. It parses your config, resolves orbs, and reports syntax errors before you push. Install the CLI with brew install circleci (macOS) or the official Linux installer script. The circleci config process command also expands all orbs and anchors into their full form — useful for debugging what a third-party orb actually runs.

What are CircleCI orbs and why use them?▼

Orbs are reusable, versioned packages of CircleCI configuration — jobs, commands, and executors bundled together. For example, circleci/node@5 provides install-packages, test, and setup commands that handle Node.js best practices automatically. Use orbs when a third party (AWS, Slack, Datadog) has published one for their service — it saves writing 50+ lines of custom steps. Pin orbs to a specific version (e.g., circleci/[email protected]) to prevent unexpected breaking changes.

Docker executor vs machine executor — when to use each?▼

The docker executor spins up a fresh container from your chosen image — it is fast, lightweight, and ideal for most CI jobs (building Node apps, running Python tests). The machine executor provisions a full Linux VM (ubuntu-2204:current), giving you access to Docker daemon itself, nested virtualization, and system-level operations. Use machine when you need to build Docker images with layer caching, run Docker Compose services, or require privileged operations. machine is slower to start but more powerful.

How does CircleCI parallelism and test splitting work?▼

Set parallelism: N on a job and CircleCI spins up N identical containers running in parallel. Use the circleci tests split command with --split-by=timings to automatically distribute your test files across containers based on historical run times — balancing load for the shortest possible total duration. The split metadata is uploaded after each run, improving accuracy over time. This is CircleCI's standout feature for large test suites.

How do I cache dependencies between CircleCI jobs?▼

Use save_cache and restore_cache steps. Key your cache on the dependency lockfile checksum: key: node-deps-v1-{{ checksum 'package-lock.json' }}. When the lockfile changes, CircleCI busts the cache and reinstalls. Add a fallback key (node-deps-v1-) to restore the most recent cache on lockfile changes, then update only the changed packages. Caches are immutable once saved — bump the v1 prefix to force a full cache rebuild.

CircleCI vs GitHub Actions vs Travis CI — which should I pick?▼

CircleCI is the best choice when test suite speed is critical — its parallelism and test splitting features are class-leading. GitHub Actions wins for GitHub-native integration, the largest marketplace, and free public repo minutes. Travis CI was the pioneer but has declined since its acquisition; pricing changed dramatically and many teams have migrated away. For new projects on GitHub, GitHub Actions is the pragmatic default. For teams with large, slow test suites, CircleCI's parallelism ROI is often worth the cost.