Sign in through Cloudflare Access

On by default: setup puts it in front of your Gateway once your owner account exists, and pnpm everyapp access off takes it off. Your Gateway already has its own sign-in, and while EveryApp is alpha we strongly recommend a second one in front of it. Cloudflare Access is that second door, at Cloudflare's edge, from a company that does nothing else: nobody reaches the Gateway or its apps until Access has checked who they are, with their Cloudflare account, a one-time code emailed to them, or your company's identity provider. A bug in the Gateway's sign-in pages then needs someone Access already let in, and a stolen session cookie gets nothing on its own. It takes one command and uses Cloudflare's free Zero Trust plan, which covers 50 people.

Turn it onCopy Anchor Link

pnpm everyapp setup asks Put Cloudflare Access in front of your Gateway? once your owner account exists, and Enter says Yes; in a script, or run by an agent, it goes on without asking when it can (your account has a Zero Trust team and your Cloudflare login is an owner or admin), and otherwise says why. If you said No then, passed --no-access, or setup couldn't, run this in your every-app folder:

pnpm everyapp access on

If your Cloudflare account has no Zero Trust team yet, the terminal asks for a team name. People will sign in at <name>.cloudflareaccess.com, and the name can't be changed later, so pick something like your company's name. Nothing else is needed: the command creates the team itself, with no plan to pick or payment details to enter.

The command then sets everything up and says what it did:

Zero Trust team acme.cloudflareaccess.com ✓ created · sign-in with a Cloudflare account or a one-time PIN
Sign in with Cloudflare ✓ added: members of this Cloudflare account sign in with their Cloudflare account
One-time PIN sign-in ✓ added: Access emails everyone else a code
Access policy "Every App gateway members" ✓ lets in ben@acme.com and jo@acme.com
Access in front of apps.acme.com ✓ created · MCP, the OAuth endpoints and /health let through
Access in front of *.apps.acme.com ✓ created · public routes of 1 app let through
Gateway settings ✓ CLOUDFLARE_ACCESS_TEAM_DOMAIN, CLOUDFLARE_ACCESS_APPS_AUD, CLOUDFLARE_ACCESS_AUD · one new version

Sign in  https://apps.acme.com
         ben@acme.com and jo@acme.com sign in once with their own password; Access asks them to sign in first, with their Cloudflare account if they are a member of this Cloudflare account, otherwise with a code emailed to them. After that Access alone signs them in.

Everyone who is a member, or has a pending invitation, is let in. Anything your apps make public, like a tracking script or a webhook, stays reachable without a login, and so do AI apps connected to your Gateway.

The first sign-inCopy Anchor Link

The first time, each person opens the Gateway and Access asks them to sign in: Sign in with Cloudflare if they are a member of your Cloudflare account (it signs them in as that account's email address), otherwise they type their email and get a code. Then they sign in with their Gateway password as usual. That links the two, and from then on Access alone signs them in. People you invite later never need a password.

Create your owner account and invite people with the email addresses Access will see: the ones your Cloudflare account, your company login or the emailed code uses. An account under a different address can't sign in behind Access. If your Cloudflare account's address isn't your Gateway address, access on says so: sign in with the code emailed to your Gateway address, or invite the Cloudflare one.

Once everyone has done that, you can turn passwords off:

pnpm everyapp secret set EMAIL_PASSWORD_SIGN_IN

Enter false: Gateway settings like this one are set with the same command as secrets, and the prompt says what each takes. Nothing changes until an owner has signed in through Access, so it can't lock you out.

When you invite someoneCopy Anchor Link

Run pnpm everyapp access on again after inviting someone, so Access lets them in too. Nobody is ever removed from Access this way: to take someone off, deactivate them in the Gateway, which signs them out everywhere at once.

To let everyone with an email at your company through Access, run it with your domain:

pnpm everyapp access on --email-domain acme.com

They still need an invitation to get an account, unless you also let people at that domain join on their first sign-in: pnpm everyapp secret set CLOUDFLARE_ACCESS_AUTO_JOIN_DOMAINS, and enter the domain.

Check it, or turn it offCopy Anchor Link

pnpm everyapp access show
pnpm everyapp access off

show lists the team, its sign-in methods, who is let in and whether everything is in step; pnpm everyapp status says the same in one line (Access on · in step with this Gateway, or what drifted). off asks first, then takes Access off: passwords sign people in again at once. The team and its settings stay in your Cloudflare account.

Good to knowCopy Anchor Link

• Deploying an app keeps its public routes reachable: pnpm run deploy tells Access about them. The Gateway's /health stays reachable too, for an uptime monitor. Updating the Gateway (pnpm everyapp update) keeps Access in step with the new version by itself; if that ever fails it says so and names pnpm everyapp access on.
• Sign in with Cloudflare is restricted to the members of your Cloudflare account; access on and show warn if that restriction is ever turned off in the Zero Trust dashboard (and leave the provider off until it is back on). Any other sign-in method on your Zero Trust team, your company login say, is yours to allow on the two EveryApp applications in the dashboard: access on adds only these two, and never removes one.
• Your Gateway's own sign-in page can also offer Continue with Google, Microsoft, GitHub, Apple, Cloudflare or your SSO, with Access on or off. Sign in with Google and others
• An Access sign-in lasts 30 days by default. For a daily code, run pnpm everyapp access on --session 24h.