Can built-in Gatekeepers be enabled with the official one-click deployment?

[Tmeister]

Hi,

When deploying Cloudflare OS through the official Deploy to your Cloudflare account flow, can we enable built-in Gatekeepers such as:

• Google
• Slack
• etc

If yes, how should they be enabled and configured?

I haven’t been able to find documentation covering this specific setup. Any guidance would be appreciated.

Thanks!

[Ashutosh0x]

The built-in gatekeepers (GitHub, Google, Slack, etc.) are included in the source tree under packages/gatekeeper-*, but the one-click "Deploy to Cloudflare" flow only provisions the core infrastructure (router, workshop backend/frontend, MCP shared). The gatekeepers require per-tenant OAuth client credentials (client ID + secret) that you register with each upstream provider (Google Cloud Console, GitHub OAuth Apps, etc.).

To enable a gatekeeper after deploying:

1. Register an OAuth app with the upstream provider (e.g., Google Cloud Console for Google, GitHub Developer Settings for GitHub)
2. Set the redirect URI to your deployment's callback URL (pattern: https://<your-domain>/oauth/<provider>/callback)
3. Add the client credentials as Wrangler secrets:

   wrangler secret put GOOGLE_CLIENT_ID
   wrangler secret put GOOGLE_CLIENT_SECRET

4. The gatekeeper's Durable Object binding in wrangler.jsonc handles the rest ? the router dispatches to the correct gatekeeper class based on the resource URL pattern

The wrangler.jsonc at the repo root already declares all the DO bindings; they just need the secrets populated. Each gatekeeper's src/*.ts file documents the expected environment bindings near the top.

One caveat: if you're self-hosting with workerd rather than Cloudflare Workers, you'll need to configure the equivalent secrets in your local wrangler.toml or environment variables.

[Dotoryman]

An update for the current deployment flow: the installable Gatekeepers are now represented in the release manifest, and the deploy wizard can collect their per-provider inputs. You do not need to manually add Durable Object bindings to a root wrangler.jsonc.

For Google and Slack, the required inputs are CLIENT_ID and CLIENT_SECRET; the deploy service supplies those to the corresponding Gatekeeper Worker as secret bindings. The repository's deployment descriptors are the most reliable source for the callback URLs:

• Google: {PUBLIC_BASE_URL}/gatekeeper/google/oauth (deploy inputs)
• Slack: {PUBLIC_BASE_URL}/gatekeeper/slack/oauth (deploy inputs)
• GitHub follows the same shape: {PUBLIC_BASE_URL}/gatekeeper/github/oauth (deploy inputs)

So the callback is not /oauth/<provider>/callback; it is under /gatekeeper/<provider>/oauth on the public instance URL.

For Google, create a Web application OAuth client, enable the APIs you intend to connect, configure the consent screen, and add your account as a test user while the app remains in Testing mode. For Slack, create the Slack app, register the callback above, add the documented user-token scopes, and enable token rotation. Then provide the two credentials when installing that Gatekeeper through the deployment UI.

One distinction that can otherwise be confusing: installing the Google Gatekeeper makes Google resources available for connections; showing Continue with Google on the Cloudflare OS login screen additionally requires google in the backend's AUTH_GATEKEEPERS allowlist. The Google package README documents both roles and the setup details: https://github.com/cloudflare/cloudflare-os/tree/bdc5c85daf5e9c7fc80799c3fe042cd38e25add0/packages/gatekeeper-google

For a deployment that needs deeper customization than the hosted flow exposes, the project now points to cloudflare-os-starter as the supported starting point.