What's the difference between a job and the workflow?

Jobs define what runs (a sequence of steps like checkout, run commands, and caching) and where (which Docker image). The workflow then wires jobs together and controls execution, in this generator every job you add runs as part of a single named workflow, in the order you listed them.

What do orbs actually add to the config?

Orbs are reusable, versioned packages of CircleCI configuration. Enabling the Node or AWS CLI orb here just adds the corresponding `orbs:` entry (`circleci/node@5` or `circleci/aws-cli@4`) to the top of your config; you'd still reference the orb's commands or jobs elsewhere in your config to actually use them.

How does save_cache work with the cache key I provide?

CircleCI caches are keyed by the exact key string you provide, commonly something like `deps-{{ checksum "package-lock.json" }}` so the cache invalidates automatically when your lockfile changes. If you don't provide a key, no `save_cache` step is added to that job.

Why does my job need at least a checkout step or a run command?

A CircleCI job with an empty `steps:` list is invalid configuration, CircleCI needs at least one thing to actually do. Enabling checkout, adding a run command, or both, satisfies this requirement.

CircleCI Config Generator - Build a config.yml

Overview

Introduction

CircleCI's config.yml has a specific three-part shape, jobs, workflows, and optionally orbs, and it's easy to define a job correctly but forget to actually reference it from a workflow, so nothing runs.

This tool generates a complete, valid .circleci/config.yml from a form, wiring every job you define into a single workflow automatically so nothing gets left orphaned.

What Is CircleCI Config Generator?

A form-driven generator for CircleCI 2.1 configuration. You set a shared Docker executor image, add one or more jobs (each with an optional checkout step, run commands, and an optional save_cache step), name a workflow, and optionally enable the Node or AWS CLI orbs.

Every job you define is automatically added to the generated workflow's job list, so the config is runnable as soon as it's generated.

How CircleCI Config Generator Works

Each job becomes its own entry under `jobs:`, using the shared executor image under `docker:`, with `steps:` built from the checkout toggle, one `run:` entry per command line, and an optional `save_cache:` step if you provided a cache key.

The workflow section lists every job by name in the order they were added, which is enough for CircleCI to run them (in parallel, by default, unless you add `requires:` dependencies afterward).

When To Use CircleCI Config Generator

Use it when setting up CircleCI for a new project and you want a complete, working config.yml instead of assembling the jobs/workflows structure from scratch.

It's also useful for quickly producing a config to demonstrate a build pipeline before fine-tuning caching keys and orb usage.

Often used alongside GitLab CI Generator, GitHub Actions Workflow Generator and Jenkins Pipeline Generator.

Features

Advantages

Automatically wires every defined job into the workflow, so there's no risk of writing a job that never actually runs.
Generates correctly structured `save_cache` steps with your cache key and path, rather than requiring you to remember CircleCI's caching syntax.
Supports adding the Node and AWS CLI orbs with a single toggle each.

Limitations

Jobs all share one executor image; per-job executors, machine executors, and self-hosted runners aren't covered.
The generated workflow runs all jobs without ordering dependencies (`requires:`); add those manually if jobs must run sequentially.

Examples

A single build-and-test job

Input

executor: cimg/node:20.11; job 'build' (checkout: yes, run: npm install / npm test); workflow: main

Output

version: 2.1

jobs:
  build:
    docker:
      - image: cimg/node:20.11
    steps:
      - checkout
      - run: npm install
      - run: npm test

workflows:
  main:
    jobs:
      - build

The job's checkout toggle and run commands become ordered steps, and the workflow references the job by name.

Best Practices & Notes

Best Practices

Give jobs names that describe what they do (build, test, deploy) rather than generic names, this keeps the CircleCI dashboard's job list readable.
Use a checksum-based cache key (e.g. based on your lockfile) rather than a static string, so caches invalidate automatically when dependencies change.
Split long-running concerns (build vs. test vs. deploy) into separate jobs so CircleCI can show you exactly which stage failed.

Developer Notes

The generator always emits `version: 2.1` since orbs and the modern workflow syntax both require it; jobs are rendered in insertion order under both `jobs:` and the workflow's `jobs:` list to keep the two sections easy to cross-reference by eye. Cache paths default to `node_modules` when a key is set but no path is specified, since that's the overwhelmingly common CircleCI caching case for JS projects.

CircleCI Config Generator Use Cases

Scaffolding CircleCI for a new repository that doesn't have a config.yml yet
Adding a caching step to speed up an existing job without hand-writing the save_cache block
Producing a quick multi-job pipeline to demonstrate CircleCI's structure to a team

Common Mistakes

Defining a job but forgetting to add it to any workflow, so it exists in the config but never actually runs, this generator avoids that by auto-wiring every job into the workflow.
Using a static cache key that never changes, so the cache silently goes stale and dependencies never actually get reinstalled from a fresh lockfile.

Tips

Add `requires:` between jobs in the workflow after generation if your build must finish before your deploy job starts, CircleCI runs unordered jobs in parallel by default.

CircleCI Config Generator