fix: bypass Cloudflare Bot Fight Mode in trigger-coolify-deploy health check - #5
Merged
Andreas-Garcia merged 1 commit intoAug 8, 2026
Conversation
…h check Cloudflare's Bot Fight Mode issues an instant JS challenge (HTTP 403) to GitHub Actions runner IPs on any Cloudflare-proxied hostname, and it runs outside the Ruleset Engine so no Custom Rule can exempt it. Add health_check_origin_ip so callers can curl --resolve the app's real origin IP directly, skipping the proxy for just the health-check request.
Contributor
There was a problem hiding this comment.
Pull request overview
Adds an opt-in mechanism to make trigger-coolify-deploy health checks connect directly to an origin IP (via curl --resolve) so Cloudflare-proxied hostnames don’t fail CI health checks due to Bot Fight Mode.
Changes:
- Added optional
health_check_origin_ipinput and wired it into the health-checkcurlinvocation. - Updated README usage/docs for the new input.
- Documented the fix in
CHANGELOG.mdunder[Unreleased].
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
.github/actions/trigger-coolify-deploy/action.yml |
Adds health_check_origin_ip and applies curl --resolve during health checks. |
README.md |
Documents the new input and shows example usage. |
CHANGELOG.md |
Notes the new input/fix in the Unreleased section. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Comment on lines
+223
to
+230
| resolve_opts=() | ||
| if [ -n "$HEALTH_CHECK_ORIGIN_IP" ]; then | ||
| health_host=$(printf '%s' "$base_url" | sed -E 's#^[a-zA-Z]+://##; s#[/:].*##') | ||
| resolve_opts=(--resolve "${health_host}:443:${HEALTH_CHECK_ORIGIN_IP}") | ||
| echo "Health-checking ${health_url} directly via ${HEALTH_CHECK_ORIGIN_IP} (bypassing any proxy in front of ${health_host}), timeout ${POLL_TIMEOUT_SECONDS}s..." | ||
| else | ||
| echo "Health-checking ${health_url} (timeout ${POLL_TIMEOUT_SECONDS}s)..." | ||
| fi |
Comment on lines
122
to
+126
| coolify_subdomain: ${{ vars.COOLIFY_API_SUBDOMAIN }} | ||
| domain: ${{ vars.DOMAIN_NAME }} | ||
| coolify_api_token: ${{ secrets.COOLIFY_API_TOKEN }} | ||
| health_check_path: /health | ||
| health_check_origin_ip: ${{ vars.SERVER_HOST }} # bypass Cloudflare proxy (Bot Fight Mode 403s CI runners) |
Andreas-Garcia
deleted the
fix/health-check-bypass-cloudflare-bot-fight-mode
branch
August 8, 2026 18:39
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
health_check_origin_ipinput totrigger-coolify-deploy: when set, the health-check request usescurl --resolve <host>:443:<ip>to connect directly to the app's origin server, bypassing any reverse proxy (Cloudflare) in front of the hostname.Motivation
Dogfooding the new
deploy-api-and-web.ymlworkflow inthe-music-deck-admin(staging push) surfaced a real bug:Deploy API (staging)hung for its fullpoll_timeout_seconds, then failed withTimed out after 900s waiting for https://deck-admin-api-staging.themusictree.org/health to return 200 (last: 403)— even though Coolify's own deployment record had already reachedstatus=finishedand the container was healthy (confirmed via direct SSH: clean startup log,curl .../health→ 200 from the VPS itself).Root cause:
infrastructure'sansible/playbooks/group_vars/all.ymlalready documents this exact constraint (see comment abovecoolify_api_subdomain's DNS record) — Cloudflare's Bot Fight Mode issues an instant JS challenge (HTTP 403) to GitHub Actions runner IPs on any Cloudflare-proxied hostname, and it runs outside the Ruleset Engine, so no Custom Rule can exempt it.tmd-admin-api's staging/prod hostnames are intentionallyproxied: true(for WAF/DDoS coverage) — that's correct and shouldn't change. The PR-preview health check worked previously only because preview subdomains areproxied: false.Changes
trigger-coolify-deploy/action.yml: new optionalhealth_check_origin_ipinput. When set, the health-check curl call adds--resolve <health_host>:443:<ip>, connecting straight to the origin IP while keeping the correct SNI/Host header (so TLS/cert validation and virtual-hosting on Traefik still work normally).README.md/CHANGELOG.md.Migration & Deployment notes
No new secrets. Callers pass the existing org variable
vars.SERVER_HOST(207.180.249.29, alreadyALL-visibility) ashealth_check_origin_ipfor staging/prod api jobs.Test plan
the-music-deck-admin: bumpdeploy-api-and-web.ymlto the new version, addhealth_check_origin_ip: ${{ vars.SERVER_HOST }}to the api jobs, re-run the staging deploy and confirm the health check passes instead of 403ing