[Bug]: Global Redis password defaults do not work for every documented workload kind

Page or section

https://docs.stacklok.com/platform/enterprise-platform/deployment#global-redisvalkey-defaults

Source: docs/platform/enterprise-platform/deployment.mdx, "Global Redis/Valkey defaults".

What's wrong?

The page says global.redis.host, existingSecret, and existingSecretKey provide default session storage for MCPServer, MCPRemoteProxy, and VirtualMCPServer workloads with no explicit spec.sessionStorage.

That is only fully true for VirtualMCPServer when Redis requires authentication.

The operator forwards the default address to all three workload kinds, but its MCPServer and MCPRemoteProxy deployment builders do not fall back to the global/default Redis Secret. Those child pods get the address without THV_SESSION_REDIS_PASSWORD and fail with:

failed to create Redis session storage: redis: failed to connect: NOAUTH Authentication required

An explicit per-resource spec.sessionStorage.passwordRef works for all three resource kinds.

The current documentation therefore recommends a configuration that renders successfully but crash-loops two of the three documented consumers.

Suggested fix

Until the platform pins an operator release containing the fix, add a clearly scoped warning:

• authenticated global/default Redis works as documented for VirtualMCPServer;
• MCPServer and MCPRemoteProxy must set an explicit Redis spec.sessionStorage with passwordRef;
• passwordless Redis is unaffected by the missing password injection.

Remove the warning when the fixed version is released and update the compatibility statement if the correction is version-specific.

Additional context

Platform bug with source analysis and acceptance criteria:

https://github.com/stacklok/stacklok-enterprise-platform/issues/4310

This was reproduced with Stacklok Enterprise Platform v0.17.0 and remains present in the ToolHive source vendored on current platform main as of 4ac27745a.

Open docs/platform/enterprise-platform/deployment.mdx at the “Global Redis/Valkey defaults” section and review the linked platform issue for the fixed operator version and acceptance criteria. Add a clearly scoped warning covering authenticated Redis behavior for VirtualMCPServer, MCPServer, and MCPRemoteProxy, while noting that passwordless Redis is unaffected. Done means the documented configuration no longer recommends a setup that crash-loops two workload kinds.