Is it possible to add routes to a Cloudflare Remotely-managed Tunnel via API calls?
Remotely managed tunnels seem to have a lot of advantages over locally managed tunnels - they're simpler to set up, have the webui etc...
But there's certainly advantages to doing everything from the CLI - eg changing CNAME records for the tunnel via API calls, with flarectl. The downside to this is that we seem to need to restart the cloudflared service in order to incorporate changes make to the config.yml tunnel configuration file.
Is there any way we can set up a remotely managed tunnel, but then modify its routes via api calls rather than the web UI?
18 Replies
The answer is yes but not cleanly. Local tunnels with their yml configuration came first. The remote managed tunnels simply mangle a json version of the same configuration on every update (you can see exactly what it does in dev tools -> network tab). The endpoint for updating config is https://developers.cloudflare.com/api/operations/cloudflare-tunnel-configuration-put-configuration. You'd have to pull down, modify, push back up config, and then use the DNS API to create tunnel CNAMEs as well
Cloudflare API Documentation
Interact with Cloudflare's products and services via the Cloudflare API
Oof. Thanks very much for the quick answer! I'll take a look, but will probably stick with the locally managed method.
Are there any plans to unify them at all?
unify them?
well, make the remotely and locally managed tunnels use all of the same mechanisms, such that they are both just different client wrappers over the same thing. There's a lot of subtle differences
well what do you mean the "same mechanisms"? Fundementally they're always going to be different, remote tunnels request config stored on edge and config updates get pushed down through tunnel, local tunnels use local configs
yml is a superset of json so even local tunnels should be able to be used with the same configuration
ok, thanks. I'll look into the json approach that you mentioned above!
@Chaika I just created a remotely managed tunnel in the web UI and created a few routes. It does, indeed, seem very simple to add/remove routes in the json payload. However, I just did that from curl requests and while it successlly modifies the tunnel config, it isn't modifying the zone CNAMES. Does that only happen when you modify things via the zero trust web UI? If so, I suppose I need to make additional api calls to modify the cnames, just as I am already doing with locally-managed tunnels? This seems to be the case (and works when I do it). I just want to make sure that I'm not missing anything/not doing anything extra.
t isn't modifying the zone CNAMES. Does that only happen when you modify things via the zero trust web UI?You should be able to see the API Calls to the DNS API when you add/remove public hostnames But yea, that's all separate, the json config is purely just shoving the config for your tunnel to pull down, no extra magic there
No, dev tools only shows a few GET requests to the tunnel config endpoint, and a single PUT request to it as well. Nothing to Zone DNS . it must handle the zone dns behind the scenes. it calls
https://dash.cloudflare.com/api/v4/accounts rather than https://api.cloudflare.com/client/v4/accounts/
Anyway, its not a big deal. I can do separate api requests to modify Zone DNS. Its nice that the remotely managed endpoint doesnt require restarting the cloudflared service. And also has the web UI.it must handle the zone dns behind the scenes.It does the dns records POST first, maybe that's why you're missing it?
or you're not adding a brand new public hostname or something
but yea the zt dash directly interfaces with the dns api, no magic there
https://dash.cloudflare.com/api/v4/accounts rather than https://api.cloudflare.com/client/v4/accounts/yea they should all match up between dash.cloudflare.com/api/v4 -> api.cloudflare.com/client/v4, even undocumented ones (although those can change at any time)
very weird. I dont see anthing for dns_records
you're just adding a brand new non-wildcard public hostname to a subdomain that doesn't have any existing records?
yes
{newsubdomain}.{oneofmydomains.com}. No path. no settings. just https localhost:443
weird maybe somehow being filtered out, you can see the ones for deletion too, it searches for the record and then deletes it by ID
oh god, im a fool. I filtered them earlier to focus on the tunnel stuff.
nothing too fancy eitherway, just a simple cname to <tunnel-id>.cfargotunnel.com
Yes, that took me a while to figure out. Once I realized that, it made it all much easier. Though i then did a lot of unnecessary bash scripting to incorporate this all into a cross-os cli too, but its far easier to do it all with a remotely managed tunnel, api request to update the tunnel route and dns cnames.
Thanks for your help!