Cloudflare Tunnel origin settings moved to the dashboard on 18 August 2026: 3 gaps to check

Summary. On 18 August 2026 Cloudflare published a changelog post saying you can now configure Cloudflare Tunnel origin application settings when adding or editing a published application route in the Cloudflare dashboard, under an "Additional application settings" panel with three categories: HTTP, TLS and Connection. The reference page that post links to, Origin parameters, carries dateModified of 2026-05-07 and has not been touched since. That page already describes the same five-step dashboard flow, and it lists four categories, not three: the fourth is Access. It also marks two parameters, proxyAddress (default 127.0.0.1) and proxyPort (default 0), as locally-managed only with a UI name of --. The last cloudflared release, 2026.8.2, shipped on 14 August 2026, four days before the announcement, so nothing on your servers changes. What changes is which team members can now alter connection behaviour without touching a config file.

What Cloudflare actually announced

The changelog entry is titled "Configure origin application settings for Cloudflare Tunnel in the dashboard" and is dated 18 August 2026. Its wording is specific: these settings "control how cloudflared connects to your origin server and were previously only available in the Cloudflare One dashboard or via local configuration files."

The panel is reached by editing a published application route, expanding Additional application settings, and choosing from three groups:

HTTP, for a custom Host header or disabling chunked encoding.
TLS, for origin server name, CA pool, TLS timeout, disabling TLS verification, matching SNI to host, or HTTP/2 to origin.
Connection, for connect timeout, keep-alive timeout, keep-alive connections, TCP keep-alive interval, proxy type, or disabling Happy Eyeballs.

That is a control-plane change. Cloudflare's cloudflared release feed shows the newest tagged release as 2026.8.2, published 14 August 2026, before the announcement. No agent upgrade is required and no version gate applies.

Gap 1: the reference doc predates the announcement by three months

The changelog closes with "For the full list of origin parameters, refer to Origin parameters." That page reports "dateModified":"2026-05-07" in its JSON-LD and renders "Last updated May 7, 2026" in the body.

Open it and you find, under "Update origin parameters", the exact procedure the changelog announces: go to Networking > Tunnels, select your tunnel, open the Routes tab, choose Edit route or Add route, expand Additional application settings, modify parameters under HTTP, TLS or Connection, then Save changes. Both pages link to the same dashboard destination, dash.cloudflare.com/?to=/:account/tunnels.

So the reference documentation described this flow in May and the changelog announced it in August, and nothing in either page tells you when the capability actually became available in your account. If you went looking for "Additional application settings" in June on the strength of the docs and could not find it, that was not a misread.

The practical consequence is narrow but real: you cannot use the doc's date to decide whether a parameter is live. A page dated 7 May 2026 documenting an 18 August 2026 feature means the date field is not tracking the product. Check the panel in your own account instead.

Gap 2: the Access category is missing from the announcement

The changelog names three categories. The Origin parameters page has four sections: TLS settings, HTTP settings, Connection settings and Access settings.

The Access section documents one parameter, access, with the dashboard label "Protect with Access". It makes cloudflared validate the Cloudflare Access JWT before proxying traffic to your origin. For every L7 request to a protected hostname, Access sends the token to cloudflared in a Cf-Access-Jwt-Assertion request header.

The only worked example the doc gives for access is YAML:

access:
  required: true
  teamName: <your-team-name>
  audTag:
    - <Access-application-audience-tag>
    - <Optional-additional-tags>

That snippet is introduced with "To enable this security control in a configuration file", which is the locally-managed path. The one origin parameter that is a security control is also the one the 18 August post does not list among the dashboard categories, and the one whose documented setup instructions assume a file on disk.

If you are relying on origin-side JWT validation as defence in depth, verify it in the panel before you delete a config file. Cloudflare's own JWT guidance (page dated 6 May 2026) recommends validating the Cf-Access-Jwt-Assertion header rather than the CF_Authorization cookie, "since the cookie is not guaranteed to be passed". The AUD tag is per application, so a tunnel fronting several Access applications needs several tags in audTag.

