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
The console at http://console.ermahgerd.localhost:8081 is the normal interface for managing organizations, members, API tokens, Worker inventory, version history, and organization audit activity. The bootstrap local user is:
owner@localhost / local-owner-passwordThat user also has the separate platform operator role, which enables
platform readiness, customer records, invitations, and organization support
views in the separate administrator portal at http://admin.ermahgerd.localhost:8082. Sign in there
independently; the tenant session never grants platform privileges.
Organization roles never imply platform-wide access.
Account signup is invitation-only. An accepted customer invitation grants the account permission to create organizations; accepting a team invitation only joins the named organization. An invited customer may own up to three organizations, and new organizations begin on the Free usage tier. See Invite and manage customers for the complete workflow.
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.
Platform operator can read platform health and suspend, reactivate, delete, or
support an organization. Organization creation belongs to customer-invited tenant
users; operators issue invitations but do not create organizations on their behalf.
Platform viewer is the read-only platform role reserved for later operator
accounts; the current UI/API does not offer platform-role mutation.
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.
The bootstrap token local-development-token is a deliberately local-only
convenience. Do not reuse it outside this appliance.
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>.workers.ermahgerd.localhostTwo organizations may each deploy a Worker named sum; they remain separate
because the organization namespace is part of the host. Use make tenant-check
to verify that behavior against a running appliance.
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.
Run make service-binding-check to deploy and invoke the included example.
API integration
Human administration uses a short-lived session obtained from the identity service. The API is intended for the console and local automation:
session=$(curl -sS http://127.0.0.1:9080/v1/sessions \
-H 'content-type: application/json' \
-d '{"email":"owner@localhost","password":"local-owner-password"}' | jq -r .token)
curl -sS http://127.0.0.1:9080/v1/organizations \
-H "authorization: Bearer $session"The identity API owns authorization decisions; the deployment control plane delegates account-scoped authorization to it rather than maintaining a second role implementation. Its service-authenticated authorization endpoint is private to platform services and not a public integration surface.
Application-level protection is a separate adjacent service built on this identity authority. See Protect applications with Access for browser login, reusable groups and policies, and service-to-service credentials.