Deploy-triggers

Warm automatisch op na elke release, vanuit Vercel, Netlify, Shopify of elke CI-pijplijn.

9 min leestijd

Deploys zijn de betrouwbaarste manier om een hele site in één keer koud te maken. Een release maakt caches massaal ongeldig, en elke bezoeker in de minuten daarna betaalt gelijktijdig de opbouwkosten — precies wanneer je het meest op problemen let.

Deploy-triggers maken opwarmen onderdeel van uitrollen. Slaagt je deploy, dan roept je platform Cache Rocket aan en begint het opwarmen zonder dat iemand een dashboard opent.

Webhook-URL's en voorbeelden staan op Account → Deploy-integraties.

Hoe het werkt

Je geeft je hostingplatform of CI een URL om aan te roepen na een geslaagde deploy. Het request draagt je API-sleutels als headers, plus een kleine JSON-body die zegt wat opgewarmd moet worden.

De algemene vorm

bash

curl -X POST https://api.cacherocket.com/web/v1/public/webhooks/vercel \
  -H "Content-Type: application/json" \
  -H "X-Public-Key: JOUW_PUBLIEKE_SLEUTEL" \
  -H "X-Secret-Key: JOUW_GEHEIME_SLEUTEL" \
  -d '{"hostname":"www.example.com"}'

Platform	Webhook-pad
Vercel	`/web/v1/public/webhooks/vercel`
Netlify	`/web/v1/public/webhooks/netlify`
Shopify	`/web/v1/public/webhooks/shopify`

Note

De exacte basis-URL voor jouw account staat op de pagina Deploy-integraties, samen met een kant-en-klaar curl-voorbeeld per platform.

Een payload kiezen

De JSON-body bepaalt wat opgewarmd wordt. Drie opties, van breed naar chirurgisch:

Body	Effect	Gebruik als
`{"hostname":"www.example.com"}`	Start elke warmer die bij die hostname past	Een normale volledige release. De gebruikelijke keuze.
`{"crawlerId":"…"}`	Start één specifieke warmer	Je hebt meerdere warmers per site en maar één is relevant voor deze deploy.
`{"urls":["https://…"]}`	Warmt precies die URL's met voorrang op	Een gedeeltelijke publicatie, of een handvol pagina's waarvan je weet dat ze veranderd zijn.

Specifieke URL's met voorrang opwarmen na een gedeeltelijke publicatie

bash

curl -X POST https://api.cacherocket.com/web/v1/public/webhooks/netlify \
  -H "Content-Type: application/json" \
  -H "X-Public-Key: JOUW_PUBLIEKE_SLEUTEL" \
  -H "X-Secret-Key: JOUW_GEHEIME_SLEUTEL" \
  -d '{"urls":["https://www.example.com/","https://www.example.com/pricing"]}'

Vercel

Voeg de Cache Rocket-URL toe als Deploy Hook of integratiewebhook in je projectinstellingen, geactiveerd bij geslaagde productie-deploys. Authenticeer met de headers X-Public-Key en X-Secret-Key.

Tip

Activeer alleen bij productie-deploys. Preview-deployments hebben eigen URL's, staan niet op je geverifieerde hostname, en die opwarmen verspilt je budget.

Netlify

Gebruik een notificatiewebhook op de gebeurtenis deploy succeeded, gericht op het Netlify-pad met dezelfde API-sleutelheaders.

Shopify

Richt webhooks voor themapublicatie of apps op het Shopify-pad, zodat winkelwijzigingen opnieuw opgewarmd worden zodra ze live staan.

Elke CI-pijplijn

Er is niets platformspecifieks aan het request — het is een HTTP POST. Voeg hem toe als laatste stap van elke pijplijn.

GitHub Actions

yaml

- name: Cache Rocket opwarmen na deploy
  run: |
    curl -X POST https://api.cacherocket.com/web/v1/public/webhooks/vercel \
      -H "Content-Type: application/json" \
      -H "X-Public-Key: ${{ secrets.CACHEROCKET_PUBLIC_KEY }}" \
      -H "X-Secret-Key: ${{ secrets.CACHEROCKET_SECRET_KEY }}" \
      -d '{"hostname":"www.example.com"}'

Zet de geheime sleutel nooit hard in een pijplijnbestand

Gebruik de versleutelde secrets-opslag van je CI-provider, zoals hierboven. Pijplijndefinities staan in je repository, en een gecommitte sleutel is een uitgelekte sleutel.

Alternatief: triggerWarm

Er is ook een eenvoudiger endpoint dat de sleutels in de body verwacht in plaats van in headers, wat past bij omgevingen waar eigen headers instellen lastig is:

bash

curl -X POST https://cacherocket.com/api/wordpress/triggerWarm \
  -H 'Content-Type: application/json' \
  -d '{"publicKey":"JOUW_SLEUTEL","secretKey":"JOUW_GEHEIM","hostname":"example.com"}'

Een bijbehorend endpoint warmUrls warmt een expliciete lijst URL's met voorrang op.

De juiste volgorde

De volgorde is belangrijker dan mensen verwachten:

1
De deploy is klaar en de nieuwe versie staat live
Een release opwarmen die nog niet volledig uitgerold is, cachet gewoon de oude.
2
Purge het CDN, als de deploy de gecachete uitvoer veranderde
Anders leest het opwarmen wat al gecachet staat en verbetert er niets.
3
Start dan het opwarmen
Nu haalt de warm-run echt nieuwe content op en vult hij de cache daarmee.

Te vroeg opwarmen is de klassieke fout

Vuurt de trigger voordat de deploy volledig live is, of voordat het CDN gepurged is, dan warm je zorgvuldig de vorige versie op. Hang aan de gebeurtenis *geslaagd*, niet aan *gestart*.

Veelvoorkomende problemen

De webhook geeft 401 terug.: De sleutels zijn verkeerd, verlopen of vervangen door een nieuwer paar. Controleer of beide headernamen exact X-Public-Key en X-Secret-Key zijn, en let op afgekapte waarden in je secrets-opslag.
Hij geeft succes terug maar er wordt niets opgewarmd.: De hostname in de body past vermoedelijk bij geen enkele actieve warmer. Controleer de exacte hostname, inclusief www, en of de bijbehorende warmer Actief is.
Het opwarmen liep, maar bezoekers raken nog koude pagina's.: Vrijwel altijd de volgorde — of hij vuurde voordat de deploy live was, of het CDN werd na het opwarmen gepurged in plaats van ervoor. Zet een purge-stap vóór de trigger.
Preview-deploys verbruiken mijn URL-budget.: Beperk de webhook tot alleen productie-deploys.
Is dit hetzelfde als een CDN-purge?: Nee. Deploy-triggers starten opwarmen; ze maken niets ongeldig. CDN-integraties purgen en warmen daarna weer op. Veel teams gebruiken beide.