Skip to content

TODOS.md

Latest commit

 

History

History
48 lines (34 loc) · 2.46 KB

TODOS.md

File metadata and controls

48 lines (34 loc) · 2.46 KB
Raw

TODOs

Foundational on-prem control plane design for post-v1

What: Design the post-v1 on-prem control plane architecture for regulated or customer-managed environments.

Why: The v1 plan intentionally ships a hosted control plane only. Some target buyers may still require on-prem later, and the architecture tradeoffs are big enough that they should not live only in chat history.

Pros:

  • Preserves the architectural questions early, before they get rediscovered under deadline
  • Forces clarity on tenancy, secrets, upgrades, support burden, and self-hosted dependencies
  • Gives a cleaner starting point once hosted v1 is validated with design partners

Cons:

  • Easy to confuse with near-term roadmap if not clearly marked as deferred
  • Can distract the team from validating the hosted wedge first

Context: Current v1 scope is hosted control plane, outbound-only agent execution, Patroni-backed 3-site HA, and 2-site controlled DR. This TODO is for the follow-on design work after the hosted wedge proves real demand. A good starting point is an RFC comparing a single-tenant self-hosted control plane versus a customer-managed gateway paired with the hosted control plane.

Depends on / blocked by:

  • Successful validation of hosted v1 with at least one design partner

Internal template authoring workflow for validated deployment shapes

What: Design an internal workflow for authoring, testing, versioning, and promoting supported deployment templates.

Why: The public Designer was correctly deferred from v1, but the team will still need a disciplined internal way to evolve known-good deployment shapes once the first Postgres template is live.

Pros:

  • Creates a sane path to grow the template catalog without turning every change into custom ops work
  • Makes "Supported" versus "Experimental" a real process instead of a vague promise
  • Gives any future Designer effort a grounded internal precursor

Cons:

  • Easy to misread as permission to build the public Designer too early
  • Not valuable until the first wedge is validated and template changes start repeating

Context: This is explicitly not a public-facing Designer feature. It is internal template tooling that would come after v1 proves demand. The goal is to define how templates are authored, validated, versioned, and released so the product can expand without losing trust.

Depends on / blocked by:

  • Successful validation of the v1 Postgres wedge
  • At least one repeated template change that is painful without better internal tooling