Use this free online GitLab CI Generator directly in your browser. No signup required, no data leaves your device. Part of Utilier — a collection of 133+ developer utilities.
What is GitLab CI/CD Pipeline Generator?
GitLab CI/CD is GitLab's built-in continuous integration and deployment platform. This tool generates .gitlab-ci.yml pipeline configuration files for common workflows — Node.js testing, Python testing, Docker build/push, Kubernetes deployment, static site deployment. Select pipeline type, configure stages (build, test, deploy), jobs, scripts, and copy the YAML to the root of your GitLab repo. Validates YAML syntax, suggests optimizations (caching, artifacts, rules), and checks for security issues (exposed secrets).
Multi-stage pipelines: Organize jobs into stages (build, test, deploy). Stages run sequentially, jobs within stages run in parallel. Example: test stage waits for build, deploy waits for test.
Rules and conditions: Control when jobs run with rules: only/except branches, manual triggers, schedule-only jobs. Example: deploy only on main branch, test on all branches.
Caching and artifacts: Cache dependencies (node_modules, pip) for faster builds. Artifacts pass files between jobs (build produces dist/, deploy consumes it).
Writing GitLab CI/CD pipelines manually requires knowledge of YAML syntax, stages, rules, caching, and variables. This tool generates pipelines with best practices.
Avoid syntax errors: YAML indentation errors, missing stages, or invalid keys break pipelines. Tool validates syntax before commit.
Learn pipeline structure: See how stages, jobs, script, rules, artifacts, cache work together. Great for learning GitLab CI/CD.
Save time: No need to search GitLab docs for syntax or examples. Tool generates production-ready pipelines instantly.
Caching and artifacts: Tool auto-configures caching (node_modules, .m2) and artifacts (build outputs). Reduces build time and passes files between jobs.
Security best practices: Uses CI/CD variables for secrets ($CI_JOB_TOKEN, $DOCKER_PASSWORD), not hardcoded. Masks sensitive outputs.
Multi-environment support: Separate deploy jobs for dev, staging, production. Use environments and manual approvals for production deploys.
When to use GitLab CI generator
Use whenever you need to automate CI/CD pipelines on GitLab repositories.
Setting up CI for Node.js, Python, Java, Go projects (test on push, merge request).
Building and pushing Docker images to GitLab Container Registry or Docker Hub.
Deploying to Kubernetes (kubectl apply) or cloud platforms (AWS, GCP, Azure).
Deploying static sites to GitLab Pages (Hugo, Jekyll, React).
Define stages: Set pipeline stages: build, test, deploy (default). Jobs are grouped into stages. Stages run sequentially, jobs within stages run in parallel.
Configure jobs: Add jobs per stage. Each job has: image (Docker image), script (commands), rules (when to run), cache (dependencies), artifacts (outputs).
Set rules (optional): Control when jobs run: only: [main] (main branch only), rules: if: $CI_PIPELINE_SOURCE == 'merge_request_event' (on MR), when: manual (manual trigger).
Add caching (optional): Enable caching for node_modules, .m2, pip. Tool adds cache: paths: [node_modules/] with key for faster builds.
Commands to run in job. Array of shell commands. Example: script: [npm ci, npm test]. Runs in Docker container.
rules
Control when job runs. if: $CI_COMMIT_BRANCH == 'main' (main branch), if: $CI_PIPELINE_SOURCE == 'merge_request_event' (MR), when: manual (manual trigger).
cache
Cache directories for faster builds. Example: cache: paths: [node_modules/] key: $CI_COMMIT_REF_SLUG. Reuses node_modules between runs.
artifacts
Files to pass between jobs or download. Example: artifacts: paths: [dist/, coverage/] expire_in: 1 week. Build job produces, deploy consumes.
variables
Environment variables. Set in .gitlab-ci.yml (variables: NODE_ENV: production) or Settings > CI/CD > Variables (secrets). Access: $VAR_NAME.
only/except (legacy)
Legacy syntax for branch filtering. only: [main] = run on main only. except: [dev] = run on all except dev. Replaced by rules (recommended).
Common mistakes to avoid
Not using caching, causing slow builds (re-downloading dependencies every time)
Why it happens: Without cache, npm install or pip install re-downloads all dependencies every run (5-10 min). Caching reduces to 10-30 sec. Common oversight for new users.
How to avoid it: Add cache: paths: [node_modules/] (Node.js), [.m2/repository/] (Maven), [~/.cache/pip] (Python). Use key: $CI_COMMIT_REF_SLUG for branch-specific cache.
Hardcoding secrets in script instead of using CI/CD variables
Why it happens: script: docker login -u admin -p password123 exposes secrets in logs and .gitlab-ci.yml. Anyone with repo access sees secrets. Common for beginners.
How to avoid it: Add secrets in Settings > CI/CD > Variables (e.g., DOCKER_PASSWORD, masked). Use in script: docker login -u admin -p $DOCKER_PASSWORD. GitLab masks output.
Using only: [main] for test jobs, skipping tests on feature branches
Why it happens: only: [main] runs job on main only. Tests don't run on feature branches or MRs, so bugs slip through. Common when copying deploy configs for test jobs.
How to avoid it: Remove only/except for test jobs (run on all branches). Or use rules: if: $CI_PIPELINE_SOURCE == 'merge_request_event' to test on MRs only.
Not using artifacts to pass files between jobs, causing deploy to fail
Why it happens: Each job runs in a new container (clean slate). Build job produces dist/, but deploy job doesn't have it (empty). Jobs don't share files unless using artifacts.
How to avoid it: In build job: artifacts: paths: [dist/]. In deploy job: dependencies: [build] (downloads artifacts from build). Files are passed between jobs.
Using docker:latest without docker:dind service, causing 'cannot connect to Docker daemon' error
Why it happens: docker:latest image has Docker CLI but no daemon. docker build fails with 'Cannot connect to Docker daemon'. Need docker:dind (Docker-in-Docker) service to run Docker commands.
How to avoid it: Add services: - docker:dind in Docker build jobs. Example: image: docker:latest services: - docker:dind. This starts Docker daemon for building images.
Frequently asked questions
Where do I put the .gitlab-ci.yml file?
In repo root (same level as README.md, package.json). GitLab automatically detects .gitlab-ci.yml in root and runs pipeline on push.
How do I add secrets (passwords, API keys) to pipelines?
Settings > CI/CD > Variables > Add variable. Set key (e.g., DOCKER_PASSWORD), value (secret), and check 'Mask variable'. Use in .gitlab-ci.yml: $DOCKER_PASSWORD.
What is the difference between only/except and rules?
only/except is legacy (only: [main] = run on main). rules is modern and more flexible (rules: if: $CI_COMMIT_BRANCH == 'main'). Use rules for new pipelines.
How do I pass files from build job to deploy job?
Use artifacts in build job: artifacts: paths: [dist/]. In deploy job: dependencies: [build] or needs: [build]. Files are downloaded from build artifact.
What is docker:dind and when do I need it?
docker:dind (Docker-in-Docker) is a service that runs Docker daemon inside a container. Needed for docker build, docker push in pipelines. Add: services: - docker:dind.
How do I manually trigger a job?
Add when: manual to job. Example: deploy: stage: deploy when: manual. Job appears in pipeline but doesn't run until you click 'Play' button in GitLab UI.
What are GitLab CI/CD free tier limits?
Free tier: 400 CI/CD minutes/month per namespace. Shared runners. Paid plans: 10,000 min/month. Self-hosted runners have no limits (use your own servers).