---
title: "Organizations and access"
---

> Documentation Index
> Fetch the complete documentation index at: https://ermahgerd-docs.t-bd7662a5eeb4.workers.ermahgerd.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Organizations and access

Organizations are the tenant boundary. An organization owns Workers, buckets,
databases, queues, key-value namespaces, Images use, AI provider connections,
vector indexes, credentials, members, protected applications, and stable Worker
and storage hostname namespaces. Its UUID is the Wrangler account ID.

## Use the console

Use the tenant console for organizations, members, API tokens, Worker inventory,
deployment history, and audit activity. Follow [Managed ermahgerd](/managed/)
for account onboarding, or use the address supplied by your installation's
operator.

Account signup is invitation-only. A customer invitation grants permission to
create organizations; a team invitation only joins the named organization.
An invited customer may own up to three organizations. New organizations start
on Free. Organization roles never grant platform administrator access.

Organization owners can permanently close an organization from **Management →
Settings**. The platform stops dispatch before it purges Workers and artifacts,
queues, databases, key-value namespaces, object storage including old versions,
credentials, and quota state. Platform operators can instead suspend an
organization without removing data. Suspension removes published ingress routes,
rejects shared-runtime route resolution (including queue delivery), and blocks
resource mutation. Management reads remain available for diagnosis; reactivation
republishes the existing routes.

Lifecycle actions use a confirmation dialog. Deletion requires the exact
organization name and warns that all owned data will be removed. Suspension,
reactivation, and deletion do not require a written reason; identity records
the actor, action, organization, and time automatically. Tier and quota changes
also record their changes without asking for a reason.

## Organization roles

| Role     | Worker access                                            | Organization administration                     |
| -------- | -------------------------------------------------------- | ----------------------------------------------- |
| owner    | read, write, invoke; data services and Access read/write | Full access, including owner grants             |
| admin    | read, write, invoke; data services and Access read/write | Manage members, tokens, and audit records       |
| member   | read, write, invoke; data services and Access read/write | Read members; manage tokens they created        |
| observer | Worker, data-service, and Access read                    | Read members, token metadata, and audit records |

Every organization must retain an owner. Only an owner can grant the owner
role.

Owners and administrators invite organization members from **Management →
Team**. The platform returns a private, single-use link to send directly to the
invited email. Existing accounts sign in before accepting; new accounts choose
a name and password. Team invitations never grant permission to create another
organization.

## Create and use an API token

Create an organization token from the console. The token secret is returned
only once; the service persists only a SHA-256 hash. Tokens may be expired,
revoked, and scoped to selected Worker names.

Two permission presets are available:

| Preset     | Permissions                                                                         |
| ---------- | ----------------------------------------------------------------------------------- |
| read-only  | organization resources, data services, quotas, and Access read                      |
| read-write | read-only plus Worker invocation/deployment, data-service writes, and Access writes |

Use a read-write token for Wrangler deployments. Use a scoped token whenever a
build system should deploy only a named Worker.

S3 access keys are a separate credential type. They use SigV4, are scoped to
one organization, may be restricted to named buckets, and cannot deploy or
administer Workers. See [Object storage](/build/storage/).

## Worker hostnames

An organization receives an immutable, DNS-safe namespace. Its Worker routes
use a subdomain rather than a path:

```text
<worker>.<organization-namespace>.<installation-worker-domain>
```

Two organizations may each deploy a Worker named `sum`; they remain separate
because the organization namespace is part of the host. Copy its complete URL
from the Worker overview.

## Worker-to-Worker service bindings

A Wrangler service binding is an explicit capability to call one named Worker
in the same organization. The dispatcher resolves the target's active immutable
version on each call, so callers need not be redeployed after a target update.

The target receives trusted platform-managed caller identity in these headers:

* `X-Ermahgerd-Caller-Organization`
* `X-Ermahgerd-Caller-Worker`

HAProxy removes those headers, and the internal-hop header, from public
requests. Treat the values as authenticated only when they came from an actual
service-binding call. Dynamic Workers may reach public Internet addresses, but
private platform services are not reachable through global `fetch()`; service
bindings are explicit, tenant-scoped capabilities. Calls are limited to 16 hops
to bound cycles.

See the [service-binding example](https://github.com/nullbytelabs/ermahgerd/blob/main/examples/service-bindings/) for application code.

## Application access

Organization tokens authorize platform resource operations. S3 credentials
authorize storage requests. Application login is another boundary: configure
[Application Access](/build/access/) when a Worker hostname needs browser
login or scoped service credentials.

Source: https://ermahgerd-docs.t-bd7662a5eeb4.workers.ermahgerd.io/build/organizations/index.mdx