Configuring an instance from Aspire

The Deployment record is the ONE input. Aspire and Helm render from it; the image receives it as configuration (Deployment:Record); Aspire emits a record, never a chart. (Maintainer, 2026-09-08: "yes, must be the only input" · "pipe it somehow into the memex image via config ⇒ see how e.g. orleans interfaces" · "create fluent language to configure. give possibilities to configure in the aspire api" · on generating Helm from Aspire: "ok. retire".)

An instance IS a DeploymentContent record — the Hosting/Deployment node the control instance holds at Deployments/<name> (Operating from the portal). Before this change the record had a second, adapter-only copy in MemexOptions (half its fields, different names, a hand-maintained chart beside both), and on 2026-09-06 the record and the rendered overlay disagreed in 41 places that nothing reported. Now there is one declaration and three readers of it:

The contract they share is one assembly, MeshWeaver.Deployment.Contract (namespace MeshWeaver.Deployment; src/MeshWeaver.Deployment.Contract/): the record and its nested specs, the fluent builder (DeploymentRecordExtensions), the configuration binding (DeploymentRecordJson) and the portal-config derivation the chart and the adapter both use (DeploymentPortalConfig). It has zero MeshWeaver references so it can ride inside the published Aspire package (bundled into its lib/ folder — no third NuGet id; the maintainer retired all but two on 2026-09-07), and inside the image it is referenced by MeshWeaver.PluginCatalog, which puts it in the application closure the in-mesh Hosting sources compile against.

The fluent surface

Every method is a pure transform of the record: it returns a new DeploymentContent, leaves its input untouched, composes, and needs no Aspire — the same calls serve an AppHost, the setup wizard, the dotnet new template generator and a test. Defaults live on the record, never on the builder: a bare new DeploymentContent() already renders a bootable portal (PostgreSql graph store, Filesystem backend, port 8080).

using MeshWeaver.Deployment;

var record = new DeploymentContent()
    .WithHost("portal.example.com", dnsZone: "example.com")
    .WithNamespace("portal")
    .WithDatabase("portal", server: "pg-portal", connectionSecret: "portal-pg-connection")
    .WithImage("ghcr.io/systemorph/memex-portal-ai", tag: "3.1.0")
    .WithPluginRepo("plugins", "https://github.com/Systemorph/MeshWeaver.Plugins", gitRef: "main")
    .PreInstall("MeshWeaver.Plugins/Hosting")
    .WithRequiredModule("MeshWeaver.Hosting.Postgres")
    .WithVolume("data", "/data", size: "128Gi", storageClass: "azurefile", accessMode: "ReadWriteMany")
    .WithKeyVault("kv-portal", prefix: "portal-")
    .WithKeyVaultSecrets(secrets => secrets.Map("Email__ClientSecret", "email-clientsecret"))
    .WithSignIn(microsoftClientId: "<client id>", microsoftTenantId: "<tenant>")
    .WithEmail(mailboxAddress: "portal@example.com", clientId: "<client id>", tenantId: "<tenant>")
    .WithAi(ai => ai.OpenRouter(["anthropic/claude-sonnet-4"]).Tiers(heavy: "anthropic/claude-opus-4"))
    .WithReplicas(2)
    .WithResources(requestsCpu: "500m", requestsMemory: "2Gi", limitsCpu: "2", limitsMemory: "8Gi")
    .WithStartupProbe(periodSeconds: 10, failureThreshold: 60)
    .WithOperator(ns: "hosting")
    .WithPortalConfig("Embedding__Endpoint", "https://openrouter.ai/api/v1");

In an AppHost the entry point stays AddMemex, and it returns a resource builder that carries the record. Each With* on the resource builder delegates one-to-one to the record transform above, then re-syncs what Aspire derives (images, volumes, replicas); Configure(record => …) applies any transform the named wrappers do not carry.

var builder = DistributedApplication.CreateBuilder(args);

builder.AddMemex("memex")                       // the default record: default images, one replica, the fleet's three volumes
    .WithImage("ghcr.io/systemorph/memex-portal-ai", tag: "3.1.0")
    .WithOrleansClustering("AdoNet")
    .WithPluginRepo("plugins", "https://github.com/Systemorph/MeshWeaver.Plugins", gitRef: "main")
    .PreInstall("MeshWeaver.Plugins/Hosting")
    .WithSignIn(microsoftClientId: "<client id>", microsoftTenantId: "<tenant>")
    .WithSecret("Authentication__Microsoft__ClientSecret", builder.AddParameter("microsoft-client-secret", secret: true))
    .PublishRecord("deployments/memex.json");   // the FINAL record, written when the application starts

builder.Build().Run();

