Purge Your CDN Cache from Your Deploy Pipeline

Every deploy that changes a file the CDN caches ends the same way: the new version sits on your origin while the edge keeps serving the old copy until it expires. Purging by hand after each release works until the release that someone forgets. This guide makes the purge part of the pipeline itself: your CI calls the Melbicom API as its final step, and stale assets no longer reach visitors.

Prerequisites

A Melbicom CDN resource serving your site’s assets.
A Melbicom API token, from Create Your Melbicom API Token.
A CI/CD pipeline that can run shell commands, with an account allowed to manage its secrets and variables; the example uses GitHub Actions, and any runner with curl works the same way. The one-time service lookup in Step 1 also uses jq, on your own machine.

Why Purge from the Pipeline

The release reaches visitors without delay: the purge runs the moment the deploy finishes, not as a separate manual task.
One less manual step: the release process is fully described by the pipeline, purge included.
Scoped purges protect your hit ratio: automating makes it easy to purge only what changed, so the rest of the cache keeps serving.

Step 1: Find Your Service ID

The purge endpoint is addressed by service id. List your services once and note the id of your CDN plan:

curl -s -H "Authorization: Bearer YOUR_TOKEN" https://api01.melbicom.net/api/services \
  | jq '.[] | select(.productName | contains("CDN")) | {id, productName, serviceStatus}'

Every CDN plan’s product name contains CDN, so the filter returns exactly your CDN services. The id is stable, so this is a one-time lookup, not a pipeline step.

Step 2: Store the Token as a CI Secret

The token grants full account access, so it belongs in your CI’s secret store, never in the repository. In GitHub Actions, add it as a repository secret named MELBICOM_API_TOKEN (Settings, Secrets and variables, Actions), and the service id as a repository variable MELBICOM_SERVICE_ID.

Step 3: Add the Purge Step

Append the purge as the last step of your deploy job. This example purges the /assets/ folder of the resource cdn.example.com after every push to main; replace both with your own values:

name: deploy
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy the site
        run: ./deploy.sh
      - name: Purge the CDN cache
        run: |
          curl -sf -X POST \
            "https://api01.melbicom.net/api/services/${{ vars.MELBICOM_SERVICE_ID }}/resources/purge-cache" \
            -H "Authorization: Bearer ${{ secrets.MELBICOM_API_TOKEN }}" \
            -H "Content-Type: application/json" \
            -d '{"resource_name": "cdn.example.com", "resource_url": "/assets/"}'

resource_name is your CDN resource’s name and is always required. resource_url scopes the purge: a file path purges that file, a path ending in / purges the folder, and omitting it purges the entire resource over both HTTP and HTTPS. An optional purge_scheme of http or https narrows a path purge to one scheme; the default covers both.

Step 4: Purge Only What Changed

Purging the whole resource on every deploy works, but it empties the cache: every object is refetched from your origin and the first visitors wait on cold-cache responses. Point resource_url at the folder your deploy actually rewrites, and version file names where you can, so unchanged objects keep serving from the edge. The mechanics of what a purge does at the edge are covered in Purge a URL or Your Entire CDN Cache.

What You’ve Built

A release process that ends with fresh content at the edge, with no manual step left. The purge is scoped, so the cache hit ratio is preserved across deploys, and the token driving it lives in the CI secret store with the rest of your credentials. The same call works from any pipeline: GitLab CI, Jenkins, a plain deploy script, anything that can run curl. The full endpoint list is in Melbicom API: Authentication and Endpoints.