Introducing the Simmetric Chat Enterprise Plugin

Enterprise is a plugin, not a fork

The most common way open-source projects ship an enterprise tier is a fork: a private branch that drifts from the community codebase until upgrading becomes a migration project. Simmetric Chat chose the other path. The enterprise tier ships as an optional plugin package - @simmetric-chat/enterprise - loaded by the community server at boot through a plugin loader. The community server probes for the package at startup:

• Found and valid → the plugin registers its routes, and enterprise features go live.
• Not installed → an info-level log line notes the community build and the server continues unchanged.
• Found but broken → the server exits loud. A broken enterprise install never silently degrades to community - a half-working SSO stack is worse than none.

The same license governs the tier. The community codebase is AGPL-3.0; the enterprise plugin is a separately licensed commercial package, and a license JWT (LICENSE_KEY) is what unlocks the features. Without a valid license the enterprise routes still mount, but every gated feature answers 402 with an explicit JSON payload naming the feature and the tier - your integration code can branch on license state instead of guessing.

Identity: SSO and SCIM out of the box

Single sign-on supports the two protocols enterprises actually run: SAML 2.0 (with login, callback, and metadata endpoints for IdP-initiated flows) and OIDC (login and callback for the browser-redirect flow, built on a current OpenID Connect client library). Both bind to the same admin-configurable SSO panel.

Configuration is flexible where it matters. OIDC can be configured entirely from the admin SSO panel (stored encrypted at rest in the database), entirely from environment variables, or from both - env takes precedence when set, so infrastructure-as-code deployments can pin provider settings while the panel remains the source of truth otherwise. Built-in providers cover Google, GitHub, and Microsoft Entra, and a generic provider accepts any discovery document.

SCIM 2.0 closes the lifecycle loop: user and group provisioning over the standard SCIM protocol with a Bearer-token-protected endpoint. When HR offboards a user in your identity provider, their Simmetric Chat account deactivates through the same flow - no orphaned accounts, no spreadsheet-driven deprovisioning. Together, SSO and SCIM mean your IdP remains the single authority on who exists and who can log in.

The audit log that cannot be rewritten

Audit logs have an awkward property: the more valuable they are, the more valuable they are to modify. Simmetric Chat's enterprise audit log enforces immutability at the database layer, not the application layer.

A dedicated Postgres role - simmetric_audit_writer - holds only an INSERT privilege on the audit table. The enterprise plugin writes audit events through a separate connection pool that authenticates as that role, so UPDATE and DELETE fail at the database level, not by application convention. Readers take a deliberately separate path through the standard application connection, which has SELECT but is a different role entirely - the writer cannot read, and the reader cannot write.

The guarantee is honest about its own configuration: when the writer password is set, the boot log confirms the immutability guarantee is active; when it is missing, the audit log still records events but a boot warning states that database-level immutability is not enforced. Fail-safe defaults plus a truthful boot log - the pattern this platform uses everywhere.

The audit log is exposed to admins through an event-log viewer, gated by an audit_log_immutable license flag. Authentication events, document operations, settings changes, DLP bypasses, retention changes - the trail is the answer to "what actually happened," and it composes with the community RBAC story: access to the log itself is a permission.

White-label and encrypted backups

Two features target teams that deliver Simmetric Chat to their own customers or run it as internal infrastructure with strict data policies:

White-labeling removes product chrome from customer-facing surfaces - the embedded widget, branding defaults, UI-level customization - under a dedicated license flag. A consultancy deploying a knowledge assistant for a client can present the assistant as the client's own; the platform stays in the background.

Backups go beyond database dumps: scheduled and on-demand jobs produce encrypted backup archives, retention policies decide what to keep and for how long, and a permission split separates who may configure a destination, who may run a job, who may inspect logs, and who may restore. That last distinction matters - triggering a backup and restoring production data into an arbitrary workspace are different levels of trust, and the permission model treats them that way.

Air-gapped licensing for regulated environments

The environments that need SSO, immutable audit, and controlled backups are frequently the same environments with no internet access. Enterprise licensing is built for that: the license is an RS256-signed JWT whose embedded public key ships with the community server. Verification happens locally - the server checks the signature against the embedded key, so no license server needs to be reachable. Set LICENSE_KEY in the server environment, restart, and the features unlock; remove it, and they close back to community with explicit 402 responses.

That design means an enterprise deployment runs entirely inside a data center: local LLMs through Ollama, local vector stores, local embeddings, local OCR, and now local license validation. Air-gapped is not a degraded mode bolted on later - it is the deployment shape this product was designed around.

What this means for the v0.22 line

The community and enterprise lines move together. The community server declares the enterprise plugin as an optional peer dependency; the loader resolves it at boot and the shared plugin context injects the core concerns (auth, crypto, database, logger) so the plugin can only depend on the shared contract, never on community internals. Community releases and enterprise releases are built against the same shared version, and a version mismatch fails loud at boot rather than misbehaving at runtime.

For operators, the practical summary: install the plugin package, set a valid LICENSE_KEY, configure SSO in the admin panel, set the audit-writer password, and restart. The boot log tells you exactly which of those steps succeeded. The community tier remains AGPL-3.0 and fully functional - SSO, audit, and backups are additive on top of it, gated by license rather than by a code fork.

Read the full guide in the docs →