AddMemex(name, record) starts from a record you already have; AddMemexFromFile(name, path) reads one (a bare record, or a full mesh node with a content object — what get Deployments/memex returns). MemexOptions is what is left of the old options type: the default image registry, the default portal repository, the derived default tag (<major>-latest) and DefaultRecord(name).

Secrets are never on the record — it syncs to git. On Kubernetes a secret is a Key Vault name on the record (keyVaultSecrets, vaultValuesKeys) and a value the CSI driver mounts; under Aspire it is WithSecret(configurationKey, parameter) — an Aspire parameter, or a literal in development — handed to the container directly. PublishRecord never writes one, by construction.

How the record reaches the image

The way Orleans' Aspire integration hands a silo its clustering — resource → environment → the app binds from configuration — the adapter injects the record into the portal container as one configuration section:

It is one JSON value on purpose: DeploymentContent is an init-only record over immutable collections, carrying the mesh's $type, and none of that binds through the configuration binder — while one JSON value is byte-identical on a ConfigMap and in an Aspire environment. The portal reads it with DeploymentRecordJson.FromConfiguration(configuration) (null when the section is absent — a Monolith, a test). The derived per-key surface stays beside it because that is what every existing IOptions reader in the image already binds; the record is the source, the keys are its projection.

The two routes differ in exactly the places PortalConfigOptions names — declared, not discovered:

FluentBuilderTest.TheSameRecordRendersTheSameKeysForHelmAndForAspire renders the real memex record both ways and asserts the difference is exactly these three.

The parity table

This table is the contract between the fluent surface, the record and the two renderers. RendererParityTest (test/MeshWeaver.Deployment.Contract.Test) reads it: every method it names exists on DeploymentRecordExtensions; every record transform the code has is in it; every field it names is on the record; every public field of the record is reached by some row (or is in the "written by the operator" table below); and every configuration key it names is emitted by DeploymentPortalConfig.PortalConfig for a fully populated record (Prefix__* names a family). Editing the code without the table, or the table without the code, is red.

Helm values are the paths in the values file HelmValues.Render produces (config.memex_portal.* is the portal ConfigMap). A dash means the field is the record's or the operator's alone — it configures no container.

The nested builders these rows lean on: KeyVaultSecretsSpec.Map(key, vaultSecret); AiProviders.OpenRouter(models, endpoint, order, enabled) / .Anthropic(…) / .AzureFoundry(…) / .AzureAis(…) / .Tiers(heavy, standard, light, utility); WithStorageLayout(s => s with {…}) and WithRegistry(r => r with {…}) take the spec record directly.

Fields no method sets — the operator writes them, or they are a legacy shape kept for records that still carry it:

Retired: generating the Helm chart from Aspire

Core #3646 asked for the chart to be generated from the Aspire model through Aspire's Kubernetes/Helm publisher. That direction is retired (maintainer, 2026-09-08: "ok. retire"), for measured reasons:

• The chart's operational contract is not expressible in Aspire's publisher. The publisher emits a Deployment, a Service and an Ingress per container. The chart renders what an instance actually needs to run on the fleet: the run-once migration Job that gates the portal (DbVersionGate), the SecretProviderClass per Key Vault class and the CSI mounts, KEDA scaling, the startup probe and drain contract, the hosting operator and its service account, the hosted registry, the language-gate sidecars, session affinity and the per-ingress-class annotations. Each of these is a field on the record and a section of HelmValues.Render; none is a container-level property a generic publisher could derive.
• The duplication it meant to remove was the adapter's own second copy of the record, not the chart. On 2026-09-06 the record and the rendered overlay disagreed in 41 places because the values were declared twice (MemexOptions and the record) and rendered by two hands. With the record as the one input the chart is a renderer of it, exactly like the adapter — the duplication is gone without generating anything.
• What Aspire does emit is the record (PublishRecord), which the control instance turns into a chart release through Provision — so the developer path and the fleet path meet at the record, not at a YAML file.

Aspire.Hosting.Kubernetes is therefore not referenced by the deploy AppHost (deploy/aspire/Memex.Deploy.AppHost), and --mode kubernetes is gone.

What is still open

• The Plugins half. The in-mesh Hosting module (Hosting/Deployment/Source/*) still compiles its own copy of DeploymentContent; its PR replaces that copy with using MeshWeaver.Deployment; and makes HelmValues.PortalConfig delegate to DeploymentPortalConfig. It stays a DRAFT until the fleet's images carry this assembly (merging to Plugins main edits live portals — a registration syncs sources at main's HEAD).
• German labels. The in-mesh record carries [Translation("de", …)] on every property; the contract cannot (the attribute is read by concrete type from MeshWeaver.Messaging.Contract, which is not a published package). The pairs are preserved in the appendix below, and return to the declarations once the localizer reads a catalog for declarations.

Labels

The property labels of the record, English ([Description], on the contract) and German (the in-mesh [Translation] texts, preserved here until the catalog follow-up above).