Access Git Behind a Firewall¶
Capawesome Cloud Native Builds needs to clone your Git repository to run a build. If your Git server is behind a firewall, the build runner cannot reach it by default. This guide covers three approaches to solve this, each with different trade-offs for security, complexity, and maintenance.
Reverse Tunnel (Recommended)¶
A reverse tunnel lets you expose your internal Git server to the internet without opening inbound firewall ports.
You run a small daemon inside your network that establishes an outbound-only connection to a tunnel provider.
The provider assigns a public hostname (e.g., git-tunnel.yourcompany.com) that routes traffic through the tunnel to your internal Git server.
This is the recommended approach for most teams because your firewall remains fully closed to inbound traffic while Native Builds can access your repository securely.
There are several tunnel providers available, such as Cloudflare Tunnel, ngrok, or Tailscale Funnel. Refer to your chosen provider's documentation for setup instructions.
Once the tunnel is running, use the public hostname as the server URL when connecting Capawesome Cloud to your Git repository.
Repository Mirroring¶
You can set up a mirror of your internal Git repository on a public Git hosting service like GitHub or GitLab. Native Builds then clones from the mirror instead of your internal server, so no direct access to your network is needed.
The most common approach is push mirroring, where your internal server pushes changes to the external mirror on a schedule.
Some Git hosting services like GitLab offer built-in mirroring.
For others, you can set up a cron job that runs git push --mirror to keep the mirror in sync.
Sync Delay
Mirrors are not real-time. There is always a delay between a push to your internal server and the mirror being updated. Make sure your mirroring schedule is frequent enough for your build workflow.
IP Whitelisting¶
You can whitelist the IP ranges of the infrastructure providers that Capawesome Cloud uses to run Native Builds. This allows the build runners to access your internal Git server directly through your firewall.
Required IP Ranges¶
You need to whitelist the IP ranges from the following providers:
Security Considerations
These IP ranges are shared across all customers of the respective providers. Whitelisting them allows any service hosted on those networks to reach your Git server, not just Capawesome Cloud. Make sure your Git server requires proper authentication (e.g., SSH keys or access tokens) in addition to the IP whitelist.
Comparison¶
| Reverse Tunnel | Repository Mirroring | IP Whitelisting | |
|---|---|---|---|
| Firewall changes | None | None | Inbound rules required |
| Security | High (outbound-only, encrypted) | High (no exposure) | Low (broad shared IP ranges) |
| Real-time access | Yes | No (sync delay) | Yes |
| Complexity | Medium | Low to medium | Low |
| Maintenance | Low | Medium (sync schedule, credentials) | Medium (IP range updates) |