[Feature]: Pull-based auto deploy (poll the Git branch) for servers that can't receive webhooks

[Khalid1G]

Problem

Automatic deployments in Coolify are push-based: the Git provider (GitHub/GitLab/Gitea/Bitbucket App or a manual webhook) has to send a webhook to the Coolify instance. That only works when the instance is reachable from the provider over the internet.

Many self-hosted instances are not reachable, by design or by circumstance:

• servers inside company, university or lab networks, reachable only over a VPN
• home labs behind NAT or CGNAT without port forwarding
• instances whose dashboard is deliberately kept off the public internet
• networks where only outbound connections are allowed

These servers can still reach the Git provider (cloning works), but they never receive push events. Today the options are to deploy by hand, run an external CI job that calls the Deploy API (which also needs to reach the instance), or add a tunnel (Cloudflare Tunnel, Tailscale Funnel, ngrok…) whose only purpose is to let webhooks in. A tunnel adds a public endpoint and another service to operate, which is often exactly what these setups are trying to avoid.

Proposal: pull-based auto deploy (branch polling)

An optional, per-application setting next to Auto Deploy:

• Auto deploy mode: Webhook (current) / Polling
• Polling interval: e.g. 1, 5, 15 minutes (or a cron expression)

On each interval Coolify checks the latest commit of the application's branch and, if it differs from the last deployed commit, queues a deployment, exactly as if the push webhook had arrived.

Suggested behaviour:

• Use the credentials Coolify already has for the application (Git App installation token, deploy key, or public URL). git ls-remote <repo> refs/heads/<branch> works for every provider, including deploy-key and generic Git sources, and transfers almost nothing.
• Cheap when nothing changed: for GitHub, conditional requests (ETag / If-None-Match) return 304 and don't count against the rate limit; with ls-remote a check is a few hundred bytes.
• No duplicate or runaway deployments: skip if a deployment for that application is already queued or running; don't retry a commit whose build failed until a new commit arrives.
• Respect existing settings: Watch Paths (compare the files changed between the deployed commit and the new one), and the server's concurrent build limit.
• Visibility: show "last checked" and "deployed / latest commit" on the application page, and add an entry to the deployment log ("triggered by polling, commit abc123").
• Jitter the schedule so many applications don't all poll at the same second.

Why it fits Coolify

• No new inbound exposure: it works on fully private servers, which is a strong security property for a self-hosted PaaS.
• It reuses existing pieces: sources and their credentials, the deployment queue, Watch Paths and the scheduler that already runs backups and scheduled tasks.
• It is the same idea as [Feature Request] Poll container registry for new versions #12156 (poll a container registry for new image versions), applied to Git sources. Both could share one per-application "check for updates" scheduler, with notify or auto deploy as the action.
• Pull-based reconciliation is a well-established pattern in deployment tools (GitOps controllers such as Argo CD and Flux poll Git on an interval by default; Portainer offers polling for Git-based stacks), so users coming from those tools already expect it.

Alternatives considered

• Tunnels (Cloudflare Tunnel, Tailscale Funnel, ngrok): they work, but they add a public endpoint, an extra service and often an account/domain, only to receive webhooks.
• External CI calling the Deploy API: the CI runner must reach the instance, so it has the same reachability problem (or needs a self-hosted runner next to Coolify).
• A cron job on the server that polls Git and calls the Deploy API: what people do today. It works, but it duplicates logic Coolify already has (credentials, last deployed commit, queue state) and is invisible in the UI.

I'm happy to test a build of this, and to help with the implementation if the maintainers agree on the approach.

[Cinzya]

Some users created a small app that catches the webhook requests on a public server and forwards the requests on a internal connection back to Coolify.