Deploy to Cloudflare
Run your own gateway on your Cloudflare account. Deploy a GitHub fork from the Cloudflare form, then register with your email.
For the simplest terminal setup, install @maxceem/agw and run
agw deployment setup --name my-gateway --no-domain. It creates the resources,
saves its recovery journal and connects the new gateway. See CLI.
The button below is an alternative for a deployment maintained through a GitHub fork.
Setup acts on your Cloudflare account through Wrangler, and reuses whatever
Wrangler is already authorized with: an earlier wrangler login, or
CLOUDFLARE_API_TOKEN in the environment. It opens a browser only when it finds
neither. Setting CLOUDFLARE_API_TOKEN is what keeps a browser out of it; add
--no-input so nothing else prompts either, and supply the values it would
have asked for.
The first deployment command downloads the gateway build belonging to that CLI
version: one archive, published with the project's GitHub release. It is checked
against a SHA-256 built into the CLI before anything is unpacked, and kept under
$XDG_CACHE_HOME/agw (~/.cache/agw, or %LOCALAPPDATA%\agw on Windows), so
later commands reuse it. An archive that does not match that hash is refused.
On a machine with no route to GitHub, download gateway-<version>.tar.gz from
the release matching agw --version elsewhere, copy it over, and name it:
agw deployment setup --name my-gateway --no-domain \
--release-archive "./gateway-$(agw --version).tar.gz"The same hash is checked, so a file that travelled by hand is trusted no further
than one that arrived over the network. AGW_RELEASE_ARCHIVE sets the same path
for every deployment command.
Prepare the deployment values
Generate a vault key with openssl rand -base64 32 and save it privately.
The deployment ID is generated automatically.
Back up the vault key
Losing SECRET_VAULT_LOCAL_KEK_V1 makes stored provider credentials unreadable.
Keep it in a password manager or another protected backup.
Deploy your fork
The form creates your fork and Worker and connects later pushes to Workers Builds. Fill in these values:
| Field | Value |
|---|---|
SECRET_VAULT_LOCAL_KEK_V1 | Your private vault key. |
SECRET_VAULT_MODE | local |
SECRET_VAULT_LOCAL_KEK_CURRENT_VERSION | 1 |
ALLOWED_REGISTRATION_EMAILS | Your email address. Add more, separated by commas, for anyone else who should have an account of their own. |
The deploy script generates the deployment ID and internal signing secrets once, applies migrations and deploys the console and Worker. Later builds read and reuse the deployed ID, including after a custom-domain change. You do not need to generate it or add it to the build environment. If the script cannot read the existing deployment, it stops rather than risking a change to its identity.
Check https://YOUR-WORKER.workers.dev/v1/healthz and confirm "vault":"ok".
The generated deployment ID is available at /v1/cli/capabilities.
Register
Open https://YOUR-WORKER.workers.dev and create your sign-in with the email
you listed in ALLOWED_REGISTRATION_EMAILS. It gets an account of its own; an
address that is not listed cannot register. To let someone else in later, add
their email to the variable in the Worker's settings. See
ALLOWED_REGISTRATION_EMAILS.
Follow Quickstart to add a provider and an app, or Custom domain and rate limiting to add a hostname.