Bento docs
Bento documentation

One foundation.
Two ways to build.

Bento is a SaaS starting point you own. It has modular backends in Go and NestJS, matching Next.js and SvelteKit frontends, and the privacy and security controls a real product needs, already connected.

$ bento init my-saas
Frontend previews

The same product in two frameworks

The same components, themes and page patterns in each edition. These are UI previews. Account actions need a connected backend.

What's inside

A backend built to be split later

Every part of Bento is documented where it lives in the repository. These pages give you the overview.

Modules

Fourteen modules. None imports another.

Each module owns its PostgreSQL schema. Modules talk through events and versioned capability contracts, and the build fails if one module imports another.

IdentityAccountAuthorizationAuditUsageFilesBillingEntitlementsNotificationsPrivacyAIRealtimeChatIntegrations
Compliance
9/10

GDPR technical areas implemented

5/10

Selected SOC 2 software areas implemented

Deployment

One build, split by configuration

Run everything in one process, or put any set of modules in its own service behind an edge.

MonolithBENTO_MODULES unset
ServiceBENTO_MODULES=account,files
EdgeBENTO_ROLE=edge
Contracts

Language-neutral by design

Events, capabilities, principal assertions and route listings are JSON Schema and OpenAPI files in contracts/. The Go edge serves the Nest services unchanged.

118

event schemas

45

capability contracts

Backends

Go and NestJS

The same modules, folders and rules in both, passing the same end-to-end suites as a monolith and as a split.

Frontends

Next.js, SvelteKit, Expo

Two web editions kept in step, six style presets, and a React Native app getting started.

CLI

Start a project

bento init copies a backend and frontend starter into a new project, with the local stack, the testing harness and the API contract.

Testing

Checked on both backends

Twelve end-to-end suites run against Go and Nest, as a monolith and split behind an edge. k6 load profiles and Toxiproxy outages test the real backend.

Infrastructure

One local stack, observed

PostgreSQL, Redis, S3, Mailpit and NATS in Compose, with Grafana dashboards and alert rules for application and security signals.

Errors

Every failure has a kind, a code and a safe message

Ten kinds decide the status, stable codes drive the UI, internals never leave the process, and a failed dependency is never read as "no". The same model runs from a domain rule through capabilities, events and realtime to the message on screen.

401 identity.sign_in_denied403 identity.reauthentication_required409 files.version_conflict429 identity.sign_in_throttled503 usage.authorization_check_failed