What PlatformKit is

PlatformKit

PlatformKit is a Go foundation for composing multi-tenant SaaS applications, built as a reference architecture: about thirty thousand lines that demonstrate ten ideas once each, with the gates that keep them true running on every pull request.

It brings together a small kernel, business modules that are plain Go packages, typed web components with a stylesheet that is a Go value, and an operator interface whose screens are generated from entity schemas. An application is a list of modules constructed in main with typed dependency structs; a client is configuration and assets on one image.

The source of truth is the repository at https://github.com/septagon-oss/platformkit. This site is the narrative that gets you to the right file there; when the two disagree, the repository is right.

The ten ideas

The repository’s ARCHITECTURE.md walks the same ground in the order a request meets it: the composition, the request path, the schema, the interface, the delivery boundaries and how each is verified. The decisions behind it are the ADRs. As ten ideas, one line each:

  1. Composition is a list: apps/platformkit/modules.go constructs every module in dependency order, and the compiler checks the graph.

  2. A module is three things: contracts/, internal/ and module.go.

  3. Cross-module dependencies are Go interfaces declared in the provider’s contracts/; a module’s internal/ cannot be imported.

  4. Tenant isolation belongs to the database, through FORCE ROW LEVEL SECURITY set per transaction, and to the type system, through db.Tx[db.Tenant] and db.Tx[db.System].

  5. Authorization is declared beside every route and validated at boot.

  6. Events leave through one transactional outbox to NATS JetStream.

  7. Each capability owns its migration history; one runner applies them in composition order.

  8. Screens derive from schemas: rest.Spec.Mount registers a resource, and the admin module generates seven pages from each one.

  9. A client is configuration: one image, one binary with roles, differences in configuration and assets only.

  10. Claims need evidence: make check and make e2e prove what they exercise, and untested claims stay explicit.

Where to go next

  • Run it — one go run command with nothing but Go installed, then the development loop against Postgres and NATS.

  • Architecture — the nested maps, from the repositories down to each flow, then the layout, the budgets and the browser half.

  • Build a module — the task module as the worked example.

  • A client is configuration — how a product is assembled from public, catalog and client modules.

  • Components, pages and screens — the UI stack and the seam a second shell reads.

  • The native shell — the Expo application that generates its screens from the same seam.

Questions go to the community discussions.