BomLoomArchitecture
How BomLoom is structured and the principles behind it.
Repository layout
| Path | Content |
|---|---|
apps/backend | NestJS server: REST API, persistence, serves the web app in production. |
apps/frontend | Vue single-page application. |
packages/api | OpenAPI specification and the types and schemas generated from it. |
docs | This documentation (Fumadocs), published to docs.bomloom.com. |
docker | Container image and local development services. |
API first
packages/api/openapi.yaml (OpenAPI 3.1) is the single source of truth for the HTTP API. Changes start in the
specification; pnpm api:generate then produces:
- TypeScript types consumed by the frontend through
openapi-fetch, - Zod schemas the backend uses to validate requests (
ZodValidationPipe).
Generated files are committed, so changes to the API are visible in reviews.
Plugins and adapters
Integrations are implemented behind adapters so they can be added or swapped without touching the core:
- Authentication: OIDC/OAuth providers and local users.
- SBOM formats: CycloneDX first, SPDX later.
- Advisory sources: OSV first, more sources later.
Multi-tenancy
Every resource belongs to an organization. Organizations are isolated from each other.
Workers
Scanners run as worker images in CI pipelines and report their results to the BomLoom server, authenticated with API tokens.
Deployment
BomLoom ships as a single container image: the backend serves the API under /api and the built frontend for all
other paths. Database migrations run on startup.