Architecture
TesseraCore merges four existing open-source apps into one product with one shared UI — not a reskin of four separate services, but a shared Go codebase, server-rendered HTML, no SPA framework, PostgreSQL.
- Casdoor (Go) → IAM/SSO source, the starting point since it’s already Go.
- Snipe-IT (PHP/Laravel) → Asset Management functional/data-model reference.
- iTop (PHP) → ITSM/CMDB functional/data-model reference.
- CheckMK (Python/C++) → Monitoring concept reference (not a port of the actual engine — a lightweight host/status tracker).
- Tabler (Astro/SCSS) → UI foundation, customized with a glassmorphism/neumorphism theme.
Editions
The product ships as both standalone single-module apps and the full unified package, from one shared codebase built into separate binaries:
| Edition | Contains |
|---|---|
tesseracore-iam | IAM only — a complete, sellable identity product on its own |
tesseracore-assets | IAM + Asset Management |
tesseracore-itsm | IAM + ITSM/CMDB |
tesseracore-monitoring | IAM + Monitoring |
tesseracore-full | Everything, integrated automatically in one binary |
IAM is bundled into every edition — an ITSM customer still gets login, users, and RBAC — and is also sold/deployed as its own standalone identity product, usable by other apps too.
Module boundary rule
internal/<module>/{domain,service} packages never import net/http. Only
internal/<module>/http does. This keeps business logic callable both
in-process (same binary) and, for cross-deployment integration, behind a
generated API client.
Shared Postgres, schema per module
One Postgres instance, one schema per module (iam, assets, itsm,
monitoring, notify). Modules use real foreign keys when co-located in
tesseracore-full; any reference that might cross a module boundary not
present in a given standalone edition is a nullable UUID with no DB-level FK
constraint, resolved in application code.
Cross-module integration
Modules never call each other’s packages directly — they publish/subscribe
to a versioned event catalog (AssetCreated, HostAlertTriggered,
TicketStatusChanged, etc.) via internal/events. In tesseracore-full
this dispatches in-process; in standalone editions the same events travel as
signed outbound webhooks to another TesseraCore instance’s /api/events.
Event-handling code is written once against the catalog regardless of which
transport is active.
API-first
Every module’s API is spec-first: internal/<module>/api/openapi.yaml is
written before the handlers, and oapi-codegen generates the Go types and
request/response contracts handlers implement. UI pages live at
/<module>/..., the JSON API at /api/<module>/..., and interactive docs at
/swagger — the same path contract whether one tesseracore-full binary or
several standalone instances sit behind the load balancer.
UI pipeline
Pages are authored as Astro files in the sibling Tabler-TesseraUI repo
first (reusing its shared UI primitives and the glassmorphism/neumorphism
theme tokens), built, then converted into web/templates/{layouts,pages} Go
templates with real data bindings. The Tabler repo stays the single source
of truth for markup and styling.