GitHub Actions: Tag-Based Releases

Deploy only when you explicitly tag a release. This gives you complete control over what reaches production—no accidental deployments from work in progress.

.github/workflows/tag-deploy.yaml
name: Tag-Based Deploy

on:
  push:
    tags:
      - "v*"

jobs:
  deploy:
    runs-on: ubuntu-latest
    env:
      ZUPLO_API_KEY: ${{ secrets.ZUPLO_API_KEY }}

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 24

      - name: Install dependencies
        run: npm install

      - name: Deploy with tag as environment name
        run: |
          # Extract tag name (e.g., v1.2.3 -> v1.2.3)
          TAG_NAME="${GITHUB_REF#refs/tags/}"

          npx zuplo deploy \
            --api-key "$ZUPLO_API_KEY" \
            --environment "$TAG_NAME"

This workflow:

1. Triggers only when you push a tag matching v* (like v1.0.0, v2.1.3)
2. Creates an environment named after the tag
3. Deploys your API to that environment

Creating a Release

Code
# Tag the current commit
git tag v1.0.0

# Push the tag to trigger deployment
git push origin v1.0.0

Deploying to Production

If you want tags to update your production environment instead of creating new environments:

Code
- name: Deploy to production
  run: |
    npx zuplo deploy \
      --api-key "$ZUPLO_API_KEY" \
      --environment main  # or your production environment name

With GitHub Releases

Combine with GitHub Releases for a complete release workflow:

Code
on:
  release:
    types: [published]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      # ... setup steps ...

      - name: Deploy release
        run: |
          npx zuplo deploy \
            --api-key "$ZUPLO_API_KEY" \
            --environment "${{ github.event.release.tag_name }}"

Next Steps

• Add multi-stage deployment with staging validation
• Set up automatic cleanup for old environments