ChillyOS is a production-oriented SaaS foundation for restaurant ordering and operations. The repository is organized as a monorepo so customer experiences, restaurant tools, platform services, shared capabilities, infrastructure, and quality controls can evolve together without losing clear ownership.
Repository status: Foundation only. The local FastAPI, Next.js, PostgreSQL, SQLAlchemy, Alembic, and Docker environment is runnable, but no product features, APIs, or database models have been created.
The platform is intended to support:
- Multi-tenant restaurant organizations, brands, locations, and staff.
- Customer menu discovery, ordering, checkout, and order tracking.
- Restaurant order acceptance, preparation, fulfillment, and menu operations.
- Platform administration, reporting, notifications, and payment orchestration.
- Production operations with security, observability, testing, and compliance treated as first-class concerns.
| Path | Responsibility |
|---|---|
backend/ |
Route-free FastAPI shell plus SQLAlchemy and Alembic infrastructure. |
frontend/ |
Feature-free Next.js application shell and production build. |
apps/ |
Deployable customer, restaurant, administration, gateway, and worker applications. |
services/ |
Business capabilities with explicit domain ownership. |
packages/ |
Reusable, domain-neutral building blocks and contracts. |
infrastructure/ |
Environment provisioning and platform operations. |
config/ |
Versioned, non-secret configuration and policy definitions. |
docs/ |
Architecture, product, API, operations, security, and compliance documentation. |
tests/ |
Cross-system contract, integration, end-to-end, and performance suites. |
scripts/ |
Future repository automation and operational utilities. |
ChillyOS uses business-capability boundaries rather than technical layers as its primary organizing principle. Services own their rules and data, applications compose capabilities through published contracts, and cross-cutting packages must not become hidden owners of business behavior.
The initial boundaries and non-negotiable engineering rules are defined in
PROJECT_BIBLE.md. Material architectural choices belong in
docs/architecture/decisions/.
- Directory and file names use lowercase kebab-case, except established root governance documents.
- Every major directory contains a README defining its purpose and boundaries.
- Tenant isolation, idempotency, auditability, and least privilege are mandatory.
- Secrets and customer data must never be committed to the repository.
- Shared packages contain reusable primitives, not convenience copies of domain logic.
- Changes to public contracts require compatibility analysis and documentation.
The foundation runs through Docker Compose:
Copy-Item .env.example .env
docker compose up --build
The neutral frontend shell is then available at http://localhost:3000, and
the route-free FastAPI process listens on http://localhost:8000. PostgreSQL
uses the host port configured in .env.
Before product implementation begins:
- Review the principles in
PROJECT_BIBLE.md. - Record material architecture choices under
docs/architecture/decisions/. - Define the first approved product slice under
docs/product/.
ChillyOS is proprietary software. See LICENSE for the applicable
terms.