[FEATURE]:Multi-node / HA scaling story for opencode serve — is this on the roadmap?

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

We're deploying opencode serve behind a sidecar in Kubernetes and hit the same wall #17341 described: running multiple opencode serve instances behind a load balancer for horizontal scaling / HA isn't currently supported, for two independent reasons:

1. Session/conversation storage is a single local SQLite file per process (Database.path() / layerFromPath, packages/core/src/database/database.ts) — not shareable across instances, no dialect abstraction exposed today.
2. A directory's InstanceContext is cached in-memory per process (InstanceStore, packages/opencode/src/project/instance-store.ts), and provisioning locks are process-local — so a request for a given directory/session landing on a different instance than the one that created it gets no history and, depending on the caller, may re-provision from scratch.

What we found already exists

• #17341 ("Making OpenCode-Server scalable") asked for this directly — it got one community pointer to an unofficial third-party project (kubeopencode) and was auto-closed by the stale bot after 60 days, with no maintainer response.
• #14212 ("Support more DBMS' for OpenCode state storage") has real progress: @tripersonale built and tested a working PostgreSQL backend (@effect/sql-pg, OPENCODE_DATABASE_DIALECT/OPENCODE_DATABASE_URL, 1035/1035 tests passing on both dialects as of Aug 2026) on a fork (tripersonale/opencode:feat/multi-database-backend), and mentioned an upstream PR "when the diff stabilizes." As of 1.18.26 this hasn't landed on dev.
• #44892 ("Concurrent opencode run processes race on shared project upsert") shows there's already a known race even in the current single-instance-per-DB model, which would need addressing before any shared-DB multi-instance story is safe.

The DB-storage half has a viable path forward via #14212. The instance/session-routing half has no tracking issue at all — nothing currently addresses making the in-memory InstanceStore (or an equivalent) resolvable across processes, which is the other required piece for true horizontal scaling.

Ask

• Is multi-node / stateless-session opencode serve on the roadmap in any form?
• If the Postgres work in #14212 is close to landing, is there interest in a follow-up around externalizing/making resolvable the per-directory InstanceStore state, so a request can be served correctly regardless of which instance receives it?
• If this isn't planned, is there a recommended pattern today for running opencode serve at scale (e.g. sticky routing per session as the intended deployment model, rather than a shared-nothing/stateless one)?

Happy to share more detail on our specific deployment constraints if useful.