Option to set rotation or retention rules for preview deploys

[Yuripetusko]

We would really love to use preview deploys feature but the tiny limit of 5 (hobby) preview deploys is just doesn't make it feasable. We already pay for trigger dev cloud, but don't really want to pay extra cost for something that in theory can be managed otherwise if there was an easy option to do so.

The proposal is to allow users allos users to have an easy way to rotate preview deploys to stay within the limit. Either with LRU-like eviction policy or simply with enforced hard limit option where new deploys would fail once the limit is reached.

We create a lot of PRs, and some of them stay for a while as drafts due to some blockers or other reasons, currently we have a single staging environment which we rarely use now as the process of deploying is clunky and there's always "fear" that someone else will deploy there overwriting your deploy creating a lot of confusion. While we can probably spend some time and figure out some place to store and manage configurable list of branches that the CI could read to see if deploy is needed for this branch, but with vercel integration this seems even harder. Unless i'm missing something and there's an easy/DX-friendly path, the preview branch feature is currently useless unless you are ready to overpay by forgetting to delete the old ones

[unusdon]

There isn't built-in rotation today — the hobby cap is a hard ceiling, not an LRU eviction. You can build the eviction yourself with the CLI + a small GitHub Action, and it takes about 20 lines of workflow YAML.

The mechanic

Every preview deploy in Trigger.dev has a branch slug attached to it (matching your PR branch name). You can list and delete previews with the CLI:

# list previews
npx trigger.dev@latest deploy list --env preview --project $TRIGGER_PROJECT

# delete a specific preview
npx trigger.dev@latest deploy delete --env preview --branch feature/foo --project $TRIGGER_PROJECT

So the eviction pattern is: when a PR is closed (merged or closed unmerged), delete the preview deploy attached to it. That naturally keeps the count under the cap without any LRU accounting — you're bounded by open PRs, not by time.

GitHub Action that auto-evicts on PR close

Save as .github/workflows/trigger-preview-cleanup.yml:

name: Cleanup Trigger.dev preview

on:
  pull_request:
    types: [closed]

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

      - uses: actions/setup-node@v4
        with:
          node-version: '22'

      - name: Delete preview deploy
        env:
          TRIGGER_ACCESS_TOKEN: ${{ secrets.TRIGGER_ACCESS_TOKEN }}
          TRIGGER_PROJECT: ${{ vars.TRIGGER_PROJECT_REF }}
        run: |
          npx trigger.dev@latest deploy delete \
            --env preview \
            --branch "${{ github.head_ref }}" \
            --project "$TRIGGER_PROJECT" \
            --skip-warnings || echo "no preview for branch, skipping"

|| echo is there because deleting a preview that doesn't exist errors out; on the first run after enabling this workflow, some PRs won't have matching previews and you don't want the job to fail.

Time-based LRU fallback

If you want actual LRU eviction (say, "keep only the 5 most recent regardless of PR state" because you're doing lots of hotfix branches), run this on a cron:

on:
  schedule:
    - cron: '0 3 * * *'   # nightly at 03:00 UTC

jobs:
  lru-evict:
    runs-on: ubuntu-latest
    steps:
      - name: Keep only 5 newest previews
        env:
          TRIGGER_ACCESS_TOKEN: ${{ secrets.TRIGGER_ACCESS_TOKEN }}
          TRIGGER_PROJECT: ${{ vars.TRIGGER_PROJECT_REF }}
        run: |
          npx trigger.dev@latest deploy list --env preview --project "$TRIGGER_PROJECT" --json \
            | jq -r 'sort_by(.createdAt) | reverse | .[5:] | .[].branch' \
            | while read branch; do
                npx trigger.dev@latest deploy delete --env preview --branch "$branch" --project "$TRIGGER_PROJECT" --skip-warnings
              done

That keeps the 5 newest and evicts the rest each night.

Feature request angle

An in-product "preview retention policy" ({ maxPreviews: 5, evictionStrategy: 'lru' }) would be the right long-term shape — it belongs on the project settings alongside the concurrency/queue caps. Worth opening as a formal feature request; the CLI plumbing above proves the primitives exist, so the UI/config layer is the missing piece.

[Yuripetusko]

Yep thanks, we did implement a similar approach, but yeah I was specifically talking about in-product setting for this