Enterprise overview
The Community Edition (edssa-server-ce) ships under BSL 1.1 with
a strict feature subset documented in
CE feature subset. Everything held back
from CE lives in the Enterprise build of edssa-proxy + the
operator panel + the sibling crates edssa-tenant, edssa-sso.
What’s in Enterprise
| Capability | CE | Enterprise |
|---|---|---|
| Token widths | 64 only | 32 / 64 / 128 / 256 |
| Fleet count | 1 per process | unbounded |
| Multi-tenant hierarchy (Tenant / Organization / Fleet) | — | ✓ (Multi-tenant) |
| Per-tenant audit isolation (cryptographic + filesystem + RBAC) | — | ✓ |
| SAML / OIDC SSO | — | ✓ (SSO) |
| Per-fleet + per-source-IP + per-(fleet, sub-ID) rate limiting | — | ✓ (Production hardening) |
| Tier-3 trace + Tier-4 Merkle audit | — | ✓ |
| F-03 swarm, F-04 relay roles | — | ✓ |
| F-06 EdSSA Orbit (orbit-coupled state advancement) | — | ✓ |
| F-16 drift corrector | — | ✓ |
| F-19 response-ID chain (Tier-3 replay) | — | ✓ |
| F-22 schema-derived bytes | — | ✓ |
| Hot-publish state mutation (Phase-2 ratchet) | — | ✓ |
| Cooperative recovery (F-24/F-25) | — | ✓ |
| ML-KEM onboarding (F-07) | — | ✓ |
| Payload channel (F-26/F-27/F-28) | — | ✓ |
| WebAuthn / SSO panel auth | — | ✓ |
Binary + crate layout
edssa-proxy— the Enterprise verifier. Same crate as the CE-substrate proxy, but built withdefault-featuresonedssa-core(theenterprisecargo umbrella) + the manifest’s Enterprise-shaped fields enabled.edssa-panel— the Enterprise operator panel. WebAuthn auth/tenants+/sso/*routes + the per-fleet plasticity / audit-tier / rate-limit edit flows.
edssa-tenant— multi-tenant hierarchy types (Tenant,Organization,FleetRef,TenantStoretrait). Consumed byedssa-panel(RBAC, UI) +edssa-audit(per-tenant Merkle scope).edssa-sso— SSO provider abstraction (AuthProvidertrait,AuthProviderRegistry, flow types). Concretesamaelopenidconnectimpls land behind cargo features in customer-driven follow-up batches.
edssa-admin— operator CLI for on-box inspection (manifest dump, trigger registry, fleet detail, handshake apply).
Architectural calls worth knowing
- CE / Enterprise share the engine.
edssa-core’s hot path (verify_token,EdssaCore,EdssaRouter) is identical between the two builds — the differences are in which modules link in (theenterprisecargo feature gatesrelay,swarm,oracle,weaver,drift::MedianOf3) and which manifest fields are accepted at boot. - The validation gate is the load-bearing boundary, not the
feature flag. CE’s
edssa-server-cevalidates incoming manifests at boot and rejects Enterprise-shaped fields with a clear error message + docs pointer; the feature flag is defence-in-depth (no Enterprise symbols are compiled into the CE binary either). Operators upgrading from CE to Enterprise change the binary, not the manifest format. - The same wire format works in both builds. CE clients + Enterprise clients are bit-for-bit interchangeable; the only difference is what the verifier does with the token after authenticating it (multi-fleet routing, per-tenant audit, rate-limit enforcement, Tier-3 response chain, etc).
Where to next
- New to multi-tenant operations? Start with Multi-tenant.
- Integrating SAML / OIDC for the operator panel? See SSO.
- Tuning rate limits + observability? See Production hardening.
- General operator concerns (deployment, seed rotation, observability surface) are still in the CE Operator runbook — most of it applies to Enterprise unchanged.