Self-hosting Konversio: overview and requirements

Konversio is designed to run entirely on infrastructure you control. This article covers what you need before you start, what the stack looks like, and how to think about storage and backups.

What you need

Server requirements

A Linux server running a recent Ubuntu LTS or Debian stable release is the recommended base. You will also need:

• Docker (20.10 or later) and Docker Compose (v2 plugin or standalone v1.29+)
• A domain name with DNS you control — Konversio needs a publicly reachable URL for webhooks, email routing, and the live chat widget
• An SMTP service for outbound email (conversation replies, agent notifications, password resets)

Minimum hardware specs

If you run Pilot with a locally hosted model (via Ollama), add at least 8–16 GB RAM and a GPU or fast CPU — the model inference load is separate from the Konversio app itself.

What Docker Compose runs

The default docker-compose.yml brings up the following services:

• Rails app — the main web server, handles the UI and API
• Sidekiq — background job worker (email delivery, webhook dispatch, automation triggers, report generation)
• cable — Action Cable server for real-time updates in the agent UI
• PostgreSQL — primary database
• Redis — job queue, pub/sub for real-time features, caching

All services communicate on an internal Docker network. Only the Rails app and cable server are exposed externally (via a reverse proxy such as Nginx or Caddy).

What data is stored and where

PostgreSQL holds everything structured: accounts, contacts, conversations, messages, users, teams, labels, automation rules, reports, and help center content.

File attachments (images, documents sent in conversations) are stored either locally on disk or in an S3-compatible object store, depending on your ACTIVE_STORAGE_SERVICE setting. By default, local storage is used.

Backup recommendations

At minimum, back up two things:

1. PostgreSQL database — use pg_dump on a schedule. A daily dump with a week of retention is a reasonable baseline. Store dumps off the server (object storage, a second machine).
2. Attachments — if using local storage, back up the storage/ directory. If using S3-compatible storage, your bucket versioning and lifecycle policies cover this.

Redis does not need persistent backups — it holds transient job queue state that will recover on restart.

Test your restores. A backup you have never tested is not a backup.