CI/CD Pipeline Generator
Write your pipeline as a simple list of steps, install, lint, test, build and deploy, and get it in the syntax of the CI/CD platform you use: GitHub Actions, GitLab CI, Bitbucket Pipelines, Azure Pipelines, CircleCI or a Jenkinsfile. CI steps run for every change, deploy steps only on the main branch, and secrets are referenced the way each platform expects.
- Runs in your browser
- No sign-up
- Free to use
How to use CI/CD Pipeline Generator
- Choose the platform and the container image.
- List the steps as name: command.
- Add variables and the names of secrets.
- Save the file under the name shown in the notes.
CI/CD Pipeline Generator features
Six platforms
GitHub, GitLab, Bitbucket, Azure, CircleCI and Jenkins.
CI and CD
Steps named deploy run only on the main branch.
Containers
All jobs run in the image you choose.
Variables
Environment variables in each platform’s syntax.
Secrets
secrets.X, protected variables, env mappings or credentials().
Notes
Where to save the file and where to store secrets.
When to use CI/CD Pipeline Generator
- Moving a project from one CI service to another.
- Supporting the same build on several platforms.
- Comparing how CI platforms express the same pipeline.
- Creating a first pipeline without learning each syntax.
CI/CD Pipeline Generator FAQ
How is a deploy step recognised?
Any step whose name starts with deploy becomes part of a deployment job that only runs for the main branch, after the CI job succeeded.
How are secrets handled?
You list only their names. The pipeline references them as ${{ secrets.NAME }} in GitHub, variables in GitLab and Bitbucket, mapped env in Azure, contexts in CircleCI and credentials() in Jenkins; the values stay in the platform’s secret store.
Does the install step run twice?
Yes, deployment jobs repeat install steps because each job starts in a fresh container.
What about platform-specific features?
The generated files cover the common core: jobs, images, variables, branches and secrets. Add caching, matrices or approvals with the platform’s own options.
Where do I save the file?
The notes give the exact path: .github/workflows/ci.yml, .gitlab-ci.yml, bitbucket-pipelines.yml, azure-pipelines.yml, .circleci/config.yml or Jenkinsfile.
Is anything uploaded?
No. Everything is generated in your browser.
The same pipeline everywhere
Most pipelines do the same few things: start a container with the right tools, install dependencies, run checks and tests, build, and, on the main branch, deploy. Yet every CI/CD platform describes this differently: GitHub has workflows and jobs, GitLab has stages and scripts, Bitbucket has pipelines and steps, Azure has stages and deployment jobs, CircleCI has jobs and workflows, and Jenkins has a Groovy pipeline.
This generator separates what you want from how a platform spells it. You list steps once as name: command; steps whose names start with deploy form the delivery part. The generator then writes a CI job with the other steps for pushes and pull requests, and a deploy job that depends on it and runs only for the main branch.
Each platform gets its idiomatic form. GitHub uses a container job and an if condition on the ref; GitLab uses stages and rules; Bitbucket uses branch and pull-request pipelines with a deployment environment; Azure uses stages with a deployment job; CircleCI uses a workflow with branch filters; Jenkins uses stages with when { branch } and a Docker agent.
Variables become environment settings in each format. Secrets are never written into the file: you list their names, and the generated pipeline reads them from the platform’s secret storage, with notes explaining where to add them.
The output is a solid starting point that runs on each platform. From there, add the platform-specific features you need, such as caches, matrices, approvals or artifacts.