Introduction to Platform-Kernel
Platform-Kernel is a production-grade, industry-agnostic modular SaaS core built for independent software developers who need a complete infrastructure layer without building one from scratch. It provides every service your module needs — from authentication and data persistence through financial ledgers and real-time notifications — through a unified, type-safe SDK.
This portal is for independent module developers integrating with Platform-Kernel. If you are operating the kernel itself (infrastructure, self-hosting, DevOps), start with Self-Hosting → Requirements.
The Business Model: B2B2B White-Label
Platform-Kernel is a white-label SaaS core operating across three tenant tiers in a strict hierarchy:
| Tier | Role | What they do |
|---|---|---|
| Platform Owner | Operates the kernel | Manages infrastructure, billing plans, system-wide settings |
| Partner | White-label reseller | Provisions client tenants, customises branding, manages access |
| Client | End-user organisation | Installs modules, manages their own users and data |
Each tier is fully isolated. The kernel enforces Row-Level Security (RLS)
in PostgreSQL and a closure-table ancestry structure for O(1) hierarchy
lookups — a tenant_id propagates through every API call, every database
row, and every Kafka message.
The Core Philosophy: "Everything Is a Primitive"
Platform-Kernel is not a collection of micro-features. It is built around seven primitives — atomic, composable building blocks that collectively cover 100 % of the infrastructure concerns a module developer will ever need. Every module solves its domain problem by combining exactly these seven primitives.
| # | Primitive | SDK Package | Backend Service | Responsibility |
|---|---|---|---|---|
| 1 | Auth | @platform/sdk-auth | IAM Service | Authentication (JWT ES256, Argon2id), RBAC, MFA (TOTP), OAuth providers, multi-tenant delegation |
| 2 | Data | @platform/sdk-data | Data Layer | CRUD (PostgreSQL + RLS), analytics (ClickHouse), cache (Valkey), CDC pipeline, auto-generated REST endpoints |
| 3 | Events | @platform/sdk-events | Event Bus | Domain events (Kafka), transactional messaging (RabbitMQ), browser CustomEvents bridge |
| 4 | Notify | @platform/sdk-notify | Notification Service | WebSocket push, browser push, pluggable channels (Email, SMS, Telegram, Discord, Slack, WhatsApp, Webhook) |
| 5 | Files | @platform/sdk-files | File Storage | S3-compatible upload/download, presigned URLs, antivirus staging, server-side image processing (libvips) |
| 6 | Money | @platform/sdk-money | Money Service | ACID wallets, integer-only ledger (no float), hold/confirm/cancel, reversals, double-entry bookkeeping |
| 7 | Audit | @platform/sdk-audit | Audit Log Service | Immutable append-only audit trail (ClickHouse), dual-write resilience (Kafka + PostgreSQL WAL), 7-year retention |
Platform-Kernel contains zero business logic. It does not know what your module does. Authentication, data storage, money movement, and notifications are infrastructure concerns — your module's domain logic is always yours.
System Architecture
The kernel is a polyglot monorepo: Go services (backend), TypeScript packages (SDK and UI), and Module Federation 2.0 for runtime module loading.
Protocol Translation
Clients (browser, SDK, external systems) communicate with the kernel exclusively via REST/HTTP through the API Gateway. Internally, the gateway translates every request into a gRPC call to the appropriate Go service. This means:
- Your module's SDK calls hit
https://api.septemcore.com/api/v1/... - The Gateway validates the JWT, checks rate limits, validates against OpenAPI schemas, then forwards as gRPC
- Go services only expose gRPC — there is no direct REST route to any backend service
Tech Stack at a Glance
| Layer | Technology |
|---|---|
| Backend services | Go 1.26.1 |
| Frontend shell | Vite 8 · React 19 · TypeScript strict |
| Module loading | Module Federation 2.0 (@module-federation/vite) |
| SDK | TypeScript, 12 npm packages + 10 frontend packages |
| Primary database | PostgreSQL 17 (OLTP, with RLS) |
| Analytics database | ClickHouse (OLAP, ReplacingMergeTree) |
| Cache | Valkey (Redis-compatible) |
| Message streaming | Apache Kafka (domain events, 8 topics) |
| Task queues | RabbitMQ (transactional, retry, DLQ) |
| File storage | S3-compatible (SeaweedFS or AWS S3) |
| Secrets | HashiCorp Vault (JWT signing keys, TLS certs) |
| API contracts | OpenAPI 3.1.0 (9 specs) · gRPC / Protobuf (7 packages) |
| Security | JWT ES256 · Argon2id · mTLS · AES-256-GCM · TLS 1.3 |
| Documentation engine | Docusaurus 3.10.0 |
Who This Documentation Is For
| Reader | What to start with |
|---|---|
| Module developer (frontend-first) | Quickstart → SDK Overview |
| Module developer (full-stack) | Quickstart → Project Structure → Module Manifest |
| Architect / technical evaluator | Architecture Overview → Concepts → Multi-Tenancy |
| DevOps / infrastructure | Self-Hosting → Requirements |
What Platform-Kernel Is Not
Understanding boundaries is as important as understanding capabilities:
| Not included | How to solve it |
|---|---|
| Business logic for any specific domain | Build your own module using the seven primitives |
| Pre-built UI beyond the admin shell | Compose from @platform/sdk-ui Design System components |
| Industry-specific integrations | Register your external integration via Integration Hub |
| A monolithic application framework | Platform-Kernel is pure infrastructure — your module architecture is your own |
Next Steps
| Guide | What you will learn |
|---|---|
| Quickstart | Scaffold your first module and register it with the kernel in five steps |
| Project Structure | Anatomy of a module — every directory and file explained |
| Module Manifest | Full module.manifest.json specification with all fields |
| Concepts → Primitives | How the seven primitives compose into module features |