Scan after deploy
GitHub Actions
Start a scan from your workflow after each deploy.
Integration guide
Scan your website after every GitLab CI/CD deploy
Add a job to .gitlab-ci.yml that calls the Rookflare deploy hook once your deploy stage succeeds, so each pipeline on your default branch starts a scan.
Overview
What the GitLab CI/CD integration does
What it does
- Adds one small job in the .post stage, which GitLab places after every other stage of the pipeline.
- Sends $CI_COMMIT_SHA as the ref, so retrying a pipeline or re-running the job for the same commit starts one scan.
- Uses the curlimages/curl image, so it works on shared runners and on self-managed runners with outbound HTTPS.
Before you start
- A Growth and Agency plan. The 14-day free trial runs on Growth, so you can set it up before you pay.
- A verified website in Rookflare with monitoring turned on, and the owner or admin role.
- A GitLab project whose pipeline deploys your website, and the Maintainer role (or higher) to add CI/CD variables.
Setup
Set up GitLab CI/CD step by step
-
Step 1
Create the deploy hook in Rookflare
Open the website, go to the Settings tab and select “Create deploy hook” in the “Scan after deploy” card. Copy the token right away: this is the only time Rookflare shows it in full. The card keeps the endpoint and the last four characters of the token.
The Scan after deploy card right after “Create deploy hook”: the full token is shown once, with the endpoint below it. -
Step 2
Add the token as a CI/CD variable
In GitLab, open Settings → CI/CD → Variables and add ROOKFLARE_DEPLOY_TOKEN with the token as its value. Mark it masked so it never shows in job logs. Mark it protected only if you deploy from protected branches or tags, because protected variables are not passed to other pipelines.
-
Step 3
Add the job to .gitlab-ci.yml
The job runs in the .post stage. When a job in an earlier stage fails, later stages do not start, so a failed deploy never triggers a scan. The rule limits it to the default branch; change it to match how you deploy.
rookflare-scan: stage: .post image: name: curlimages/curl:8.11.1 entrypoint: [""] rules: - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH script: - > curl -fsS -X POST "https://app.rookflare.example/api/webhooks/deploy" -H "Authorization: Bearer $ROOKFLARE_DEPLOY_TOKEN" -H "Content-Type: application/json" -d "{\"ref\": \"$CI_COMMIT_SHA\"}"Sample endpoint and placeholder token. The dashboard fills in yours.
-
Step 4
Run a pipeline on the default branch
Merge or push to the default branch, or start a pipeline from Build → Pipelines → Run pipeline. The rookflare-scan job appears in the last column of the pipeline graph. In Rookflare, “Last used” updates and the website’s Scan history shows a scan with the trigger “After deploy”.
The website’s Scan history: the newest scan has the trigger “After deploy” and is scanning; below it a scheduled scan and an earlier deploy scan, both completed.
Troubleshooting
If it does not work
-
The job fails with 401 on some branches
A protected variable is only available in pipelines for protected branches and tags. On any other branch $ROOKFLARE_DEPLOY_TOKEN is empty. Protect the deploy branch, or remove the protected flag from the variable.
-
The pipeline does not start at all
GitLab does not run a pipeline that contains only .pre or .post jobs. If your rules skip every deploy job on that branch, the Rookflare job alone is not enough to start a pipeline, which is what you want.
-
The job never runs when you deploy from tags
Tag pipelines have no $CI_COMMIT_BRANCH, so the default-branch rule does not match. Use a rule on $CI_COMMIT_TAG instead, and keep the job tied to the same condition as your deploy job.
-
Rookflare answers with an error code
401 means a wrong, rotated or revoked token, 402 a plan or daily limit, 409 an unverified or paused website and 429 more than 30 calls a minute. The cURL guide explains each answer and what to do.
Where should the deploy token live?
In your deploy tool’s secret store, never in the repository. The token can only start scans of one website, and you can rotate or revoke it on the website’s Settings tab at any time; the old token stops working right away.
Can the scan start before later stages finish?
Yes. Add “needs: [your-deploy-job]” to the Rookflare job. GitLab then starts it as soon as that job succeeds and ignores the stage order. Keep the same rules as the deploy job.
We have review apps and staging environments. Which deploys should call Rookflare?
Only the one that ships the address you monitor, usually the job with environment: production. Review apps and staging have their own URLs, and a call from them would scan your live site even though nothing changed there.
Why is GitLab not a tab in the dashboard?
The dashboard shows ready-made snippets for GitHub Actions, Vercel, Netlify, WordPress and cURL. The GitLab job is the same cURL request with GitLab’s variables, so it works with the same endpoint and token.
Start monitoring your website
Add your address, pick the pages and approve the first scan as your baseline.
Plans start at €19 per month. Prices are provisional.