How We Built Deployxa's CI/CD Pipeline: From Push to Production
Deployxa's CI/CD pipeline takes your code from Git push to production in under 90 seconds, with zero downtime (via blue/green deployments) and automatic rollback (via the readiness engine). Building a pipeline that is fast, reliable, and safe is a significant engineering challenge. Here is how we built it, the architecture decisions we made, and the lessons we learned.
The direct answer is that Deployxa's CI/CD pipeline has five stages: trigger (Git push or manual), build (compile the code, with build cache), test (run tests, if configured), deploy (start the new container, run readiness checks, swap traffic), and verify (monitor the new version, roll back if needed). The pipeline is fully automated, which means you push and the platform handles the rest. For more on the deployment process, see our article on Traefik v3 dynamic routing.
The Five Stages
1. Trigger
The pipeline is triggered by a Git push (to the main branch, or a configured branch) or a manual trigger (via the dashboard or CLI). The trigger sends a webhook to the Deployxa engine, which starts the pipeline.
2. Build
The build stage compiles the code: it installs dependencies (from the build cache), runs the build command (e.g., npm run build), and produces the build output. The AutoRepairService stands by to patch missing dependencies. The build cache makes subsequent builds 5-10x faster. For more on the build cache, see our article on the build cache architecture.
3. Test
If the app has tests configured, the test stage runs them. If tests fail, the pipeline aborts, and the deployment does not proceed. If tests pass (or are not configured), the pipeline proceeds to deploy.
4. Deploy
The deploy stage starts the new container (green) alongside the old container (blue). The readiness engine runs the 14-point check on the new container. If the check passes (grade A or B), Traefik swaps traffic from blue to green atomically. If the check fails, the deployment is aborted, and blue continues to serve traffic.
5. Verify
The verify stage monitors the new container for a configurable period (default 5 minutes). If the readiness grade drops below B during the monitoring period, the pipeline automatically rolls back to blue. If the monitoring period passes without issues, the deployment is considered successful, and blue is torn down.
Step-by-Step: How a Deployment Flows
Here is how a typical deployment flows through the pipeline.
Step 1: Git push
You push code to GitHub: git push origin main. GitHub sends a webhook to Deployxa.
Step 2: Build
Deployxa's engine receives the webhook, clones the repository (shallow clone), and runs the build. The build cache makes this fast (5-30 seconds for subsequent builds). The AutoRepairService patches any missing dependencies.
Step 3: Test (if configured)
If the app has tests, the engine runs them. If tests fail, the pipeline aborts.
Step 4: Deploy
The engine starts the new container. The readiness engine runs the 14-point check. If the check passes, Traefik swaps traffic.
Step 5: Verify
The engine monitors the new container for 5 minutes. If the grade drops, the engine rolls back. If the monitoring passes, the deployment is successful.
Step 6: Notify
The dashboard shows the deployment result, and the user is notified via the dashboard (or Slack, if configured).
Common Pitfalls and Troubleshooting
The first pitfall is slow builds. If the build is slow (e.g., 5+ minutes), the pipeline is slow, which delays deployments. The fix is to use the build cache and to optimize the build (e.g., use incremental compilation, parallelize tasks). The second pitfall is flaky tests. If tests fail intermittently, the pipeline aborts unnecessarily, which blocks deployments. The fix is to fix flaky tests or to mark them as non-blocking. The third pitfall is false readiness failures. If the readiness engine produces false failures (e.g., due to a temporary network issue), the pipeline aborts unnecessarily. The fix is to use retries (e.g., check 3 times before failing). The fourth pitfall is not monitoring after deployment. If the pipeline does not monitor after deployment, a slow degradation (e.g., a memory leak) goes undetected. The fix is to have a verify stage that monitors for a period after deployment. The fifth pitfall is not having a rollback. If a deployment causes issues and there is no automatic rollback, users are affected until a human intervenes. The fix is to have automatic rollback (via the readiness engine).
Advanced CI/CD Patterns
Beyond the basics, Deployxa's CI/CD pipeline supports several advanced patterns. The first is parallel deployments. For monorepos with multiple services (e.g., frontend, backend, worker), the pipeline can build and deploy all services in parallel, which reduces the total deployment time. Each service is deployed independently, with its own readiness check and rollback. For more on monorepo deployment, see our article on deploying a FastAPI + Next.js monorepo.
The second pattern is staged rollouts. Instead of swapping all traffic to the new version at once, the pipeline can gradually shift traffic (e.g., 10 percent, 25 percent, 50 percent, 100 percent), monitoring at each stage. If an issue is detected at any stage, the pipeline rolls back automatically. This is useful for high-traffic apps where an abrupt switch might cause issues.
The third pattern is canary deployments. The pipeline can deploy the new version to a small subset of users (e.g., internal employees, beta users) before rolling it out to everyone. This catches issues that only affect certain user segments (e.g., users on a specific browser or device).
The fourth pattern is deployment gates. The pipeline can require approval (e.g., from a manager) before proceeding to production. This is useful for apps where deployments need human oversight (e.g., financial apps, healthcare apps). The approval gate can be integrated with Slack (e.g., a Slack button to approve or reject).
The fifth pattern is deployment notifications. The pipeline can send notifications (via Slack, email, or webhook) at each stage of the deployment (build started, build succeeded, deploy started, deploy succeeded, rollback triggered). This keeps the team informed about the deployment's progress.
How the Pipeline Integrates with the MCP Server
The CI/CD pipeline is exposed via the Deployxa MCP server, which means your AI assistant (in Cursor or Claude Desktop) can trigger and monitor deployments directly. For example, you can say "deploy the current project and check if it's healthy," and your AI assistant calls deployxa_deploy_workflow, waits for the build, calls deployxa_get_readiness, and reports the result. If the deployment fails, the assistant can call deployxa_get_build_log to diagnose the issue and propose a fix. This is the agentic deployment workflow, where the AI assistant handles the entire deployment process without you leaving your editor. For more on the MCP server, see our article on giving Cursor cloud superpowers. For more on agentic deployment, see our article on the agentic blue/green deployment pipeline.
Lessons Learned
Building the CI/CD pipeline taught us several lessons. First, speed matters. A fast pipeline (under 90 seconds) enables rapid iteration, which is essential for the vibe coder workflow. Every second saved in the pipeline translates to more iterations per day. Second, reliability matters more than speed. A fast pipeline that occasionally fails is worse than a slow pipeline that always succeeds, because failures break trust and cause developers to avoid deploying. Third, automatic rollback is essential. Without automatic rollback, a bad deployment stays live until a human intervenes, which means users are affected. With automatic rollback, bad deployments are detected and reverted in seconds. Fourth, the readiness engine is the safety net. The 14-point readiness engine catches issues that the build process cannot (e.g., runtime errors, database connectivity issues, slow responses). Without the readiness engine, deployments would be much riskier. Fifth, the build cache is the speed multiplier. Without the build cache, every build would take minutes, which would make the pipeline too slow for rapid iteration. The build cache makes subsequent builds 5-10x faster, which is the difference between a 90-second pipeline and a 5-minute pipeline. For more on the build cache, see our article on the build cache architecture.
Conclusion: A Fast, Reliable, Safe Pipeline
Deployxa's CI/CD pipeline takes your code from Git push to production in under 90 seconds, with zero downtime and automatic rollback. The five stages (trigger, build, test, deploy, verify) work together to ensure that your deployments are fast, reliable, and safe. For more on Deployxa's engineering, see our articles on the build cache architecture and the container image registry. Learn about how we handle DDoS protection and the Git integration system in our companion articles. Explore our free developer tools. Try Deployxa Drop for an instant live preview.