onebox/readme.hints.md

# Onebox Project Hints

## SSL Certificate Storage (November 2025)

SSL certificates are now stored directly in the SQLite database as PEM content instead of file paths:
- `ISslCertificate` and `ICertificate` interfaces use `certPem`, `keyPem`, `fullchainPem` properties
- Database migration 8 converted the `certificates` table schema
- No filesystem storage for certificates - everything in DB
- `reverseproxy.ts` reads certificate PEM content from database
- `certmanager.ts` stores SmartACME certificates directly to database

## Architecture Notes

### Database Layer (November 2025 Refactoring)

The database layer has been refactored into a repository pattern:

**Directory Structure:**
```
ts/database/
├── index.ts              # Main OneboxDatabase class (composes repositories, handles migrations)
├── types.ts              # Shared types (TBindValue, TQueryFunction)
├── base.repository.ts    # Base repository class
└── repositories/
    ├── index.ts          # Repository exports
    ├── service.repository.ts      # Services CRUD
    ├── registry.repository.ts     # Registries + Registry Tokens
    ├── certificate.repository.ts  # Domains, Certificates, Cert Requirements, SSL Certificates (legacy)
    ├── auth.repository.ts         # Users, Settings
    ├── metrics.repository.ts      # Metrics, Logs
    └── platform.repository.ts     # Platform Services, Platform Resources
```

**Import paths:**
- Main: `import { OneboxDatabase } from './database/index.ts'`
- Legacy (deprecated): `import { OneboxDatabase } from './classes/database.ts'` (re-exports from new location)

**API Compatibility:**
- The `OneboxDatabase` class maintains the same public API
- All methods delegate to the appropriate repository
- No breaking changes for existing code

## Current Migration Version: 8

Migration 8 converted certificate storage from file paths to PEM content.

## Reverse Proxy (November 2025 - Caddy)

The reverse proxy now uses **Caddy** for production-grade reverse proxying with native SNI support, HTTP/2, HTTP/3, and WebSocket handling.

**Architecture:**
- Caddy binary downloaded to `.nogit/caddy` on first run (v2.10.2)
- Caddy process managed by `CaddyManager` class
- Configuration pushed dynamically via Caddy Admin API (port 2019)
- Automatic HTTPS disabled - certificates managed externally via SmartACME
- Zero-downtime configuration updates

**Key files:**
- `ts/classes/caddy.ts` - CaddyManager class for binary and Admin API
- `ts/classes/reverseproxy.ts` - Delegates to CaddyManager

**Certificate workflow:**
1. `CertRequirementManager` creates requirements for domains
2. Daemon processes requirements via `certmanager.ts`
3. Certificates stored in database (PEM content)
4. `reverseProxy.addCertificate()` writes PEM files to `.nogit/certs/` and updates Caddy config
5. Caddy serves TLS with the loaded certificates

**Configuration:**
- Dev mode: HTTP on 8080, HTTPS on 8443
- Production: HTTP on 80, HTTPS on 443
- Admin API: localhost:2019 (not exposed externally)
- Automatic HTTPS disabled to prevent Caddy from binding to default ports