Gap 3: two parameters can never leave the config file

Two Connection settings are flagged in the doc with the note "For locally-managed tunnels only" and a UI name of --:

Parameter	Default	Dashboard UI name	Settable from the dashboard
`connectTimeout`	30s	Connect Timeout	Yes
`tlsTimeout`	10s	TLS Timeout	Yes
`keepAliveTimeout`	1m30s	Idle Connection Expiration Time	Yes
`keepAliveConnections`	100	Keep Alive Connections	Yes
`tcpKeepAlive`	30s	TCP Keep Alive Interval	Yes
`proxyType`	`""`	Proxy Type	Yes
`proxyAddress`	`127.0.0.1`	`--`	No, locally-managed only
`proxyPort`	`0`	`--`	No, locally-managed only

proxyType accepts "" for the regular proxy or "socks" for a SOCKS5 proxy, and it is settable remotely. The listen address and port for that same proxy are not. A team routing SSH or RDP through a SOCKS5 proxy on a non-default bind address keeps a config.yml, which means the migration to dashboard management is partial for exactly the workloads that most need a fixed bind address.

Two more details in the same table are worth reading closely before anyone moves settings. caPool is described as a "local file path to the certificate authority (CA) for your origin server certificate (for example, /root/certs/ca.pem)". That value is stored on Cloudflare's side for a remotely-managed tunnel but resolved on the machine running cloudflared, so it only works if the path exists identically on every replica. And the UI labels do not match the YAML keys: keepAliveTimeout appears as "Idle Connection Expiration Time", http2Origin as "HTTP2 connection", noTLSVerify as "No TLS Verify". You cannot grep a config file for what someone changed in the dashboard.

Who this affects, and how to tell if that is you

Cloudflare's locally-managed tunnels page, dated 16 April 2026, is direct about the intended split: remotely-managed tunnels are recommended "for most use cases", and locally-managed tunnels are "intended for specific scenarios such as local development, testing, or legacy configurations". The 18 August change makes the remote path cover more ground, which sharpens a question a lot of teams have deferred.

You are affected if any of these are true:

You run a locally-managed tunnel with an originRequest block and were keeping it only because the dashboard could not express those values.
You have per-ingress overrides. The configuration file doc, dated 9 July 2026, shows a top-level connectTimeout: 30s with a single service overriding it to 10s; that inheritance model is a file-level construct.
You bind a SOCKS5 proxy to something other than 127.0.0.1.
You depend on origin-side Access JWT validation.

There is also a documentation chain worth knowing about, because it costs time. The configuration-file page links "origin-specific properties" to /tunnel/configuration/#origin-parameters. That page is dated 21 May 2026, and its Origin parameters section is a pointer: "For the complete list of origin parameters and setup instructions, refer to Origin parameters." Three pages, three different modified dates (7 May, 21 May, 9 July 2026), one list of parameters. Budget for the hop.

What to do this week

Audit before you migrate. The real cost here is usually the audit, not the change.

Run cloudflared tunnel ingress validate against your current config file and record the resolved settings per hostname, including inherited top-level values.
Write down every parameter you have not set explicitly. Moving to remote management means unset values take the documented defaults: connectTimeout 30s, tlsTimeout 10s, keepAliveTimeout 1m30s, keepAliveConnections 100, tcpKeepAlive 30s. Silence is not "same as today" unless today matches those numbers.
Confirm proxyAddress and proxyPort are at defaults before retiring a config file, or keep the file.
Check whether "Protect with Access" appears in your panel, and if origin JWT validation matters, keep the access block until you have seen it work from the dashboard.
Confirm outbound reachability to Cloudflare on port 7844, which the Tunnel setup page still lists as the prerequisite for a restrictive firewall.

One cost note that has not changed: publishing an application through a tunnel does not need a paid Cloudflare Access plan. The published applications page, dated 23 June 2026, says Access seats are required only when you secure the application with Access policies. Seat consumption is per user, not per application: the seat management page, dated 1 May 2026, states a user "will occupy and consume a single seat regardless of the number of applications accessed", and once all seats are consumed, additional users who try to log in are blocked.

