LeadMax deploys through Cloudflare's OAuth: you authorize LeadMax on Cloudflare's own consent screen, Cloudflare gives us a token limited to the permissions you approved, and every deploy uses that token on your behalf. You never paste an API key into LeadMax.
Where to connect
- Settings → Cloudflare connection → Connect Cloudflare. This is the usual path for accounts created with an email address or GitHub.
- Sign in with Cloudflare at sign-up, where it is offered. The same authorization then serves both sign-in and deploys.
The Cloudflare email does not have to match your LeadMax email. If you belong to several Cloudflare accounts, the consent screen lets you grant one or more of them; LeadMax lists every account you granted and uses the first as the default deploy target. Change it with Use for deploys.
What LeadMax asks for
Permissions are Cloudflare API token scopes, shown by name on the consent screen. LeadMax requests the smallest set a deploy needs plus a few optional ones you can untick:
Required
| Scope | Why |
|---|---|
user-details.read | Read who you are at sign-in (Cloudflare's identity endpoint only returns an id). |
account-settings.read | Read the names of the accounts you granted, so you can pick the one to deploy to. |
workers-scripts.write | Upload the Worker and its static assets, manage versions, turn on the workers.dev URL. |
workers-kv-storage.write | Create the KV namespace the framework uses as a data cache. |
d1.write | Create the project's D1 database and apply its migrations. |
Optional
| Scope | Why |
|---|---|
workers-routes.write | Reserved for custom domains on your zones (not available yet). |
zone.read | Reserved for listing your zones when choosing a custom domain (not available yet). |
openid and offline_access are protocol scopes Cloudflare adds itself: the first identifies you, the second lets LeadMax refresh the token without asking you to sign in again. A scope you declined is simply missing from the token; Settings shows each account's granted, missing and declined scopes, and a deploy that needs a missing scope stops with a clear message instead of failing half-way.
How your token is handled
- Stored encrypted at rest with the platform secret; only our Workers can read it.
- Refreshed server-side before it expires. If Cloudflare refuses a refresh, the connection is marked as needing re-authorization.
- Never sent to your browser, and never visible to the build of your project: the build runner injects it only into requests to Cloudflare's API, so nothing in your project's dependencies can read it.
- Used for exactly the operations listed above, on the account you chose.
"Needs re-authorization"
A connection shows this state when the token can no longer be refreshed. Usual causes:
- You revoked LeadMax from your Cloudflare dashboard.
- The refresh token was invalidated (Cloudflare invalidates the whole chain if a refresh token is reused).
- You lost access to the Cloudflare account.
Choose Re-authorize / grant more in Settings to run the consent flow again. The same button is how you add an optional scope you declined earlier, or grant another Cloudflare account. Refresh accounts re-reads the list of accounts and their workers.dev subdomains without a new authorization.
Disconnecting
Disconnect in Settings deletes the token on our side and unlinks the Cloudflare identity from your LeadMax account. Apps already deployed keep running on your account; only new deploys need a fresh authorization. To revoke the grant on Cloudflare's side as well, remove LeadMax from the authorized applications in your Cloudflare dashboard.
Nothing is deleted on your account
Disconnecting, deleting a project or deleting your LeadMax account never removes a Worker, database, namespace or bucket from your Cloudflare account. See What gets created on your account for how to clean up yourself.