CI / CD for vibcoding: deploy without downtime and rollback in 1 minute

You can generate AI code every hour, but without CI/CD, any release becomes a lottery. As long as the calculation is done with your hands, you always have a risk: you forgot migration, did not check your health, wiped .env, got a downtime.

Below is a working scheme that is suitable for your website format: fast, without overcomplicating and with real quality control.

## The short answer

CI/CD is even needed by a solo developer if the project is already on sale and has users. Minimum for adult release:

1. Auto-assembly and auto-testing for each push.
2. Deployment in an inactive environment (blue/green or analogue).
3. Mandatory health check before switching traffic.
4. Explicit rollback script (one command).

If these four items are not available, a “downtime release” is not actually guaranteed.

## Where CI/CD works best

• When updates are issued more than 1 time per week.
• When there is authorization, payments, webhooks, integration.
• When the project is supported through AI assistants, it is easy to allow regression.
• When you need a predictable rollback without overnight crashes.

## Minimum release architecture

For most projects on Node/Python/Go, it is enough:

• GitHub Actions as an orchestration layer.
• Docker image as a single artifact.
• Two runtime environments (blue and green).
• Reverse proxy (Nginx/Traefik) to switch traffic.
• Check /health before switch.

## Ready-made prompt for AI (copy)

You're senior DevOps.
You need a production-ready CI/CD pipeline for a web application.

The context:
- stack: [point stack]
- Deploy: Docker on VPS
- strategy: blue-green
Goal: zero-downtime + rollback for 1 team

Do it.
(1) .github/workflows/deploy.yml
(2) Dockerfile (multi-stage, non-root)
3) docker-compose.prod.yml with blue/green services
(4) switch.sh and rollback. sh
5) health-check scenario before switching
(6) short launch instructions

Requirements:
Do not keep secrets in the repository
- Fail-fast on the tests.
Disabling the deploitation when falling health-check
Logging steps without leaking tokens

## Workflow (a database that can be adapted)

name: Deploy Production

on:
  push:
    branches: ["main"]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Build image
        run: docker build -t registry.example.com/app:${{ github.sha }} .

      - name: Push image
        run: docker push registry.example.com/app:${{ github.sha }}

      - name: Deploy to inactive slot
        run: ssh ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }} "cd /opt/app && ./deploy-to-inactive.sh ${{ github.sha }}"

      - name: Health check
        run: ssh ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }} "cd /opt/app && ./health-check.sh"

      - name: Switch traffic
        run: ssh ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }} "cd /opt/app && ./switch.sh"

## Anti-patterns that kill releases

• Deploy directly to a single instance without an interim check.
• The absence of a rollback command (rollback by hand = long and risky).
• Check only "container up," with no real HTTP health check.
• Secrets in .env inside the repository.
• DB migrations that are incompatible with the previous version of the application.

## Checklist before sale

1. There are separate secrets for staging and production.
2. Docker image is collected repeatable (multi-stage, pinned base image).
3. /health checks not only the process, but also access to the database / cache.
4. Rollback has been tested at least once.
5. After the release, 4 DORA metrics are tracked.

## What to read next

• Docker для новичка: полный гайд по запуску, образам и контейнерамXX
• Чистая архитектура: как не превратить проект в спагеттиXX
• Подключение домена к Cloudflare: рабочая схема без ошибокXX
• Почему «оно работает» не равно качеству: проверка кода от ИИXX