UtilityKit

500+ fast, free tools. Most run in your browser only; Image & PDF tools upload files to the backend when you run them.

GitHub Actions Workflow Generator

Generate starter CI/deploy workflow YAML for common project types.

About GitHub Actions Workflow Generator

GitHub Actions Workflow Generator on UtilityKit creates ready-to-use YAML workflow files for common CI/CD patterns — CI test runs, Docker image builds and pushes, automated deployments, and pull-request checks — without requiring you to memorise the GitHub Actions YAML schema. Select your trigger events (push, pull_request, schedule, workflow_dispatch), pick one or more job templates (lint, test, build, deploy), configure your runtime environment, and the generator assembles a syntactically valid `.github/workflows/` file you can drop into your repository. Each generated workflow follows GitHub's official recommendations: pinned action versions, explicit permissions blocks, concurrency groups to cancel redundant runs, and secret references rather than hard-coded credentials. Ideal for teams setting up CI for the first time and engineers who want a correct scaffold without wading.

Why use GitHub Actions Workflow Generator

Schema-Correct YAML

The generator produces syntactically valid workflow YAML that passes GitHub's schema validation on the first push, eliminating the red-X loop of fixing indentation errors.

Pinned Action Versions

All `uses:` references include the recommended version pin (e.g. `actions/checkout@v4`) so your workflow does not silently break when an action publishes a breaking change.

Security Hardened

Generated workflows include explicit `permissions:` blocks scoped to minimum required access, and reference secrets by name rather than embedding credentials.

Concurrency Groups

Automatic concurrency group configuration cancels in-progress runs on the same branch when a new push arrives, saving CI minutes on fast-moving branches.

Multiple Trigger Types

Supports push, pull_request, schedule (cron), and workflow_dispatch triggers — mix and match for complex CI/CD pipelines without hand-writing every trigger block.

No Account or CLI Required

Runs entirely in your browser. No GitHub login, no CLI tools, and no Actions billing required to generate, copy, and inspect workflows.

How to use GitHub Actions Workflow Generator

  1. Choose your workflow trigger events: push to main, pull_request targeting main, manual workflow_dispatch, or a cron schedule.
  2. Select the job templates you need: Lint (ESLint / flake8), Test (unit tests with coverage), Build (Docker image), or Deploy (SSH / cloud provider).
  3. Set your runner OS — ubuntu-latest is the default; macOS and Windows runners are also available for cross-platform projects.
  4. Configure environment details: Node/Python/Go version matrix, package manager cache strategy, and any required secrets by name.
  5. Toggle optional features: concurrency group (cancel in-progress runs on new push), artifact upload (test reports, build artefacts), and status badges.
  6. Click Generate Workflow, then copy the YAML or download it. Save the file as `.github/workflows/<name>.yml` in your repository and push it.

When to use GitHub Actions Workflow Generator

  • When setting up CI for a new repository and you want a test-and-lint workflow without reading the entire GitHub Actions documentation.
  • When adding automated Docker builds and pushes to GHCR or Docker Hub for the first time and need the correct `docker/login-action` and `docker/build-push-action` sequence.
  • When you want a pull-request check that blocks merges unless tests pass, and need the correct `pull_request` trigger with branch filters.
  • When migrating a project from CircleCI or Jenkins and need an equivalent GitHub Actions YAML to compare and adapt.
  • When teaching a team how GitHub Actions works and you need a commented, readable example to walk through step by step.
  • When you need a scheduled nightly job (cron trigger) to run integration tests or dependency audits without writing cron syntax from memory.

Examples

Node.js CI on push and PR

Input: Trigger: push + pull_request, Job: Test, Runtime: Node 20, Cache: npm

Output: name: CI on: push: branches: [main] pull_request: branches: [main] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: '20' cache: 'npm' - run: npm ci - run: npm test

Docker build and push to GHCR

Input: Trigger: push to main, Job: Build + Push, Registry: ghcr.io

Output: name: Docker on: push: branches: [main] jobs: build: runs-on: ubuntu-latest permissions: contents: read packages: write steps: - uses: actions/checkout@v4 - uses: docker/login-action@v3 with: registry: ghcr.io username: ${{ github.actor }} password: ${{ secrets.GITHUB_TOKEN }} - uses: docker/build-push-action@v5 with: push: true tags: ghcr.io/${{ github.repository }}:latest

Scheduled nightly dependency audit

Input: Trigger: cron 02:00 UTC daily, Job: Audit, Runtime: Node 20

Output: name: Nightly Audit on: schedule: - cron: '0 2 * * *' jobs: audit: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: { node-version: '20', cache: 'npm' } - run: npm ci - run: npm audit --audit-level=high

