Code deploy is the process of shipping new code to production. The right answer is a managed CI/CD pipeline (GitHub Actions, GitLab CI) + a managed deploy platform (Render, Fly, Railway, Kubernetes). The wrong answer is manual git push to a production box, FTP-upload to a web server, or a custom shell script. The mistake every team makes: the team builds a custom deploy script, the team has 4 different deploy paths, the team cannot reproduce the deploy that worked last week.
Table of contents
- The deployment strategy — blue-green, canary, rolling
- The CI/CD pipeline — the right answer for a small team
- The deploy platform — the right answer for a small/medium team
- The Kubernetes deploy — the right answer for a large team
- The rollback — the right answer for a failed deploy
- The health check — the right answer for a working deploy
- The one mistake that loses the team’s weekend
- How this fits the rest of the stack
- FAQ
The deployment strategy — blue-green, canary, rolling
The deployment strategy is how the new code replaces the old code. The right answer is blue-green (the new code runs in parallel, the traffic switches atomically) for a low-risk deploy, the right answer is canary (the new code runs for 1-5% of the traffic, the team watches the metrics, the team rolls forward) for a high-risk deploy, the right answer is rolling (the new code replaces the old one instance at a time) for a steady-state deploy.
The wrong answer is the ‘recreate’ strategy (the old code is killed, the new code is started) for a production deploy — the team has downtime. The right answer for a dev environment is the recreate strategy, the right answer for a production deploy is blue-green or canary.
The CI/CD pipeline — the right answer for a small team
The right answer for a small team is a managed CI/CD pipeline. GitHub Actions for a team on GitHub, GitLab CI for a team on GitLab, CircleCI for a team that wants the on-prem option. The team writes a YAML file, the team commits, the pipeline runs, the deploy happens. The right answer is the managed pipeline for a team that does not want to operate Jenkins.
The deploy platform — the right answer for a small/medium team
The right answer for a small/medium team is a managed deploy platform. Render, Fly, Railway, Render, Vercel (for the frontend), Heroku (for the legacy). The team connects the git repo, the team clicks ‘deploy’, the platform builds, the platform deploys, the platform handles the rollback. The right answer is the managed platform for a team that does not want to operate a Kubernetes cluster.
The Kubernetes deploy — the right answer for a large team
The right answer for a large team is Kubernetes (or a Kubernetes-managed service like EKS, GKE, AKS). The team writes manifests (or Helm charts), the team applies them with kubectl apply, the team has full control over the deploy strategy (blue-green, canary, rolling), the team has full control over the rollback. The right answer is Kubernetes for a team with a dedicated platform engineer.
The gotcha: the team that has a small team (1-3 engineers) and Kubernetes is paying for the complexity. The right answer is a managed platform (Render, Fly), the right answer for a team that needs Kubernetes is a managed Kubernetes (EKS, GKE, AKS) with a tool like ArgoCD for the GitOps workflow.
The rollback — the right answer for a failed deploy
The rollback is the right answer for a failed deploy. The right answer is a managed platform’s built-in rollback (Render: ‘rollback to previous deploy’, Kubernetes: kubectl rollout undo). The right answer is to test the rollback in dev, the right answer is to document the rollback in the runbook.
The wrong answer is a custom rollback script — the team has 4 different rollback paths, the team cannot reproduce the rollback that worked last week. The right answer is the platform’s built-in rollback.
The health check — the right answer for a working deploy
The health check is the right answer for a working deploy. The platform’s deploy waits for the health check to pass, the team is notified if the health check fails, the team can roll back automatically. The right answer for a health check is a simple GET /health that returns 200 when the app is ready, the right answer is to check the database connection and the external dependencies in the health check.
The wrong answer is to use the home page as the health check — the home page is a marketing page, the marketing page is not the right answer for ‘the app is ready’. The right answer is a dedicated /health endpoint.
The one mistake that loses the team’s weekend
The mistake: the team has a manual deploy process, the team member on-call is paged at 2am, the team member has to remember the deploy steps, the team member makes a mistake, the production is down for an hour. The right answer is to automate the deploy, the right answer is to have a runbook for the on-call, the right answer is to have a rollback that is one click.
How this fits the rest of the stack
The infrastructure question is a small piece of a larger pattern: the team’s runtime, storage, database, secret store, logs, and deployment platform are all parts of the same platform. The right answer is to model the full stack before the project ships, not after. The RunxBuild hosting calculator is the right place to do that exercise — pick the runtime, the memory tier, the storage, the secret store, and the egress, and the calculator shows what the deploy actually costs at the team’s actual usage.
Useful related references:
FAQ
What is the best way to deploy code in 2026?
A managed CI/CD pipeline (GitHub Actions, GitLab CI) + a managed deploy platform (Render, Fly, Railway, Kubernetes). The wrong answer is manual git push to a production box.
What is the difference between blue-green and canary deploy?
Blue-green runs the new code in parallel and switches the traffic atomically. Canary runs the new code for a small percentage of the traffic and rolls forward based on the metrics.
What is the best CI/CD tool for a small team?
GitHub Actions for a team on GitHub, GitLab CI for a team on GitLab, CircleCI for a team that wants the on-prem option. The wrong answer is Jenkins for a small team.
How do I roll back a deploy?
For a managed platform: the platform’s ‘rollback’ button. For Kubernetes: kubectl rollout undo deployment/<name>. The right answer is to test the rollback in dev.
What is a health check in a deploy?
A simple endpoint that returns 200 when the app is ready. The platform’s deploy waits for the health check to pass. The right answer is a dedicated /health endpoint, not the home page.
How do I set up automatic deploys?
Connect the git repo to the managed platform, the platform deploys on every push to the main branch. The right answer is to test the deploy in a staging environment first.
Should I use Kubernetes for a small team?
For a team with 1-3 engineers, no — the right answer is a managed platform (Render, Fly). For a team that needs Kubernetes, the right answer is a managed Kubernetes (EKS, GKE, AKS).
How do I deploy to a custom server?
Use a CI/CD pipeline that runs the build, uploads the artifact, and runs the deploy on the custom server. The right answer is to automate the deploy, the wrong answer is manual.