India-specific considerations

For Indian teams keeping origin servers in-country under the Digital Personal Data Protection Act 2023, the change is control-plane only and does not move any traffic path. What it does move is configuration state: a remotely-managed tunnel stores origin parameters on Cloudflare rather than on your server. That is a change to where a configuration record lives, so record it in your change log and your data-flow documentation before an auditor finds it first. Teams running a mix of dashboard-managed and file-managed tunnels should also decide which is authoritative, because the two do not reconcile automatically.

What is still unknown

Cloudflare has not published a date on which the dashboard panel became available in all accounts, nor a note explaining why the reference page was written in May. The changelog does not say whether Access settings appear in the panel for remotely-managed tunnels, and the Origin parameters page has not been updated since the announcement. Neither page mentions Terraform or API parity for the new panel. Treat all four as unresolved and verify in your own account.

FAQ

What did Cloudflare change for Cloudflare Tunnel on 18 August 2026?

Cloudflare announced that origin application settings can be configured in the Cloudflare dashboard when adding or editing a published application route. The changelog groups them under an "Additional application settings" panel with three categories: HTTP, TLS and Connection. The post says these settings were previously only available in the Cloudflare One dashboard or in local configuration files.

Do I need to upgrade cloudflared for this?

No. The newest tagged cloudflared release is 2026.8.2, published 14 August 2026, four days before the announcement. The change is a control-plane feature in the dashboard rather than an agent capability, so no version gate applies and no upgrade or restart is required on servers already running a connected tunnel.

Why is the Origin parameters doc dated 7 May 2026?

Its JSON-LD reports dateModified of 2026-05-07 and it renders "Last updated May 7, 2026". That page already contains the five-step dashboard procedure the August changelog announces, and it has not been updated since. Do not use the page date to judge whether a given parameter is live in your account.

Which origin parameters cannot be set from the dashboard?

Two. The Origin parameters page marks proxyAddress, default 127.0.0.1, and proxyPort, default 0, with the note "For locally-managed tunnels only" and a UI name of --. Both control the listen socket for the proxy that translates HTTP traffic into TCP for protocols such as SSH and RDP.

What is the Access category the changelog leaves out?

The Origin parameters page has a fourth section, Access settings, holding the access parameter with the dashboard label "Protect with Access". It makes cloudflared validate the Cloudflare Access JWT before proxying to your origin. Access sends that token in a Cf-Access-Jwt-Assertion request header on every L7 request.

What defaults apply if I stop using a configuration file?

Unset values take documented defaults: connectTimeout 30 seconds, tlsTimeout 10 seconds, keepAliveTimeout 1 minute 30 seconds, keepAliveConnections 100 idle connections, and tcpKeepAlive 30 seconds. If your file relied on inheritance from a top-level originRequest block, capture the resolved value per hostname before you migrate anything.

Does publishing an application through a tunnel need paid Access seats?

No. Cloudflare's published applications page, dated 23 June 2026, says a paid Cloudflare Access plan is not required to publish an application via Cloudflare Tunnel. Seats are consumed only when you secure the application with Access policies, and one active user consumes one seat regardless of how many applications they open.

Why do the dashboard labels not match my YAML keys?

The Origin parameters page lists a separate UI name for each parameter, and several differ from the key. keepAliveTimeout appears as "Idle Connection Expiration Time", http2Origin as "HTTP2 connection", caPool as "Certificate Authority Pool". Keep a mapping alongside your runbook so config-file reviews and dashboard changes can be reconciled.

How eCorpIT can help

eCorpIT builds and operates Cloudflare Tunnel and Zero Trust connectivity for teams running origins in India and abroad, including migrations from locally-managed config files to remotely-managed tunnels without changing effective timeouts. We audit resolved per-hostname settings first, then move them, so nothing silently reverts to a default. If a connector migration is on your roadmap this quarter, ask our networking team to review your tunnel configuration.