CI/CD Configuration Converter

Paste a CI workflow and instantly get the equivalent in another platform — with side-by-side diff, confidence-annotated audit log, and zero upload. 100% in your browser.

What it does

Four major platforms

GitHub Actions, GitLab CI, CircleCI, and Bitbucket Pipelines — every direction (12 pairs).

Confidence-annotated output

Every translation is tagged with a confidence level: lossless, lossy, approximated, manual-review, or unsupported. The audit panel surfaces every transformation.

200+ component mappings

Actions like actions/checkout, setup-node, setup-python, docker/build-push, aws-actions/configure-aws-credentials translate to native equivalents on every other platform. Less common components fall back to shell.

Round-trip validation

Optional A → B → A check shows the diff against your original input — see exactly what the conversion lost.

Auto-detect source platform

Drop a file or paste YAML; the tool infers GitHub Actions / GitLab CI / CircleCI / Bitbucket from filename and top-level keys.

Markdown audit report

Download a structured audit (translations, secrets to recreate, schema validation results) as a single .md file you can paste into a PR description.

Schema-aware validation

Output is structurally validated against the target platform's shape; structural errors surface as a top-of-output banner rather than landing in your repo.

100% browser-side

No upload, no API. The YAML never leaves the browser. Share links use the URL fragment, which is also never sent to a server.

How to use CI/CD Configuration Converter

  1. 1
    Paste or open your YAML

    Paste a CI workflow into the left editor or click "Open file" to pick a local file. The source platform is auto-detected.

  2. 2
    Pick a target platform

    Use the From / To dropdowns. The right editor updates live as you type.

  3. 3
    Review the audit panel

    Every transformation is logged with a confidence chip. Toggle "Review only" to filter to items needing manual verification.

  4. 4
    Run a round-trip check (optional)

    Tick "Run round-trip check" to convert A → B → A and see the diff against your original. A non-empty diff highlights what couldn't be losslessly preserved.

  5. 5
    Copy, download, or share

    Copy the converted YAML, download it with the correct filename for the target, export the audit as Markdown, or copy a share link (state lives in the URL fragment — never uploaded).

When to use this

Switching CI providers

Your team is migrating from CircleCI to GitHub Actions for plan reasons. Paste each .circleci/config.yml workflow, get a GitHub Actions equivalent, and use the audit log as the migration checklist.

Standardising a multi-repo org

Your org has 30 repos split across GitHub and GitLab. Convert the GitLab pipelines to GitHub Actions one-by-one to land them on a single platform.

Evaluating a new platform

You're deciding whether to move from Bitbucket to GitLab. Paste a representative pipeline to see what conversion would actually look like before committing.

Learning a new platform

You're comfortable with GitHub Actions but new to CircleCI. Paste your familiar workflow and study the converted output to learn the equivalent CircleCI primitives.

Documenting a legacy pipeline

A long-lived CircleCI config has accumulated complexity. Convert it to GitHub Actions to get a simplified, modern shape — even if you don't actually migrate.

Common errors & fixes

"Workflow root must be a YAML mapping"
Your input is a list or scalar at the top level. Make sure the file starts with name:, on:, jobs:, stages:, version:, pipelines:, etc., not a leading dash.
"No mapping for X component"
The component is not in the bundled database. The converter emits a stub with a TODO comment. Submit a PR to expand the mapping database, or write the equivalent shell yourself.
"Output failed structural validation"
A converted job is missing a required key (runs-on, image, script, etc.). Read the audit panel for the exact path and fill in the missing piece manually before deploying.
Round-trip diff is huge
A non-empty round-trip diff is normal for any platform-specific feature without a true equivalent (matrix shapes, manual approval gates, dynamic config). Review each diffed line — most are aesthetic, not semantic.
Secret references are unresolved
The converter never substitutes secret values — it only renames the references. Open the audit-report Markdown to find the secrets-to-recreate checklist, then create them on the target platform.

Technical details

