How We Built Deployxa's CI/CD Pipeline: From Push to Production
Key Facts
Direct answer: 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 Five Stages: 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).
Step-by-Step: How a Deployment Flows: Here is how a typical deployment flows through the pipeline.
Advanced CI/CD Patterns: Beyond the basics, Deployxa's CI/CD pipeline supports several advanced patterns.
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.
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.
Scaling and Long-Term Considerations
As your project grows beyond the initial deployment, several long-term considerations become important. The first is scalability planning. What works for 100 users might not work for 1000 or 10000 users. Plan ahead by understanding your bottlenecks: is it the database (add indexes, use read replicas), the app server (add containers, use auto-scaling), or the network (use a CDN, optimize assets)? Monitor your resource usage trends and scale proactively before you hit limits, not reactively after an outage. For more on scaling, see our article on how to scale your SaaS from MVP to first customers.
The second consideration is maintainability. As your codebase grows, technical debt accumulates. Regular refactoring, dependency updates, and code reviews keep the codebase healthy. Schedule time for maintenance (e.g., one day per month) and treat it as a feature, not an afterthought. For more on maintenance, see our article on the SaaS founder's guide to dependency management.
The third consideration is team growth. What happens when you hire your first engineer? Is the codebase understandable? Is the deployment process documented? Are the environment variables inventoried? A well-documented, well-structured project makes onboarding faster and reduces the risk of mistakes. For more on team handoff, see our article on how to build a deployment process your future team can inherit.
The fourth consideration is cost evolution. As you scale, costs increase. Without monitoring, costs can exceed revenue. Track your cost-per-user metric (total hosting cost / number of active users) and ensure it stays below your revenue-per-user. For more on cost management, see our article on the SaaS founder's guide to cost optimization.
The fifth consideration is disaster recovery. As you grow, the impact of data loss or downtime increases. Regularly test your backup restore, your rollback procedure, and your incident response plan. An untested plan is not a plan. For more on disaster recovery, see our article on the SaaS founder's guide to disaster recovery planning.
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.