Deployment

A production deployment runs the compiled binary against one initialized database directory and exposes its single HTTP/WebSocket port through a TLS reverse proxy.

clients → https://chat.example.com → reverse proxy → 127.0.0.1:5613
                                      ├─ HTTP pages/assets/uploads
                                      └─ WebSocket /

Production checklist

1. Compile src/main.osl in a repeatable build environment.
2. Initialize the database once and validate its config.json.
3. Set server.url to the public origin clients use.
4. Keep websocket.host on a private interface (typically 127.0.0.1) and terminate TLS at the proxy. Use 0.0.0.0 or :: only when the container/network boundary provides the intended restriction.
5. Enable WebSocket upgrade forwarding on / and allow attachment request bodies up to your configured policy.
6. Choose local or S3-compatible attachment storage and verify write access before accepting users.
7. Run originchats-osl use /absolute/database/path under a process supervisor.
8. Back up JSON/index data and attachments, then test a restore.

Operational signals

Startup logs report loaded user, role, channel, webhook, slash-command, and plugin counts, followed by the listening port. Startup exits on invalid configuration, unavailable attachment storage, failed attachment migration, or an invalid database directory.

The server sends an application ping every 30 seconds. server_stats provides authenticated administrative runtime information. HTTP request logging is enabled in the router.

Security notes

WebSocket origins and CORS are open in the reference server. Treat the Rotur validator flow, per-command authentication, permissions, webhook credentials, attachment validation, and your reverse proxy controls as security boundaries. Rate-limit at both the application and edge where appropriate. Never expose S3/R2 secrets to clients.