What the stack is
A Venoly deployment is a set of cooperating services rather than a single binary. The core is a stateless API and realtime gateway; supporting services handle media, background work, and data. Because the API is stateless, it scales horizontally behind a process supervisor.
| Component | Role |
|---|---|
| API + realtime gateway | The stateless HTTP API and WebSocket gateway (the main application). |
| Relational database | Durable storage with sensitive columns encrypted at rest. |
| Cache & pub/sub | In-memory store for sessions, presence, rate-limit counters, and cross-instance realtime fan-out. |
| Media server (SFU) | Carries voice/video/screen-share, deployed separately from the API. |
| Edge / reverse proxy | TLS termination, static delivery, and edge rate-limiting. |
| Process supervisor | Runs the API and microservices in a cluster with zero-downtime reloads. |
| AI model runtime (optional) | Backs the AI character layer; the platform runs fine without it (characters simply go offline). |
How a deployment is shaped
- Schema is versioned and applied automatically at boot, so upgrades are forward-only and idempotent.
- Secrets are loaded from the environment or a secrets mount — never hard-coded, never published.
- Security policies (.vnl) ship as readable files and are evaluated by the built-in policy VM.
- The platform fails safe: optional subsystems degrade gracefully rather than taking the service down.
Why details aren't on this page
Exact versions, ports, network topology, environment variables, and security thresholds would help an attacker more than they would help a reader, so they are not published here. Operators who need to run Venoly receive that information directly.
Get the operator guide
Self-hosting is an advanced path. To request the operator documentation or discuss a deployment, contact founder@venoly.nl. For the developer/bot platform (not self-hosting), see /developers.
