# Cache Warming as the Last Step of Your Deploy Pipeline — CacheBoost Blog

> Every deployment flushes your cache. Making cache warming the final step of your CI/CD pipeline ensures your site is never cold after a deploy.

Source: https://www.cache-boost.com/blog/continuous-deployment-cache-warming.md
Language: en

---


Tags: use-case, tutorial, devops, performance
Published: 2026-07-28
Author: Nicolas Hodin
Reading time: 3 min

---

**In summary:**
- Every deploy flushes your cache and leaves the site cold
- Make cache warming the final step of your CI/CD pipeline
- Shows how to trigger a warm-up and wait for it to complete
- Covers multiple environments and combining with scheduled warming
The most reliable fix for post-deploy slowness is to make cache warming the final stage of your CI/CD pipeline: one API call after the deploy step, and the cache is rebuilt before real traffic notices anything happened. This guide shows copy-paste examples for GitHub Actions and GitLab CI, plus how to handle multiple environments.

## The deploy → cold cache problem

Every code deployment that clears the cache creates a window where your site is slow. The window might be 30 seconds or 5 minutes depending on your catalog size, but during that window your first real visitors (often the most excited ones, right after you've shipped something new) get a degraded experience.

Making cache warming the last step of your deployment pipeline closes that window. By the time the deployment finishes, the cache is already rebuilt.

## Triggering a warm-up from CI/CD

CacheBoost exposes a simple REST API endpoint to trigger a boost run:

```
POST https://api.cache-boost.com/v1/boosts/{boost_id}/run
Authorization: Bearer cb_live_...
```

That's a single HTTP request. It fits into any CI/CD system: GitHub Actions, GitLab CI, CircleCI, Bitbucket Pipelines, a Makefile, a shell script.

### GitHub Actions example

```yaml
name: Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to production
        run: ./deploy.sh

      - name: Warm cache
        run: |
          curl -s -o /dev/null -w "%{http_code}" \
            -X POST https://api.cache-boost.com/v1/boosts/${{ secrets.CACHEBOOST_BOOST_ID }}/run \
            -H "Authorization: Bearer ${{ secrets.CACHEBOOST_API_KEY }}" \
            -H "Content-Type: application/json"
```

Store `CACHEBOOST_API_KEY` and `CACHEBOOST_BOOST_ID` as repository secrets. The warm-up call is fire-and-forget: it queues the run and returns immediately, so it doesn't block your pipeline.

### GitLab CI example

```yaml
stages:
  - deploy
  - warm_cache

deploy:
  stage: deploy
  script:
    - ./deploy.sh

warm_cache:
  stage: warm_cache
  script:
    - |
      curl -s -X POST https://api.cache-boost.com/v1/boosts/$CACHEBOOST_BOOST_ID/run \
        -H "Authorization: Bearer $CACHEBOOST_API_KEY"
  needs: [deploy]
```

## Waiting for the warm-up to complete

The trigger endpoint returns immediately. If you want to wait for the run to finish before marking the deployment as successful, you can poll the run status:

```bash
# Trigger the run and capture the run ID
RESPONSE=$(curl -s -X POST https://api.cache-boost.com/v1/boosts/$BOOST_ID/run \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json")
RUN_ID=$(echo $RESPONSE | jq -r '.data.id')

# Poll until complete
while true; do
  STATUS=$(curl -s https://api.cache-boost.com/v1/runs/$RUN_ID \
    -H "Authorization: Bearer $API_KEY" | jq -r '.data.status')
  echo "Run status: $STATUS"
  [ "$STATUS" = "completed" ] || [ "$STATUS" = "failed" ] && break
  sleep 10
done
```

For most pipelines, fire-and-forget is fine. The warming runs in parallel with any post-deploy checks you have.

## Multiple environments

If you have staging and production environments, create one boost per environment:

- **Staging boost**: covers your staging domain, lower priority user-agents, single region
- **Production boost**: covers your production domain, all user-agents, all regions

In your CI/CD config, select the right boost ID based on the branch or environment variable:

```yaml
- name: Warm cache
  run: |
    BOOST_ID=$([[ "$BRANCH" == "main" ]] && echo "$PROD_BOOST_ID" || echo "$STAGING_BOOST_ID")
    curl -s -X POST https://api.cache-boost.com/v1/boosts/$BOOST_ID/run \
      -H "Authorization: Bearer $CACHEBOOST_API_KEY"
```

## Combine with scheduled warming

Triggering on deploy covers code deployments. But content editors don't go through your deploy pipeline: they publish posts directly in the CMS. Combine deploy-triggered warming with a scheduled nightly full warm to cover both cases:

- **On deploy**: trigger immediately via API
- **Nightly at 3am**: scheduled full warm via cron expression in the boost config

This two-layer approach ensures that neither code deployments nor content updates leave your cache cold for long.


---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try