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 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.
Worker hostnames
An organization receives an immutable, DNS-safe namespace. Its Worker routes use a subdomain rather than a path:
<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-OrganizationX-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 for application code.
Application access
Organization tokens authorize platform resource operations. S3 credentials authorize storage requests. Application login is another boundary: configure Application Access when a Worker hostname needs browser login or scoped service credentials.