Skip to main content

Host DB and Migrations

Many useful packs need their own data: settings, cached external state, workflow history, identifiers, or domain records created by the pack itself.

That data should live inside Worka’s governed storage model, not in an ad hoc side database the platform cannot see or reason about.

The main design rule​

Use pack-owned data deliberately.

A pack should store only the data it genuinely owns or needs. Do not turn a pack into a shadow application database if the data really belongs at a different platform boundary.

Why migrations matter​

Schema changes are part of the pack’s release contract.

If a new pack release changes the shape of its stored data, the runtime and operator need a clear way to understand that change. Keep migrations explicit and reviewable so that:

  • upgrades are predictable
  • rollback planning is possible
  • pack data remains understandable later

Keep scope clear​

Pack data should remain tenant-safe and workspace-safe. The pack data path should never become an easy way to ignore platform scoping.