CircleCI

CircleCI #

CircleCI is a cloud CI/CD platform focused on fast builds, reusable configuration, parallel execution, caching, and straightforward project onboarding.

Overview #

CircleCI pipelines are defined in .circleci/config.yml. Configuration includes jobs, executors, commands, orbs, workflows, contexts, and deployment steps. CircleCI fits teams that want hosted CI speed without operating their own build controllers, while still allowing self-hosted runners where needed.

Best use cases #

  • Product teams that want quick CI/CD setup and fast feedback loops.
  • Repositories that benefit from caching, test splitting, matrix jobs, or parallel execution.
  • Organizations that standardize common tasks with reusable orbs and commands.
  • Teams deploying containers, packages, serverless functions, or cloud applications.
  • Projects that need hosted CI plus selective self-hosted runners for private environments.

Minimal pipeline example # 

version: 2.1

jobs:
  test:
    docker:
      - image: cimg/node:22.0
    steps:
      - checkout
      - restore_cache:
          keys:
            - npm-{{ checksum "package-lock.json" }}
      - run: npm ci
      - save_cache:
          key: npm-{{ checksum "package-lock.json" }}
          paths:
            - ~/.npm
      - run: npm test

workflows:
  ci:
    jobs:
      - test

Secrets handling #

  • Store sensitive values in project environment variables or organization contexts.
  • Use restricted contexts to limit which projects or teams can access deployment credentials.
  • Prefer OIDC or short-lived cloud credentials when available for the deployment target.
  • Avoid printing secrets in job output and do not store secrets in caches, workspaces, or artifacts.
  • Separate staging and production credentials into different contexts with different access rules.

Deployment options #

  • Deploy with shell commands, cloud CLIs, Terraform, OpenTofu, Helm, kubectl, or reusable orbs.
  • Build and push container images to cloud registries, then deploy to Kubernetes or managed platforms.
  • Use workflows and branch filters to run deployment jobs only on approved branches or tags.
  • Use self-hosted runners for private networks, restricted data, or specialized infrastructure.
  • Integrate with GitOps by updating deployment repositories after successful builds and scans.

Security considerations #

  • Review orbs before use and pin orb versions for predictable behavior.
  • Restrict contexts and production jobs to trusted branches, tags, and teams.
  • Keep self-hosted runners isolated, patched, and scoped by trust boundary.
  • Avoid sharing caches across unrelated trust levels because cached data can affect later builds.
  • Add dependency, SAST, secret, IaC, and image scanning before deployment jobs.