Tips

  • Use `workflow_dispatch` as a second trigger alongside `push` so you can re-run the workflow manually from the GitHub UI without pushing a dummy commit — invaluable for debugging flaky tests.
  • Cache your dependency install step with `actions/cache` or the built-in cache option in `actions/setup-node`. A warm cache turns a 90-second `npm ci` into a 5-second restore.
  • Set `continue-on-error: true` on linting steps in PRs so lint failures are visible but do not block the more important test results from completing.
  • Use environment protection rules in GitHub repository settings to gate deploy jobs behind a manual approval step — this prevents accidental production deploys on every merge.
  • Prefix test-and-build workflow names with an emoji status (e.g. `🧪 CI`) to make the checks panel easier to scan at a glance in pull-request status summaries.

Frequently Asked Questions

Where do I put the generated workflow file?▾
Create the directory `.github/workflows/` in your repository root if it does not exist, then save the file with a descriptive name such as `ci.yml` or `deploy.yml`. GitHub automatically detects and runs workflows in this directory.
Should I pin action versions with SHA hashes or version tags?▾
For security-sensitive steps (checkout, secrets access), SHA pinning is recommended by GitHub because version tags are mutable. For non-security steps in private projects, version tags like `@v4` are pragmatic. The generator defaults to version tags for readability and notes where SHA pinning is advisable.
Why does the workflow include an explicit `permissions:` block?▾
GitHub Actions grants `GITHUB_TOKEN` read/write permissions to all scopes by default in older configurations. Restricting permissions to only what the job needs (e.g. `contents: read`, `packages: write`) is a supply-chain security best practice and required by many security benchmarks.
How do I reference repository secrets in the workflow?▾
Use `${{ secrets.YOUR_SECRET_NAME }}` syntax anywhere in the YAML. Secrets must be added under your repository's Settings → Secrets and variables → Actions before the workflow runs. The generator includes placeholder names (e.g. `DOCKER_PASSWORD`) that you replace with your actual secret names.
What is a concurrency group and when should I use it?▾
A concurrency group ensures only one workflow run is active per branch at a time. When a new push arrives, the in-progress run is cancelled. This saves CI minutes on branches with rapid commits and prevents stale deployments from completing after a newer push supersedes them.
Can I add multiple jobs with dependencies between them?▾
Yes. Use the `needs:` field on a job to declare a dependency. For example, `needs: test` on a `deploy` job ensures deployment only runs after the test job completes successfully. The generator supports up to three sequential job stages: build → test → deploy.
Does the generator support matrix builds?▾
Yes. Enable the matrix option to generate a `strategy.matrix` block that runs your test job across multiple runtime versions (e.g. Node 18, 20, 22) or operating systems simultaneously, giving you cross-version compatibility coverage without duplicating jobs.
Will the generated workflow work on private repositories?▾
Yes, with the same considerations as any Actions workflow on a private repo. Note that private repos on GitHub Free have a monthly Actions minutes budget. The concurrency group option helps reduce unnecessary minute consumption on active branches.

Explore the category

Schema JSON-LD Generator Generate JSON-LD for common schema types using guided forms. JSON to TypeScript Generate TypeScript types and interfaces from JSON samples. License Generator Generate common OSS license templates with year and copyright holder. README Generator Generate markdown README scaffolds from core project fields. Htaccess Snippet Generator Generate common Apache .htaccess snippet blocks and merge selections. Nginx Snippet Generator Generate and merge common Nginx config snippets for deployment baselines.
YAML Explained: Configuration Made Human-Readable YAML is everywhere in DevOps — Docker Compose, Kubernetes, GitHub Actions, Ansible. Its indentation-sensitive syntax looks clean but has sha Mar 2026 · 8 min JSON vs YAML vs TOML: When to Use Which Config Format JSON, YAML, and TOML each solve a different problem — but pick the wrong one and you'll spend Friday night chasing a whitespace bug. Here's Mar 2026 · 11 min

Glossary

Workflow
A configurable automated process defined in a YAML file under `.github/workflows/`. A workflow contains one or more jobs triggered by repository events.
Job
A set of steps that run on the same runner in a workflow. Jobs run in parallel by default; use `needs:` to sequence them.
Runner
The virtual machine or container that executes a job. GitHub provides hosted runners (ubuntu-latest, windows-latest, macos-latest) or you can register your own self-hosted runners.
GITHUB_TOKEN
An automatically generated short-lived token provided to every workflow run, scoped to the repository. Used to push packages, comment on PRs, and create releases without storing a personal access token.
Concurrency group
A named slot that limits simultaneous workflow runs. When a new run starts with the same group key, the in-progress run is cancelled, preventing redundant CI work.
Matrix strategy
A workflow feature that fans out a single job across multiple parameter combinations (e.g. OS × runtime version) and runs them in parallel, providing broad compatibility coverage efficiently.