Generate CI/CD pipeline configurations with Cursor by referencing your project's package.json, Dockerfile, and test scripts as @file context. Use .cursorrules to specify your CI platform (GitHub Actions, Azure DevOps, GitLab CI), and prompt Composer to create complete YAML pipelines with build, test, lint, and deploy stages.
Why Cursor Excels at CI/CD Configuration
CI/CD pipeline configuration is repetitive YAML that follows predictable patterns, making it ideal for AI generation. Cursor can generate complete pipeline files for GitHub Actions, Azure DevOps, GitLab CI, and other platforms when given the right project context. The key is referencing your package.json, Dockerfile, and test configuration so Cursor knows your exact build commands, dependencies, and deployment targets. This tutorial covers the complete workflow from initial generation through debugging pipeline failures.
Prerequisites
- Cursor installed (Pro recommended for agent mode)
- A project with a package.json or equivalent build config
- A target CI/CD platform (GitHub Actions, Azure DevOps, or GitLab CI)
- Basic understanding of CI/CD pipeline concepts
Step-by-step guide
Add CI/CD rules to your project
Add CI/CD rules to your project
Create a .cursor/rules/cicd.mdc file that specifies your CI/CD platform, deployment targets, and pipeline conventions. This ensures Cursor generates valid YAML for your specific platform and follows your team's conventions for stage naming, caching, and secrets management.
1---2description: CI/CD pipeline generation rules3globs: ".github/workflows/**, azure-pipelines.yml, .gitlab-ci.yml"4alwaysApply: false5---67- CI platform: GitHub Actions8- Node.js version: 229- Package manager: pnpm (use pnpm/action-setup@v4)10- Always cache node_modules using actions/cache11- Run in this order: install → lint → typecheck → test → build → deploy12- Use matrix strategy for Node 20 and 2213- Secrets are in GitHub Settings, reference with ${{ secrets.NAME }}14- Never hardcode secrets in YAML15- Add step-level comments explaining what each step does16- Use concurrency groups to cancel redundant runsPro tip: If you use Azure DevOps instead of GitHub Actions, change the platform line and Cursor will switch to azure-pipelines.yml syntax with pool, stages, and tasks instead of jobs and steps.
Expected result: CI/CD rules auto-attach whenever you edit pipeline configuration files.
Generate a complete pipeline with Composer
Generate a complete pipeline with Composer
Open Composer with Cmd+I and reference your project configuration files. Ask Cursor to generate a complete pipeline. The more context files you reference, the more accurate the generated YAML will be. Always include package.json for build commands and any Dockerfile for containerized deployments.
1// Prompt to type in Cursor Composer (Cmd+I):2// @package.json @Dockerfile @tsconfig.json @vitest.config.ts3// Generate a GitHub Actions CI/CD workflow at .github/workflows/ci.yml4// Requirements:5// - Trigger on push to main and pull requests6// - Install deps with pnpm, cache node_modules7// - Run: pnpm lint, pnpm typecheck, pnpm test -- --coverage8// - Build: pnpm build9// - Deploy to Vercel on main branch only (use VERCEL_TOKEN secret)10// - Cancel in-progress runs for the same branch11// - Add comments explaining each stepPro tip: Reference @vitest.config.ts or @jest.config.js so Cursor knows the exact test command and can add proper coverage reporting steps.
Expected result: Cursor generates a complete .github/workflows/ci.yml file with all specified stages and proper caching.
Review and refine the generated pipeline
Review and refine the generated pipeline
Open Chat with Cmd+L and ask Cursor to review the generated pipeline for common issues. Reference the generated YAML file. Cursor will identify missing caching, incorrect action versions, redundant steps, and security issues like exposed secrets.
1// Prompt to type in Cursor Chat (Cmd+L):2// @.github/workflows/ci.yml3// Review this GitHub Actions workflow for:4// 1. Outdated action versions (should use latest stable)5// 2. Missing cache configuration6// 3. Security issues (hardcoded secrets, excessive permissions)7// 4. Missing concurrency controls8// 5. Unnecessary steps that slow down the pipeline9// List each issue with the fix.Expected result: Cursor identifies specific issues in the pipeline YAML with line-by-line recommendations.
Generate an Azure DevOps pipeline variant
Generate an Azure DevOps pipeline variant
If your team uses Azure DevOps, use Cmd+K to convert the GitHub Actions workflow to Azure Pipelines syntax. Select the entire YAML file, press Cmd+K, and ask for the conversion. Cursor understands the mapping between platforms.
1// Select the entire .github/workflows/ci.yml content,2// then press Cmd+K and type:3// Convert this GitHub Actions workflow to Azure DevOps4// azure-pipelines.yml format. Use:5// - vmImage: 'ubuntu-latest'6// - task: NodeTool@0 for Node.js setup7// - script steps for pnpm commands8// - stages: Build, Test, Deploy9// - condition: succeeded() for deployment gatePro tip: You can also ask Cursor to generate GitLab CI (.gitlab-ci.yml) using the same conversion approach. Just specify the target platform.
Expected result: The GitHub Actions YAML is converted to valid Azure DevOps pipeline syntax with equivalent stages.
Debug pipeline failures with Cursor
Debug pipeline failures with Cursor
When a pipeline fails, copy the error output from your CI/CD dashboard and paste it into Cursor Chat. Reference the pipeline YAML file and ask Cursor to diagnose and fix the issue. Cursor is particularly effective at fixing YAML syntax errors and missing dependency issues.
1// Prompt to type in Cursor Chat (Cmd+L):2// @.github/workflows/ci.yml3// My CI pipeline failed with this error:4// [paste the full error output from GitHub Actions]5// Diagnose the root cause and provide the exact fix.6// Show me the corrected YAML for the failing step.Pro tip: Use the @web context to have Cursor search for the specific error message online. Type: '@web [error message] GitHub Actions fix' for the latest solutions.
Expected result: Cursor identifies the pipeline failure cause and provides the corrected YAML configuration.
Complete working example
1name: CI/CD Pipeline23on:4 push:5 branches: [main]6 pull_request:7 branches: [main]89concurrency:10 group: ${{ github.workflow }}-${{ github.ref }}11 cancel-in-progress: true1213jobs:14 build-and-test:15 runs-on: ubuntu-latest16 strategy:17 matrix:18 node-version: [20, 22]1920 steps:21 # Checkout repository code22 - uses: actions/checkout@v42324 # Install pnpm package manager25 - uses: pnpm/action-setup@v426 with:27 version: 92829 # Setup Node.js with caching30 - uses: actions/setup-node@v431 with:32 node-version: ${{ matrix.node-version }}33 cache: 'pnpm'3435 # Install dependencies36 - run: pnpm install --frozen-lockfile3738 # Run linting checks39 - run: pnpm lint4041 # Run TypeScript type checking42 - run: pnpm typecheck4344 # Run tests with coverage45 - run: pnpm test -- --coverage4647 # Build the project48 - run: pnpm build4950 # Upload coverage report51 - uses: actions/upload-artifact@v452 if: matrix.node-version == 2253 with:54 name: coverage-report55 path: coverage/5657 deploy:58 needs: build-and-test59 runs-on: ubuntu-latest60 if: github.ref == 'refs/heads/main' && github.event_name == 'push'6162 steps:63 - uses: actions/checkout@v46465 - name: Deploy to Vercel66 uses: amondnet/vercel-action@v2567 with:68 vercel-token: ${{ secrets.VERCEL_TOKEN }}69 vercel-org-id: ${{ secrets.VERCEL_ORG_ID }}70 vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }}71 vercel-args: '--prod'Common mistakes when generating CI/CD Configs with Cursor
Why it's a problem: Not referencing package.json when generating pipeline YAML
How to avoid: Always include @package.json in your pipeline generation prompt so Cursor uses your exact script names and package manager.
Why it's a problem: Hardcoding secret values in generated YAML
How to avoid: Add a .cursorrules entry: 'Never hardcode secrets in YAML — always use ${{ secrets.NAME }} syntax.' Review all generated YAML for hardcoded values before committing.
Why it's a problem: Using outdated GitHub Action versions
How to avoid: Add a rule specifying current action versions: 'Use actions/checkout@v4, actions/setup-node@v4, actions/cache@v4.'
Why it's a problem: Missing cache configuration in generated pipelines
How to avoid: Explicitly request caching in your prompt and verify the cache key includes the lockfile hash.
Best practices
- Reference package.json, Dockerfile, and test config files when generating pipeline YAML
- Create a .cursor/rules/cicd.mdc with auto-attaching globs for workflow files
- Specify exact CI/CD platform and action versions in your rules to prevent outdated syntax
- Use concurrency groups to cancel in-progress runs when new commits push to the same branch
- Add step-level comments in pipeline YAML so future developers understand each stage
- Test pipeline changes in a feature branch before merging to main
- Use Cursor Chat to debug pipeline failures by pasting CI error output directly into the prompt
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
Generate a GitHub Actions CI/CD workflow for a Node.js project using pnpm. Include: dependency caching, linting, type checking, testing with coverage, building, and deploying to Vercel on main branch. Use Node.js 22, cancel in-progress runs, and add comments for each step.
@package.json @Dockerfile @tsconfig.json Generate a complete GitHub Actions workflow at .github/workflows/ci.yml. Install with pnpm, cache dependencies, run lint + typecheck + test with coverage + build. Deploy to Vercel on main branch push only. Use concurrency groups and add step comments. Reference secrets with ${{ secrets.NAME }}.
Frequently asked questions
Can Cursor deploy my application directly?
No. Cursor generates and edits pipeline configuration files but does not execute deployments. The generated YAML runs in your CI/CD platform (GitHub Actions, Azure DevOps, etc.) which handles the actual deployment.
How do I set up CI/CD for a Cursor project?
Open Composer (Cmd+I), reference @package.json and other config files, and prompt Cursor to generate a workflow file for your CI platform. Commit the generated YAML and configure secrets in your CI platform's settings dashboard.
Can Cursor fix a failing pipeline automatically?
Yes, with the MCP GitHub integration, Cursor can push fixes and iterate through build cycles. Without MCP, paste the CI error output into Chat (Cmd+L) with the pipeline YAML referenced, and Cursor will provide the fix to apply manually.
Does Cursor support Azure DevOps pipelines?
Yes. Specify 'Azure DevOps' in your .cursorrules or prompt, and Cursor generates azure-pipelines.yml with proper stages, pools, tasks, and conditions. You can also convert existing GitHub Actions workflows to Azure format.
How do I handle secrets in Cursor-generated pipelines?
Cursor cannot access or create CI secrets. It generates references like ${{ secrets.VERCEL_TOKEN }} in YAML. You must manually configure the actual secret values in your CI platform's settings. Add a rule requiring secrets syntax in .cursorrules.
Can Cursor generate multi-stage Docker builds for CI?
Yes. Reference @Dockerfile and @package.json and ask Cursor to generate a multi-stage Dockerfile with separate build and production stages. Then generate a CI pipeline that builds and pushes the Docker image.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your project.
Book a free consultation