> 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/accounts.md).

# What you will need, and what is not ready

Before anybody in your organization can request an app, somebody has to go and create accounts and credentials in other companies' consoles — Cloudflare, Microsoft, Salesforce, Google, and wherever your apps will keep their files. Nothing in Emseapea can do that for you, and until it is done most of the screens in the [Admin guide](/admin-guide/getting-started.md) have nothing to act on.

This section is the list. Four groups, in the order most organizations need them:

1. [**The gateway we include**](/setting-up-your-accounts/cloudflare-for-the-gateway.md) — Cloudflare.
2. [**Somewhere to deploy apps**](/setting-up-your-accounts/somewhere-to-deploy-apps.md) — AWS and Azure.
3. [**Somewhere to keep files and data**](/setting-up-your-accounts/somewhere-to-keep-files-and-data.md) — the storage providers.
4. [**Systems your apps can reach**](/setting-up-your-accounts/systems-apps-can-reach.md) — Salesforce, Google Workspace, Microsoft.

Each page tells you what to create, in which console, which permissions it needs, what you end up holding, and where in Emseapea it goes.

## Machine credentials only — never a personal login

Every credential on every page below belongs to **a thing, not a person**: a service account, an application user, an integration user, an app registration, a scoped API token. Never your own sign-in, and never a colleague's.

This is not a formality. A personal login carries whatever that person happens to be able to see, which is almost never the access you meant to grant; it stops working the day they change role or leave; and every action a governed app takes is then attributed to them in your vendor's own audit trail, which is exactly the question you will be trying to answer six months later.

Where a vendor makes this awkward — Salesforce asks you to pick a **Run As** user, for instance — create a dedicated user for it rather than nominating somebody real.

## Read the honesty labels before you spend an afternoon

Emseapea is a young product and several of the places you can enter a credential do not yet do anything with it. Rather than leave you to find that out at four o'clock on a Friday, every item in this section carries one of three labels:

| Label                                            | What it means                                                                                                                           |
| ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------- |
| **Working today**                                | A real account of this kind has actually been reached, and it worked. The date is given.                                                |
| **Built, but never used against a real account** | The code is written and tested, and nothing has ever been sent to the real vendor. It may well work. Nobody has watched it work.        |
| **Not built yet**                                | There is a place to enter this and nothing reads it. No credential and no permission will change that — it is missing work on our side. |

Two things follow from that, and they are worth saying plainly:

* **A credential you supply cannot make something in the third row work.** Where a page says "not built yet", the gap is ours, and giving us more access closes none of it.
* **"Built, but never used against a real account" is not a warning to stay away.** It is an invitation to be the first, with somebody around who can look at logs. It is not a state to discover in production.

## What Emseapea keeps, and what goes to your gateway

Two different things, and it matters which is which:

* **Vendor secrets** — a Salesforce consumer secret, an Entra client secret, a Google service-account key — are **never stored by Emseapea**. You type them once on **Settings → Gateway** and they go straight onto your gateway as Worker secrets. Emseapea keeps the non-secret half (the client ID, the web address, the token address) so it can show you what is configured.
* **A deploy target's credential** and **a database connection string** have to survive long after you last opened the page, so Emseapea does store them. Deploy-target credentials sit in a separate table nothing but the deploy step reads from, and are [not encrypted at rest today](/admin-guide/deployment-targets.md#honest-about-what-this-doesnt-guarantee). Database connection strings are encrypted.

## Where to go next

Start with [Cloudflare](/setting-up-your-accounts/cloudflare-for-the-gateway.md) — it is the one account that everything else leans on — then work down the list. When the accounts exist, [Getting started](/admin-guide/getting-started.md) is the fifteen minutes that turns them into a working organization.