Skip to main content
Protect the Workspaces browser app origin with Cloudflare Access. Leave the API and usercontent origins public. Workspaces checks the Access assertion and adds each person who signs in to the instance organization as a member.

​
Before you start

You need three custom domains in a Cloudflare zone:
  • an app domain for the browser app and live editing;
  • an API domain for API-key requests, MCP, and read-only Git; and
  • a usercontent domain for raw file bytes.
You can test the deployment at the default workers.dev address, but supported Access login requires a custom domain. Use Deploy Workspaces on Your Cloudflare Account for the shared resources and two-Worker setup. Complete the Access steps below before the final app Worker deploy.

​
Create the Access application

1

Add a self-hosted application

In Cloudflare Zero Trust, open Access > Applications. Add a Self-hosted application for the app domain.
2

Add an allow policy

Choose the people who may sign in. Use your identity-provider groups, email domain, or an explicit list.
3

Copy the team domain

In Zero Trust settings, find the team domain. Set CLOUDFLARE_ACCESS_TEAM_DOMAIN in the app Worker config to its full HTTPS address.
4

Copy the application audience

Open the Access application’s overview and copy its Application Audience (AUD) tag. Set CLOUDFLARE_ACCESS_AUDIENCE in the app Worker config to that value.
5

Set the instance organization

Set one stable SELF_HOST_ORG_ID and the displayed SELF_HOST_ORG_NAME. Cloudflare Access does not assign Workspaces roles. Every signed-in person becomes a member.
6

Deploy the app config

Deploy or redeploy the app Worker after you change its config. The usercontent Worker does not need the Access values.
Do not create an Access application for the API domain. Tools and agents use a Workspaces API key on that public origin. The app Worker checks the bearer key before it checks for an Access assertion. Do not create an Access application for the usercontent domain. The usercontent Worker has no browser session or app cookie. A living raw URL works only while the workspace uses an open sharing setting. Anyone with a complete version-pinned raw URL can read that stored version until the workspace is deleted. Putting the raw origin behind Access requires recipients and tools to sign in. It also breaks Copy raw link.

​
Verify human sign-in

1

Open the app domain

Use a private browser window so an existing Access session does not skip the sign-in test. Cloudflare should show the Access sign-in screen.
2

Sign in

Sign in with an account allowed by the policy. Cloudflare should return the browser to Workspaces.
3

Check the Workspaces account

Open Settings > Account. Confirm the expected email under Signed in as.
4

Create and revoke an API key

Open Settings > API keys and create a test key. Use it for one request to the public API origin, revoke it, and confirm the next request fails with 401 unauthorized.
Cloudflare Access manages the browser session. Workspaces does not create its own login cookie in this mode. Sign out opens Cloudflare’s logout address.

​
Fix common Access failures

Disabling a person’s Access login does not revoke an existing Workspaces API key. The key owner must revoke it before you remove their sign-in access. Reviewed July 21, 2026. Maintained by the Plannotator documentation team.
Last modified on July 24, 2026