Chart major for the authup service family: the consoles are their own services (appVersion 1.0.0-beta.64+)

[tada5hi]

What changed upstream

Plan 101 D2-3 (authup/authup#3513, shipped) turns authup into a service family. The chart is at appVersion 1.0.0-beta.63 and predates all of it, so this is a chart major.

• server-core serves no console at all. Each console is its own service package: @authup/server-auth-console (SSR, the hosted login/consent/workflow pages), @authup/server-admin-console and @authup/server-account-console (static). The hosted page GETs on server-core (/authorize, /logout, /register, /activate, /password-forgot, /password-reset) now 302 to the auth console's url.
• New roles on the same image. server/core start (API plus every enabled console on one listener, the batteries-included default), server/core core (API and IdP alone, mounts nothing), server/core console [admin|account|auth] (one console service, or every enabled one). worker, migration and healthcheck are unchanged.
• The configuration file is authup.yml. authup.conf and authup.server.core.conf are not read any more. See item 1: this is the one that breaks a chart user silently.
• Config sections per service: server.core.*, server.adminConsole.*, server.accountConsole.*, server.authConsole.*, plus the root-level deployment keys and theme.*. Every key is declared exactly once in @authup/server-config, and authup config schema emits the JSON Schema for the whole document.

Supersedes the topology half of #25. Item 1 there (retire the adminConsole workload) still stands verbatim and is repeated below; its items 2-4 describe a shape that no longer exists (server/core console as "the IdP without the management API", a root /theme/** mount, both replica sets running start).

Chart changes

1. The config ConfigMap writes a file nothing reads (silent breakage)

templates/server/configmap-configuration.yaml:10 keys the ConfigMap on authup.server.core.conf. Since authup/authup#3509 the only file read is authup.yml, discovered in the CLI's working directory. A release that sets server.configuration therefore mounts a file the server ignores and boots on defaults plus environment, with one startup log line naming the retired file. Rename the key to authup.yml and keep the mount path. Same for configmap-migration-configuration.yaml.

2. Remove the adminConsole.* workload

Unchanged from #25: templates/admin-console/**, templates/_admin-console-env.tpl, the adminConsole: values block (values.yaml:843), its values.schema.json section, and the TRUSTED_ORIGINS auto-append of the console origin (values.yaml:419). The image's client/admin-console service exits 1, so that Deployment crash-loops against any appVersion from beta.64 on.

3. Single-workload default: no routing change

server/core start still serves the API and every enabled console on one listener, so server.ingress.path: / keeps covering /console/**. Update the accountConsole value comment (values.yaml:432, still says /account; it is /console/account) and document ADMIN_CONSOLE_ENABLED / ACCOUNT_CONSOLE_ENABLED.

4. Optional: the split topology (the bigger piece)

An API workload running server/core core plus a console workload running server/core console. Constraints, all verified against the upstream tree:

• One console process, three listeners. server/core console starts every enabled console, each on its own port: auth 3020, admin 3021, account 3022 (server.<name>Console.port). The container's PORT=3000 applies to server-core only. Each console answers GET /healthy on its own port.
• The ingress must STRIP the console prefix. A console service serves its handler at the ROOT of its own listener (/, /assets/**, /theme/**, /healthy), while the shell's asset hrefs are rebased onto the path component of server.<name>Console.url (/console/admin/assets/...). So /console/admin to :3021 needs a URLRewrite filter (Gateway API) or rewrite-target (ingress-nginx); an un-stripped rule 404s every asset. That url may change PATH but never ORIGIN, which is asserted against publicUrl when the config resolves.
• Four exact paths must stay on the API workload: /console/admin/login/start, /console/admin/callback, /console/account/login/start, /console/account/callback. Those are the cookie-mode sign-in and they are still server-core routes, because the pending-login cookie has to be issued by the origin that reads it back. They must win over the /console/** prefix rule.
• Console pods need no database, no Redis, no migrations, no components. They hold no credential and open no connection, so COMPONENTS_ENABLED / MIGRATION_ENABLED do not apply to them at all: console runs neither by construction.
• The theme moves with the consoles. theme.directoryPath is read by the console SERVICES now, not by server-core, and theme assets are served under each console's own base. templates/server/configmap-theme.yaml has to be mounted on the console pods; a themed split deployment with the volume only on the API pods renders unthemed.
• Redis stays required for a multi-replica API set (the authorization code is a cache entry minted at POST /authorize and redeemed at the callback), and sqlite still cannot split.

5. Docs

README and NOTES.txt mentions of /admin, /account, authup start and the configuration file name.

References

• Upstream: feat(server-core,authup)!: move the operator CLI into the authup package authup#3507 (the authup CLI), #3509 (authup.yml), #3513 (the console services); plan 101 stage D2-4.
• docs/src/guide/deployment/console-replicas.md in authup/authup is being rewritten around these roles in the same release; use it as the routing reference once merged.

[tada5hi]

Superseded by #27, which consolidates the v1 command, configuration, persistence, and deployment requirements.