Feature Flags

There are two kinds of flag in the Features section, and they answer different questions:

• Capability toggles — fixed fields on MemexFeatureOptions (Features:Ai:Providers:OpenAI, Features:Onboarding:InvitationOnly, …). The platform knows them by name and binds them once at startup. That is this page.
• Declared flags — Features:Flags:{name}, declared by the ENVIRONMENT rather than by the platform's C#, read reactively, and able to carry the packages an environment always installs. That is Environment Composition — the surface to use when a deployment needs a switch (or a content set) the platform does not already have a field for.

Memex deployments are shaped by deploy-time capability toggles bound from the Features configuration section into MemexFeatureOptions. A flag declares which capabilities a deployment ships — independent of whether a given credential key happens to be present. A disabled flag is the operator's intent and wins even if a key is configured.

No-regression default. Every flag defaults to its no-change value, so an absent Features section preserves current behaviour: the capability toggles default to true, and the two opt-ins (Onboarding:InvitationOnly, StaticRepoSync:Partitions) default to off/empty. Operators turn capabilities off (or opt in) explicitly.

How flags are bound

MemexConfiguration.ConfigureMemexServices binds the section once at startup so application code resolves the toggles through standard DI (IOptions<MemexFeatureOptions>):

services.Configure<MemexFeatureOptions>(
    builder.Configuration.GetSection(MemexFeatureOptions.SectionName)); // "Features"

Consumers inject IOptions<MemexFeatureOptions> (e.g. the onboarding gate in Onboarding.razor) rather than re-reading configuration ad hoc.

Where values come from

Configuration is layered (last wins):

1. appsettings.json
2. appsettings.{Environment}.json
3. Environment variables — section nesting uses the double-underscore form (Features__Ai__Providers__OpenAI=false). This flows identically through Azure Container Apps env, Kubernetes env, Docker-compose .env, and ARM createUiDefinition → container env.

Reference

There is no Features:Grpc any more: the gRPC mesh transport (meshweaver.v1.Mesh + gRPC-web — foreign-language participants AND the React GUI's browser data plane) is the MeshWeaver.Hosting.Grpc module, switched by listing/delisting the DLL under Modules:Assemblies — default-on everywhere, see Modules.

A related, separate section — Email — configures outbound system mail (used by invitations). It is documented in Invitation-Only Onboarding → Email.

AI flags — symmetric gating

AI provider/CLI flags gate two tiers symmetrically so a provider can never half-register (which would crash on first use):

• Services tier — the in-process IChatClientFactory / CLI Connect strategy registration in ConfigureMemexServices.
• Mesh tier — the catalog source in ConfigureMemexMesh.

if (features.Ai.Clis.ClaudeCode)
    services.AddClaudeCode(config => builder.Configuration.GetSection("ClaudeCode").Bind(config));
// …and the matching catalog source is gated by the same flag in ConfigureMemexMesh.

MemexFeatureOptions.HasAnyChatCapability is true when the deployment ships at least one provider or one CLI — so disabling every provider takes all six Providers flags, not just the four named API vendors. When it is false the portal has no built-in chat via catalog sources (users may still bring their own keys via Model Providers) — surfaced as a startup warning, not a hard failure.

API providers work bring-your-own-key (users add endpoint + key per provider under Settings → Models); see Model Providers. The co-hosted CLIs require the per-user Connect login.

Onboarding modes

The two onboarding flags combine into three modes. The first-user bootstrap exception always applies: a brand-new deployment with zero existing User nodes always lets the very first user onboard (and become platform admin), so the platform can never lock itself out.

InvitationOnly takes precedence: when it is on, the gate is "has a Pending invitation" regardless of AllowSelfOnboarding. The security boundary is enforced at the CreateUser call in Onboarding.razor (not just the UI). Full treatment: Invitation-Only Onboarding.

Examples

appsettings.json — close self-registration and require invitations:

{
  "Features": {
    "Onboarding": { "AllowSelfOnboarding": false, "InvitationOnly": true },
    "Ai": { "Providers": { "OpenAI": false } }
  }
}

Environment variables (ACA / compose / ARM):

Features__Onboarding__InvitationOnly=true
Features__Ai__Providers__OpenAI=false
Features__Orleans__Clustering=AdoNet

Kubernetes (set on the running deployment):

kubectl -n memex set env deployment/memex-portal-deployment \
  Features__Onboarding__InvitationOnly=true \
  Features__Ai__Clis__Copilot=false

See Memex Cloud Deployment → Enable / Configure AI Providers for the full operational walkthrough.

Related

• Invitation-Only Onboarding — the InvitationOnly flag end-to-end + Email configuration.
• Extensible Defaults — system defaults + mesh-level extensions (the pattern behind several capabilities).
• Memex Cloud Deployment — operating these flags in production.