Supported platformsGitHub Actions, GitLab CI, CircleCI 2.1, Bitbucket Pipelines
Conversion modelSource YAML → canonical Intermediate Representation (IR) → target YAML
YAML libraryjs-yaml (browser-side parsing only)
Mapping database sizeCurated set of widely-used Actions, orbs, and pipes (browse /mappings)
Confidence levelslossless, lossy, approximated, manual-review, unsupported
URL stateCompressed via lz-string, stored in URL fragment (#) so it never reaches a server
PrivacyNo upload, no analytics on YAML content; standard pageview analytics only

Why every CI platform looks similar but converts poorly

All four platforms model the same thing: a graph of jobs that run on a runner, depend on each other, and emit artifacts. The differences are in *vocabulary* and *defaults*: what a job's container is called, how dependencies are declared, where caching is configured, and how reusable steps are packaged.

The vocabulary differences are mostly mechanical and the converter handles them deterministically. The default differences are more interesting: GitLab clones automatically and you remove the checkout step; GitHub doesn't and you must add it. CircleCI requires explicit `save_cache` + `restore_cache` pairs while GitLab has a single job-level block. Bitbucket has a small built-in cache catalog that handles 80% of cases without you specifying paths. The converter encodes all these defaults so output looks idiomatic on the target.

When automated conversion is worth it (and when it isn't)

Automated conversion shines when your pipeline is conventional: standard language test runs, Docker builds, artifact uploads, basic deploys. For these the converter handles 90% of the work and the audit log catches the rest.

It struggles with custom JavaScript Actions, custom orbs, dynamic config, complex matrix logic, and platform-specific UI integrations (deploy environments, approval gates, schedules). For those, treat the converter's output as a *starting point*, not the finished migration. The TODO comments and audit log give you a clear punch list of what to do by hand.

The single biggest accelerant: paste your converted YAML into the target platform's lint endpoint (GitHub Actions: `actionlint`; GitLab: CI Lint UI; CircleCI: `circleci config validate`; Bitbucket: validate via the YAML editor). The combination of confidence-annotated output + target-platform lint + a round-trip check catches every reasonable conversion bug in minutes, not hours.

How the IR works and why it's public

Internally, the converter parses every input into a single Intermediate Representation (IR) — a TypeScript type that models pipelines, jobs, steps, triggers, matrix builds, caches, artifacts, and conditionals as platform-neutral concepts. Every emitter consumes only the IR; every parser produces only the IR. This keeps the matrix of supported directions tractable: 4 parsers + 4 emitters give you 16 directions (12 cross-platform), not 16 hand-written translators.

The IR's schema is published verbatim as a TypeScript file you can read. That's the point: you can audit exactly what the converter understands about each platform and predict ahead of time which features will translate well and which won't. The mapping database — the part that translates Actions / orbs / pipes — is similarly browsable.

Frequently Asked Questions

Does my YAML get uploaded anywhere?

No. The converter is a static page. Parsing, translation, schema validation, and audit-report generation all run in your browser tab. Share links encode state in the URL fragment (`#`), which is never sent to a server.

Which CI platforms are supported?

GitHub Actions, GitLab CI, CircleCI 2.1, and Bitbucket Pipelines — all 12 directional pairs. Azure Pipelines, Travis CI, Drone, Jenkins, and Buildkite are on the roadmap.

How accurate is the conversion?

Pipelines that stick to common Actions, language setups, caches, artifacts, and triggers convert with high fidelity (lossless or lossy with a clear note). Pipelines that lean heavily on custom Actions, orbs, or platform-specific UI integrations get more manual-review and unsupported flags. Every transformation is annotated, so you know exactly where to verify.

Why isn't my custom Action / orb / pipe translated?

The converter ships with a curated mapping database of the most-used components. Anything outside it falls back to a stub-with-warning so you can fill it in by hand. Adding a mapping is a code change; we expand the database with each release.

How are secrets handled?

The converter never reads or substitutes secret values. It detects secret references (e.g. `${{ secrets.NAME }}`, `$NAME`) and produces a checklist in the audit-report Markdown so you can recreate them on the target platform.

What is the round-trip check?

A button labelled "Run round-trip check" converts your input from source to target and back to source, then shows the diff against the original. A non-empty diff is normal — every conversion involves at least one platform-specific decision — but it's the easiest way to surface what your target platform cannot represent.

Does it work offline?

Yes. Once the page is loaded, conversion, validation, and audit-report generation work without network. The page weight is small and cached aggressively.

Related Tools