CI/CD Pipeline Best Practices for Solo Developers and Small Teams: A Practical GitHub Actions Guide

If you are deploying by SSH-ing to a server and running git pull, you are one keystroke away from breaking production at 2am. This guide presents a pipeline for one-developer side projects and small SaaS teams.

Why CI/CD matters even for solo developers

The objection I hear most often is "I'm only one developer, I don't need a pipeline." Team size is not the deciding factor; repeatability and deployment risk are:

• List each manual step: pull, build, restart, smoke-test, and rollback preparation.
• Automate checks that should run the same way on every change.
• Measure workflow duration and maintenance cost in your own repository.
• Keep manual approval where the release risk justifies it.

Beyond time, a pipeline gives you three things you cannot get from manual deploys: tests on every change, atomic deploys (the new version replaces the old in one operation), and a known-good rollback path.

The five-stage architecture

The reference workflow.yml

This is the file I put in .github/workflows/deploy.yml for a Node.js + Docker app. Adapt for your stack.

name: Deploy

on:
  push:
    branches: [main]
  workflow_dispatch:

concurrency:
  group: deploy-${{ github.ref }}
  cancel-in-progress: false

jobs:
  lint-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm run typecheck
      - run: npm test -- --ci --coverage

  build-and-push:
    needs: lint-and-test
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v4
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/setup-buildx-action@v3
      - uses: docker/build-push-action@v5
        with:
          push: true
          tags: |
            ghcr.io/${{ github.repository }}:${{ github.sha }}
            ghcr.io/${{ github.repository }}:latest
          cache-from: type=gha
          cache-to: type=gha,mode=max

  deploy:
    needs: build-and-push
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://app.example.com
    steps:
      - uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.PROD_HOST }}
          username: deploy
          key: ${{ secrets.PROD_SSH_KEY }}
          script: |
            cd /srv/app
            docker compose pull
            docker compose up -d --remove-orphans
            # Wait for health-check
            for i in {1..30}; do
              if curl -fs http://localhost:3000/health > /dev/null; then
                echo "Healthy after ${i}s"
                exit 0
              fi
              sleep 1
            done
            echo "Health-check failed - rolling back"
            docker compose down
            docker tag ghcr.io/${{ github.repository }}:previous \
                       ghcr.io/${{ github.repository }}:latest
            docker compose up -d
            exit 1

Three things to notice:

• Jobs run sequentially with needs: - no point building if tests fail.
• The concurrency group prevents two deploys from racing if you push twice in quick succession.
• The deploy step has its own health check and rollback logic - never trust that "deploy succeeded" means "service is healthy".

Secret management done right

Secrets are where most teams quietly break their security posture. These are the rules I recommend:

1. Never commit secrets. Use .gitignore for .env files. Use gitleaks as a pre-commit hook to catch accidents.
2. Store secrets in repo or org settings. Reference as ${{ secrets.NAME }}. GitHub documents how Actions secrets are configured and redacted; still avoid printing sensitive values.
3. Use environments for production secrets. The environment: production block in the deploy job lets you require manual approval and restricts which branches can use those secrets.
4. Never echo a secret. Even masked, the lack of output is suspicious - design your scripts to not need to.
5. Rotate quarterly. Set a calendar reminder. Bonus: connect to a secrets manager (Doppler, AWS Secrets Manager) via OIDC for fully ephemeral credentials.

Testing strategy: what to run in CI

Good CI runs the checks that match the risk and gives feedback soon enough to be useful. Establish targets from your repository's baseline rather than borrowing a universal duration.

Deployment strategies, ranked

From simplest to most sophisticated. Pick the simplest one your traffic allows.

1. Managed platform (Vercel, Netlify, Fly.io, Render)

For 80% of projects this is the right answer. Push to main, the platform handles atomic deploys, instant rollback, preview environments per PR. Your GitHub Actions workflow only needs to run tests - the platform's own integration handles deploy.

2. Rolling deploy via Docker Compose on a VPS

One Docker Compose file behind a reverse proxy (Caddy or Traefik). The workflow above shows the pattern. docker compose pull && docker compose up -d swaps the container atomically.

3. Blue/green with two environments

Two parallel environments (blue and green) behind a load balancer. Deploy to the inactive one, health-check, then flip the load-balancer target. Instant rollback by flipping back.

4. Kubernetes rolling deployment

Only if you genuinely need Kubernetes (rare - see my Docker vs Kubernetes guide). Kubernetes does rolling deploys natively with kubectl rollout.

The 3-layer rollback strategy

Three rollback mechanisms, used in priority order when something goes wrong:

1. Automatic on health-check fail (the script above): the deploy script itself reverts to the previous image when the health-check fails. Fastest recovery; no human required.
2. One-command manual rollback: a ./scripts/rollback.sh in the repo that redeploys the previous git tag. Used when the issue surfaces after the deploy reported success.
3. Git revert + redeploy: git revert HEAD && git push. The pipeline rebuilds and deploys the reverted state. Slowest but always works.

Observability minimums on day one

• Health endpoint at /health that returns 200 only if the app + DB + critical dependencies are reachable.
• Structured logs shipped to a central destination (Loki, Datadog, Logtail).
• Uptime monitor (UptimeRobot, BetterStack) pinging /health every minute with Slack alerts on failure.
• Deploy notifications in Slack - the workflow posts on every deploy with sha, author, and status.
• Error tracking (Sentry) wired in with the deploy sha for release tracking.

Common CI/CD mistakes (and what to do instead)

• Running E2E tests on every commit → run lint+unit only, push E2E to nightly + staging.
• No concurrency control → two deploys race, the slower one overwrites the faster one with stale code.
• Trusting "deploy succeeded" without a health-check → silent breakage in production.
• No deploy notifications → failures can go unnoticed until someone checks the environment.
• Using latest tag only → impossible to roll back. Always tag with the git sha too.
• Storing secrets in env files in the repo → one compromised laptop, total credential leak.

Conclusion: ship the pipeline, then ship features

Set up the smallest useful pipeline early, then add stages as the project gains tests, deployment risk, and operational requirements. The shape above - staged checks, rollback layers, real health checks, and secret hygiene - is a reliable starting point, not a fixed recipe.

Related guides

DevOps

Docker vs Kubernetes: When to Use Each, and When Kubernetes Is Total Overkill

10 minFeb 2026

Full Stack Dev

Next.js Best Practices in 2026: Scalable SaaS Architecture

12 minMay 2026

AI Automation

AI Workflow Automation for Businesses

18 minJun 2026