Your servers. Your data. Your platform.

Self-hosting

Nothing has to leave your network

Every external dependency has a self-hosted seat: your Postgres (via Supabase's self-host stack), your SMTP relay, your Jitsi server for video — and the AI layer speaks to any OpenAI-compatible endpoint, so it can run against an in-network model or be switched off entirely.

git clone https://github.com/Bytes-Medical/petrios.git
cd bytes-teaching
cp .env.example .env.production   # your DB, SMTP, domains
docker compose up -d --build
npm run db:migrate                # plain-Postgres migration runner
curl localhost:3000/api/health    # {"status":"ok","db":"ok"}

Read the self-hosting guide →

Integrate

An API and webhooks, not an island

Wire Petrios into rota systems, data warehouses, or your own frontends: an org-scoped REST API with scoped bearer tokens (OpenAPI schema included), plus HMAC-signed webhooks for session publishes, computed attendance, issued certificates, and claimed slots.

• ▸ Tokens created in Settings, hashed at rest, revocable, per-scope
• ▸ X-Petrios-Signature on every webhook delivery
• ▸ iCalendar feeds and CSV exports for everything tabular

API documentation →

Federation

Records that survive rotation

Trainees rotate; their teaching history shouldn't evaporate. Every instance can sign portable teaching records that any other instance — or anyone at all — can verify against the issuer's published key. Independent deployments become a network, not silos.

Try the record verifier →

Trust & governance

Built for the paperwork too

• ▸ Row-level security everywhere; sensitive tables deny-all behind an audited service layer
• ▸ CI security gates on every PR: CodeQL, Semgrep, secret scanning, dependency audit, an RLS guard
• ▸ AI that drafts but never sends; prompt text never stored; one kill switch
• ▸ DTAC self-assessment starter and DPIA template in docs/compliance