DevOps snippet pack: CI/CD for micro-apps with free CI, canary deploys and rollbacks

Hook: stop paying for CI/CD experiments — deploy micro-apps safely on free tiers

If you’re building micro-apps or side projects in 2026, the biggest drain is not the code — it’s recurring platform bills and the time you waste reconfiguring pipelines. This snippet pack gives you pragmatic, production-minded CI/CD patterns you can run on free CI and hosting tiers: fast GitHub Actions pipelines, safe canary deployments using Cloudflare Workers, and automated rollback recipes so one bad release doesn’t break users.

Why this matters in 2026

Micro-apps have matured from prototypes to mission-critical tooling for teams and individuals. Two trends changed the game in late 2025–early 2026:

• Edge-first deployments and API-driven platform controls. Providers expose fine-grained APIs and edge worker runtimes, making low-cost traffic steering and promotion feasible without a load balancer.
• AI-assisted, faster development cycles. Developers are shipping more micro-apps faster, increasing the need for robust, inexpensive CI/CD that supports safe rollouts at scale.

That combination makes lightweight CI/CD — driven by GitHub Actions and augmented with Cloudflare Workers and provider CLIs/APIs — the sweet spot for micro-apps in 2026.

What you’ll get from this pack

• Reusable GitHub Actions snippets for build/test, preview deploys, and promotions
• Canary deployment pattern using a Cloudflare Worker for weighted traffic routing
• Safe rollback strategies (automatic and manual) with example workflows
• Operational tips for staying within free-tier limits and when to upgrade

Quick landscape (what’s still reliably free in early 2026)

Always check provider docs for the latest quotas, but as of early 2026 the most practical free options for micro-app CI/CD are:

• GitHub Actions — free minutes/runner for public repos and modest private usage; excellent for orchestrating pipelines.
• Cloudflare Workers & Pages — very generous free tiers for edge routing and static/SSR hosting, plus easy API access to update KV values used for routing.
• Vercel & Netlify (Hobby) — free preview deployments, simple promotion APIs or CLIs for production-alias updates (limits apply). For teams doing hybrid production and preview workflows, see the Hybrid Micro-Studio Playbook.
• Deta, Supabase (free tiers), and GitHub Pages — useful for tiny microservices and storage.

Principle: use GitHub Actions as the universal orchestrator, an edge worker (Cloudflare) for lightweight traffic control, and provider CLIs/APIs for promotion/aliasing.

Core pipeline: CI, preview deploy, smoke tests

Start with a concise, cost-aware workflow. Run fast unit tests, cache dependencies, build artifacts, and deploy a preview. Below is a GitHub Actions workflow template you can adapt for Node, Python, or static apps. It favors incremental steps and uses artifacts to persist build outputs.

# .github/workflows/ci-preview.yml
name: CI / Preview
on:
  push:
    branches: [ 'main', 'develop' ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install & Cache
        run: |
          npm ci
        # optional: use actions/cache for node_modules between runs

      - name: Run tests
        run: npm test --silent

      - name: Build
        run: npm run build

      - name: Upload artifact
        uses: actions/upload-artifact@v4
        with:
          name: build-artifact
          path: ./build

  preview-deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Download build
        uses: actions/download-artifact@v4
        with:
          name: build-artifact

      - name: Deploy preview (example: Vercel/Netlify/Cloudflare)
        env:
          PROVIDER_TOKEN: ${{ secrets.PROVIDER_TOKEN }}
        run: |
          # Replace this with your provider's CLI or API call
          # Example (Vercel): npx vercel --token "$PROVIDER_TOKEN" --prod --confirm
          ./scripts/deploy-preview.sh "$PROVIDER_TOKEN"

      - name: Run smoke tests against preview
        run: ./scripts/smoke-test.sh "${{ steps.deploy.outputs.preview_url }}"

Practical notes

• Keep tests small and focused to conserve CI minutes.
• Use artifacts to avoid rebuilding heavy assets during promotion steps.
• Use branch-based preview URLs to get isolated deployments without touching production.

Canary deploy pattern using a Cloudflare Worker

When you can’t influence upstream load balancers or the hosting provider doesn’t support traffic-splitting, use an edge worker as a transparent routing layer. This pattern is perfect for micro-apps because Cloudflare Workers have a generous free tier and low latency.

How it works

1. Deploy a new version as a preview (canary) — keep it reachable at a preview URL.
2. Cloudflare Worker inspects each request and, based on a stored percentage, forwards a subset to the canary origin.
3. Worker can be updated (via KV or a small API) to increase the percentage in controlled steps.
4. If health checks fail, change the KV value to 0% or route all traffic back to production.

Cloudflare Worker (simple weighted router)

// worker.js
addEventListener('fetch', event => {
  event.respondWith(handle(event.request))
})

async function handle(request) {
  // Read the canary percentage from KV (string -> number)
  const pctRaw = await CANARY_KV.get('CANARY_PCT')
  const pct = pctRaw ? Number(pctRaw) : 0

  // Cookie override to force canary for QA
  const cookie = request.headers.get('cookie') || ''
  if (cookie.includes('force_canary=1')) {
    return fetchCanary(request)
  }

  // Random sampling
  if (Math.random() * 100 < pct) {
    return fetchCanary(request)
  }

  return fetchProd(request)
}

function fetchCanary(req) {
  const url = new URL(req.url)
  url.hostname = CANARY_HOST  // e.g. preview.yoursite.vercel.app
  return fetch(url.toString(), req)
}

function fetchProd(req) {
  const url = new URL(req.url)
  url.hostname = PROD_HOST    // e.g. app.example.com
  return fetch(url.toString(), req)
}

Deploy notes: bind a KV namespace called CANARY_KV and set CANARY_HOST / PROD_HOST as worker constants or environment variables. This keeps the worker fast and simple. For more on when to push logic to the edge versus keeping inference or state in the cloud, read edge-oriented cost optimisation.

Updating the canary percentage from GitHub Actions

# .github/workflows/canary.yml (job fragment)
- name: Set canary pct to 5
  run: |
    curl -X PUT "https://api.cloudflare.com/client/v4/accounts/$CF_ACCOUNT_ID/storage/kv/namespaces/$KV_ID/values/CANARY_PCT" \
      -H "Authorization: Bearer ${{ secrets.CF_API_TOKEN }}" \
      -H "Content-Type: text/plain" \
      --data "5"

This updates the KV key the worker reads. Incrementally increase to 25, 50, then 100 while running smoke tests between steps. The worker’s logic controls routing without needing provider-level traffic split features.

Promotion and rollback: store state and automate safely

The two most important guarantees for safe deploys are: 1) you can identify the previous production version and 2) you can revert to it quickly, reliably, and automatically.

# 1. Save previous ID
PREV_ID=$(curl -H "Authorization: Bearer $PROVIDER_TOKEN" "https://api.provider.example.com/alias/production" | jq -r .deployment_id)
printf '{"previous":"%s"}' "$PREV_ID" > prev.json
# upload prev.json as artifact or to KV

# 2. Promote new deploy
NEW_ID=$(curl -X POST -H "Authorization: Bearer $PROVIDER_TOKEN" \ 
  -d '{"deploy_id":"'$DEPLOY_ID'","alias":"production"}' https://api.provider.example.com/promote | jq -r .id)

# 3. Run health checks
./scripts/smoke-test.sh "https://app.example.com" || {
  # 4. If health check fails, rollback
  curl -X POST -H "Authorization: Bearer $PROVIDER_TOKEN" -d '{"deploy_id":"'$PREV_ID'","alias":"production"}' https://api.provider.example.com/promote
  exit 1
}