Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.tryflare.ai/llms.txt

Use this file to discover all available pages before exploring further.

​
Deploy Webhooks

Deploy webhooks give you an automatic security review after every deployment. When your CI/CD pipeline fires the webhook, Flare compares audit logs from before and after the deploy to catch IAM changes, new service accounts, permission escalations, and access pattern shifts introduced by the deployment.
Deploy webhooks require an active GCP connector. Set up your GCP connector first.

​
How it works

  1. You generate a webhook token for your GCP connector
  2. You add a one-line curl call to your CI/CD pipeline (GitHub Actions, CircleCI, Cloud Build, etc.)
  3. After each deploy, your pipeline fires the webhook
  4. Flare waits 60 minutes for post-deploy activity to accumulate
  5. Flare fetches audit logs from before the deploy and after, runs anomaly analysis on both windows, and compares them
  6. The comparison analysis appears in your Analyses history with a “Post-deploy” badge

​
What Flare looks for

The comparison focuses on what changed between the two windows:
Change typeExample
New principalsA service account that only appears after the deploy
IAM mutationsRole bindings or policy changes introduced by the deploy
Permission escalationsActions requiring higher privileges than pre-deploy activity
New IP addressesSource IPs that appear only in the post-deploy window
Frequency shiftsOperations that existed before but now occur at different rates
Disappeared patternsRegular activity that stops after the deploy (may indicate broken access)

​
Setting up

​
1. Generate a webhook token

  1. Go to Connectors
  2. Select your connected GCP connector
  3. In the Deploy webhook section, click Generate webhook token
  4. Copy the token immediately — it is only shown once

​
2. Add to your CI/CD pipeline

Add a webhook call as a post-deploy step. The only required piece is the Authorization header with your token. 
# Add as the last step in your deploy job
- name: Flare post-deploy security review
  uses: tryflare-ai/deploy-webhook@v1
  with:
    token: ${{ secrets.FLARE_WEBHOOK_TOKEN }}
    environment: production  # optional
The commit-sha and branch inputs are automatically populated from the GitHub context. See all available inputs and outputs on the GitHub Marketplace listing.

​
Action outputs

The action exposes two outputs you can use in subsequent workflow steps:
OutputDescription
analysis-atISO timestamp for when the post-deploy analysis will run
queuedtrue if the analysis was successfully queued

​
Request body (optional)

The request body is optional. If provided, the metadata is stored with the analysis for reference.
FieldTypeDescription
commit_shastringGit commit SHA that was deployed
branchstringBranch that was deployed
environmentstringDeployment environment (e.g. “production”)

​
Response

A successful webhook returns 202 Accepted: 
{
  "queued": true,
  "analysis_at": "2026-05-30T15:30:00.000Z",
  "connector_name": "GCP Production"
}

​
Pre-deploy baseline

Flare needs a “before” snapshot to compare against. The pre-deploy lookback window matches your connector’s scheduled run frequency:
Your schedulePre-deploy window
Every hour1 hour before deploy
Every 6 hours6 hours before deploy
Every 24 hours24 hours before deploy
No schedule set1 hour before deploy (default)
This makes the comparison consistent with what you already consider “normal activity” for that connector.

​
Debouncing

If your CI/CD fires the webhook multiple times in quick succession (e.g., multiple merges, failed deploys, retries), Flare debounces automatically. Only the most recent deploy gets analyzed. Earlier pending deploys are overwritten. This means you won’t waste analysis credits on intermediate deployment states — Flare always analyzes the final state.

​
Viewing results

Deploy analyses appear in your Analyses history with a green Post-deploy badge. The analysis name includes the commit SHA when provided (e.g., “Post-deploy abc1234 - GCP Production”). The anomaly results include a changeType for each finding:
  • New — this value appeared only after the deploy
  • Frequency shift — this value existed before but at a different rate
  • Disappeared — this value was present before but absent after the deploy

​
Revoking a token

From the Connectors page, click Revoke token in the Deploy webhook section. This immediately invalidates the token — all CI/CD pipelines using it will receive 401 Unauthorized. Any pending deploy analyses for that connector are also cancelled. Generate a new token if you need to re-enable the webhook.

​
Combining with scheduled runs

Deploy webhooks and scheduled runs work independently on the same connector. You can (and should) use both:
  • Scheduled runs catch anomalies during normal operations
  • Deploy webhooks catch anomalies specifically introduced by deployments
Both appear in the same Analyses history. The badges (“Scheduled” and “Post-deploy”) help you distinguish them.