Publishing on the Internet

A Route shows a DNS sync error

What it means: The published service’s own entry records its last DNS error: commonly a bad API token, or the domain’s zone isn’t actually on the Cloudflare account the token belongs to.

Fix: Fix the token under Exposure → Configuration; it needs Zone → DNS → Edit permission on the specific zone you’re publishing under. The next automatic check retries on its own once the token’s fixed.

If that didn’t work: A DNS error never blocks the service from being published or reachable through its existing record. If it was already resolving, it keeps resolving while you fix the token.

Port-forward shows “Not reachable yet” / readiness never confirms

What it means: There’s no separate reachability check to run and watch: readiness for port-forward is confirmed by a successful certificate issuance the first time you actually publish a service, not by a standalone probe.

Fix: Confirm your router forwards TCP 80 and 443 to the master’s local network address, and that the master has a DHCP reservation so that address doesn’t change under it. Then publish a service: a failed certificate issuance (see “A certificate stays ‘not issued’,” below) is the real, actionable signal if the forward genuinely isn’t working.

If that didn’t work: Many home Internet connections block inbound 80/443 outright, or sit behind CGNAT: a form of shared address that makes inbound forwarding impossible no matter how it’s configured. If the setup wizard’s own connection-type step flags CGNAT, port-forward cannot work on that connection at all; see “Behind CGNAT — use the tunnel,” below.

Behind CGNAT — use the tunnel

What it means: CGNAT (many residential Internet connections use it) means your router was never given a public IP address of its own to forward ports on. There’s nothing to forward to, so port-forward mode can’t work regardless of configuration.

Fix: Use the tunnel connection type instead. The setup wizard’s Cloudflare step needs only one API token — scoped with Zone:DNS:Edit, Zone:Zone:Read and Cloudflare Tunnel:Edit — and Buddy creates and manages the tunnel itself; there’s no separate connector token to go create by hand. If you already run your own cloudflared tunnel, open the step’s [Advanced: use my own tunnel] disclosure and paste its connector token instead. Buddy configures it but never manages or deletes it. Your published domain points at the tunnel automatically; allow a minute for DNS to catch up.

If that didn’t work: Tunnel readiness shows as soon as Cloudflare itself reports the tunnel connected, with no separate check to run. If it never shows connected, confirm the token has the Cloudflare Tunnel:Edit permission specifically, not just DNS access.

A DDNS-only provider can’t get a certificate behind CGNAT

What it means: Issuing a certificate this way needs a provider that can publish a TXT record to prove you control the domain; a DDNS-only provider, with no reachable inbound port 80 either, has no usable way to do that.

Fix: Use Cloudflare for the zone you’re publishing under: it supports the TXT-record challenge Buddy needs, which is why it’s the supported provider for this flow.

If that didn’t work: If your domain is already on a different DNS provider, moving just that zone’s nameservers to Cloudflare (a free plan is enough) is the fix, not switching your whole domain registrar.

“Remove the tunnel” shows “tunnel may still exist at Cloudflare”

What it means: This is a warning, not a failure. The local side — the tunnel connector, its credential, and Buddy’s own record of it — is always torn down regardless. What this message means is that Buddy couldn’t reach the Cloudflare API to also delete the tunnel there, so it may still be sitting in your Cloudflare account.

Fix: Either delete it by hand in your Cloudflare dashboard, or press Remove the tunnel again once Cloudflare is reachable; it’s safe to press again, since the local side is already gone and retrying is a no-op there.

If that didn’t work: If Cloudflare stays unreachable for a while, the tunnel sitting unused in your account isn’t itself harmful. Nothing is still published through it once the local connector is gone.

“Remove the Cloudflare token” fails outright

What it means: Unlike removing just the tunnel, this action is all-or-nothing on purpose: if a Buddy-managed tunnel still exists, deleting it at Cloudflare has to succeed first — deleting the tunnel itself needs that same token — before the token is forgotten. A Cloudflare API error here aborts the whole action and leaves the token in place, rather than forgetting a token that’s still needed.

Fix: Retry once Cloudflare is reachable again.

If that didn’t work: A tunnel you’re managing yourself (added through Advanced: use my own tunnel) is never touched by either action. If you’re trying to remove one of those, do it directly in your own cloudflared setup, not from this button.

A certificate stays “not issued” or shows an ACME error

What it means: The Route’s entry records the last certificate error. Common causes: the domain isn’t actually on your configured provider (so the required DNS challenge can’t be published), you’ve hit Let’s Encrypt’s production rate limits, or the master’s clock is wrong.

Fix: For rate limits while you’re testing, switch to the staging certificate authority under Exposure → Configuration, then switch back to production once things work. Buddy retries automatically on its renewal check. Fix the underlying cause and it re-issues on its own.

If that didn’t work: In the meantime, the site stays reachable over HTTPS with a browser warning: Traefik serves its own default self-signed certificate until a valid one lands, so nothing is fully down while you fix this.

A Route shows “no pods running”

What it means: This is a warning, not something Buddy blocks on: the service’s target exists and stays registered, and its DNS and certificate keep being kept current in the background, but it has no ready pods behind it right now, so requests to it will fail until that changes.

Fix: Bring the underlying app back up. It may have crashed, or been scaled to zero on purpose. Once it has ready pods again, this warning clears on its own.

If that didn’t work: Check the app’s own install status in Store → Installed for why it has no running pods, rather than treating this as an exposure problem specifically.

Publish is stuck on “Continue” / the service picker

What it means: A port Buddy can’t recognise by its name, protocol or a well-known number needs extra confirmation before you can continue: either an automatic check inside the cluster confirms it actually speaks plain HTTP, or you assert that yourself. A port that’s definitely not HTTP is disabled outright. Raw-TCP exposure isn’t supported.

Fix: If the in-cluster check fails, the service likely needs TLS terminated by itself rather than by the panel (out of scope for this flow), or you’ve picked the wrong port; check which port the service actually serves plain HTTP on.

The Kubernetes API, Traefik, and the panel’s own service are blocked from being published this way, by design.

If that didn’t work: If you’re confident the port does speak HTTP but the automatic check keeps failing, confirm the app is actually listening on that exact port from inside the cluster, not just exposing it in its own configuration.