Protect Apps with Cloudflare Zero Trust

Choose how users will connect

Cloudflare calls the first path a public hostname application protected by Cloudflare Access. The second path uses private network access and private hostname routing. In Wodby, these appear as the Protected and Private network access types.

What you need

• A Wodby account and a Kubernetes cluster using app routing.
• A Wodby app with at least one enabled external HTTP endpoint.
• A Cloudflare account with a Zero Trust organization.
• Permission to create a custom Cloudflare User API Token.

Cloudflare Access also needs an active DNS zone and a reusable Allow policy. Private network access instead needs enrolled Cloudflare One devices and an appropriate WARP device profile.

1. Create the Cloudflare API token

Copy your Cloudflare Account ID, then open My Profile → API Tokens and create a custom User API Token. Do not use an account API token because its policy editor does not expose the required zone permission rows.

Required for both cases

• Account / Cloudflare One Connector: cloudflared / Edit

Add for Cloudflare Access

• Account / Access: Apps and Policies / Edit
• Zone / Zone / Read
• Zone / DNS / Edit

Add for Private network

• Account / Cloudflare One Networks / Edit

Under Account Resources, include the intended account. For Cloudflare Access, include only the zones Wodby may publish under Zone Resources. Add both mode-specific groups if the integration will be used for both cases.

2. Create the Wodby integration

1. Open Integrations in the Wodby dashboard and select New integration.
2. Choose Cloudflare, then select the Application Access type.
3. Enter the Account ID and API token.
4. Create the integration and review any permission notices for a mode you may want to use later.

Case 1: Protect a public hostname with Cloudflare Access

Use this path when users should reach the app from any browser after signing in through your identity provider. The hostname is publicly resolvable, but Cloudflare Access denies requests that do not match the selected policy.

Prepare Cloudflare

1. Make sure the intended DNS zone is active in the same Cloudflare account.
2. Open Zero Trust → Access controls → Policies and create a reusable Allow policy. This policy decides which identities and device conditions may enter.

Configure Wodby

During new app creation, configure Access in Step 4, App settings. For an existing app instance, open Settings → Access. Then:

1. Set the top-level Access mode to Protected.
2. Select the Cloudflare Application Access integration.
3. Set Access type to Protected.
4. Choose Entire app or Selected endpoints.
5. Select the DNS zone and reusable Access policy.
6. Choose a hostname structure and confirm the suggested primary hostname, or replace it with another hostname in the selected zone.

Flattened is the safe default. Before using Hierarchical, create an active Advanced Certificate covering the exact primary hostname and its wildcard children. Wodby does not create, inspect, or renew that certificate.

Verify Cloudflare Access

1. Wait for the app deployment and Application Access task to complete.
2. Open the Cloudflare hostname shown in the app header or route list from a normal browser.
3. Confirm Cloudflare asks for authentication and that an allowed identity reaches the app while a denied identity does not.

Case 2: Keep the app on a Cloudflare private network

Use this path when the app should not have a public entry point at all. Users must connect their device to your Cloudflare Zero Trust organization before they can reach the app.

Prepare Cloudflare One devices

1. Enroll every authorized device in the Cloudflare One Client.
2. In Traffic policies → Traffic settings, enable Allow Secure Web Gateway to proxy traffic and select both TCP and UDP. TCP carries the HTTPS connection to the app. UDP is required for the private DNS query that resolves the hostname through the managed Tunnel connector.
3. Make sure 100.80.0.0/16 and 2606:4700:0cf1:4000::/64 route through WARP. In Exclude mode, remove the broader 100.64.0.0/10 exclusion. You can add back exclusions for unused CGNAT ranges, but 100.80.0.0/16 must continue to route through WARP. In Include mode, add both required ranges.
4. Check Local Domain Fallback. The suffix used by your Wodby technical hostnames must not be sent to a local DNS resolver; Cloudflare Gateway needs to answer DNS for the private hostname route.

See Cloudflare's private-hostname device connectivity guide for the current Zero Trust dashboard steps.

Configure Wodby

1. Set the top-level Access mode to Protected.
2. Select the Cloudflare Application Access integration.
3. Set Access type to Private network.
4. Choose Entire app or Selected endpoints.

This case does not ask for a DNS zone, Access policy, hostname structure, or primary hostname. Wodby reuses each selected endpoint's stable technical hostname and managed HTTPS certificate, creates a private hostname route, and keeps the matching public route disabled.

Verify private network access

1. Wait for the app deployment and Application Access task to complete.
2. Connect an enrolled device to Cloudflare One.
3. Open the Cloudflare-marked effective URL shown by Wodby in the app header or route list.
4. Disconnect Cloudflare One and confirm the same URL can no longer reach the app.

The technical hostname is not a secret and may still resolve outside WARP. Privacy comes from Wodby suppressing its public route and Cloudflare routing enrolled-device traffic through the private hostname route.

Choose the access scope

HTTP endpoints and published ports

Application Access covers HTTP endpoints. It does not place arbitrary TCP or UDP ports behind Cloudflare Access or the private hostname route.

• Entire app scope requires public TCP and UDP ports to be unpublished.
• Selected endpoints scope can leave other ports published, but those ports remain public and outside Application Access.
• Database ports and other unpublished internal ports remain available only inside the Kubernetes network.

Troubleshooting

• Cloudflare Access does not ask for a login: check that the selected Allow policy is attached to the managed application and that the hostname is proxied through Cloudflare.
• The Protected hostname has a TLS error: use Flattened hostnames or confirm the required Advanced Certificate for a Hierarchical hostname is active.
• The private hostname does not open: confirm the device is enrolled and connected, TCP and UDP proxying are enabled, and both private-hostname IP ranges go through WARP.
• Private DNS returns the public destination: review Local Domain Fallback and DNS policies that may capture the Wodby technical hostname before Cloudflare Gateway.
• App creation reports a missing permission: add the permission group for the selected access type and check that the token includes the selected account and zone.
• Access shows an error: open the Access task from the app state indicator and review the provider or connector step that failed.

Changing or removing access

Update the scope or selected endpoints from Settings → Access. To switch between Cloudflare Access and Private network, remove Access and enable it again with the other type. Wodby finishes cleanup before it creates the replacement provider resources.

Removing Access restores the matching ordinary public routes. Deleting the app removes its connector, provider routes, managed DNS records, Tunnel, and managed Access application as applicable. Cloudflare zones, reusable Access policies, certificates, device enrollment, WARP settings, and Gateway policies remain in your account.

For the product overview, see Application Access. For the complete provider contract and cleanup behavior, see the Cloudflare provider documentation and Application Access documentation.