> For the complete documentation index, see [llms.txt](https://docs.emseapea.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.emseapea.ai/setting-up-your-accounts/cloudflare-for-the-gateway.md).

# Cloudflare, for the gateway we include

Emseapea includes a small gateway so that an organization without one of its own still gets the thing that makes all of this work: your apps hold a revocable handle and nothing else, and your vendor credentials sit somewhere the apps cannot read.

The intended arrangement is that **you supply Cloudflare credentials and we deploy that gateway into your own Cloudflare account**, beside your apps, where your security team can see it and switch it off.

**That is not what happens today.** Read the next section before you create anything.

## Where your gateway actually runs today

> **Today your organization's gateway is deployed into Emseapea's Cloudflare account, not yours.** There is nowhere in the product to enter a Cloudflare account for it, and nothing asks you for one.

Concretely, as things stand:

* The gateway Worker is created on a Cloudflare account Emseapea controls, and given a hostname under `emseapea.ai`. Your organization gets its own Worker and its own hostname — no two organizations share one — but the account underneath is ours.
* If you define a Cloudflare R2 storage class, **the bucket is created in that same account**, by the same credentials. See [Somewhere to keep files and data](/setting-up-your-accounts/somewhere-to-keep-files-and-data.md).
* Your vendor secrets still never go into Emseapea's database. They are set as secrets on the gateway Worker. But that Worker is running in our account, so **today your apps' calls to your vendors do pass through infrastructure we operate.** If you have read elsewhere in this documentation that corporate data never transits Emseapea's infrastructure, that sentence describes where this is going and not where it is now.

**Status: not built yet.** This is a gap in the product, not a missing permission, and no Cloudflare credential you create will move it. It is recorded as an open piece of work; when it lands, the rest of this page is what you will be asked for.

## What you can supply today, and what it is for

One Cloudflare credential is genuinely per-organization already: the one your **approved apps** are deployed with.

> If you leave this blank, your approved apps are deployed into Emseapea's Cloudflare account as well. Supplying your own is the difference between your apps running in your tenancy and running in ours.

**Where it goes:** Settings → Deployments → Cloudflare Workers. See [Configuring deployment targets](/admin-guide/deployment-targets.md).

**Status: working today.** Cloudflare Workers is the one deployment target a real governed app has actually been deployed to.

### 1. Find your account ID

1. Sign in at [dash.cloudflare.com](https://dash.cloudflare.com) with an account that administers the Cloudflare account you want apps to run in.
2. Open **Workers & Pages**. The **Account ID** is shown in the right-hand column, and is also the long hex string in the page's own address.
3. Copy it.

**You now have:** a 32-character account ID. It is an identifier, not a secret, but it is worth pasting somewhere before you go on.

### 2. Create a scoped API token

Do **not** use a Global API Key, and do not reuse a token you created for something else — you want to be able to revoke this one on its own.

1. In the Cloudflare dashboard, open **My Profile → API Tokens → Create Token → Create Custom Token**.
2. Name it something a colleague will recognize in a year — `emseapea-deploy` is fine.
3. Under **Permissions**, add:

   | Type    | Permission          | Level    | Why                                      |
   | ------- | ------------------- | -------- | ---------------------------------------- |
   | Account | **Workers Scripts** | **Edit** | To put your approved apps on the account |
4. Under **Account Resources**, restrict it to the **one** account from step 1 — not "all accounts".
5. Set a TTL if your policy requires credential expiry, and note the date; nothing in Emseapea will warn you when it lapses.
6. **Continue to summary → Create Token**, and copy the token. Cloudflare shows it **once**.

**You now have:** an account ID and an API token that can create and update Workers on one account and can do nothing else.

### 3. Put it into Emseapea

**Settings → Deployments → Cloudflare Workers**, then **Test connection**.

Test connection here makes real calls — it verifies the token and then lists the account's Workers scripts — so it tells apart a revoked token, a token with the wrong permissions, and a wrong account ID rather than collapsing them into one failure.

## What you will be asked for once the gateway moves to your account

This section describes work that has not shipped. It is here so you can get the approvals you will need started, not so you can configure it today.

You will be asked for the same two things — an account ID and an API token — but the token will need more than `Workers Scripts: Edit`, because the gateway does more than run code:

| Type    | Permission                         | Level    | Why it is needed                                                        |
| ------- | ---------------------------------- | -------- | ----------------------------------------------------------------------- |
| Account | **Workers Scripts**                | **Edit** | To deploy your gateway Worker, and to update it when you add a system   |
| Account | **Workers R2 Storage**             | **Edit** | To create your organization's shared file store, if you use one         |
| Account | **API Tokens**                     | **Edit** | To mint the key that reaches only that one file store, and nothing else |
| Zone    | **Zone** (read) and Workers routes | —        | To attach your gateway to a hostname on a domain you own                |

The product already says the middle two out loud when it hits them:

> The token needs "Workers R2 Storage: Edit" to create the file store, and "API Tokens: Edit" to create the key that reaches only that one store.

**You will not need DNS-editing permission.** Attaching a Worker to a custom domain creates the record and the certificate as part of that operation, so the token can be narrower than you might expect.

**And you will need a zone** — a domain already on Cloudflare — for the gateway's hostname, because your approved apps have to be able to reach it by name.

### What is unproven even once you supply it

**The file store half has never been proven against any Cloudflare account, yours or ours.** Nobody has yet confirmed that the token Emseapea uses today actually carries `Workers R2 Storage: Edit` and `API Tokens: Edit`, and **no governed app has ever written a real file through a real gateway.** Buckets have been created and deleted by hand, and an object written and read back — but not through the product, and not by an app.

Treat the file store as **built, but never used against a real account**, and expect to be the first organization to find out. The [storage page](/setting-up-your-accounts/somewhere-to-keep-files-and-data.md) says what to watch for.

## Where to go next

* [Somewhere to keep files and data](/setting-up-your-accounts/somewhere-to-keep-files-and-data.md) — the R2 file store this account also creates.
* [Configuring deployment targets](/admin-guide/deployment-targets.md) — the screen the token from step 2 goes into.
* [Integrations: GitHub, Linear, gateway](/admin-guide/integrations.md) — the rest of what your gateway does once it is running.