Verified by the sovseal team

Self-Hosted Overview

Run the sovseal replication stack on your own infrastructure.

Overview

The sovseal replication and state continuity engine is open-source and can be hosted fully inside your own infrastructure. This option is ideal for enterprise teams that require absolute data custody, strict compliance boundaries, or offline-only execution.


Architecture

When self-hosting, you run the complete replication stack. The edge server operates in a server-blind capacity, only receiving, storing, and serving encrypted data envelopes.

┌───────────────────────────────────────────────────────────────┐
│  Your infrastructure (sovseal server sees none of it)         │
│  ┌──────────────────┐    ┌─────────────────────────────────┐  │
│  │  Edge function   │    │  Postgres (+ pgvector optional) │  │
│  │  v2-agent-state  │───►│  • snapshots table              │  │
│  │  (Hono / Deno)   │    │  • api_keys table               │  │
│  └──────────────────┘    └─────────────────────────────────┘  │
│           ▲                                                   │
│           │ HTTPS, ciphertext only                            │
└───────────┼───────────────────────────────────────────────────┘

   ┌────────┴────────┐
   │  Your agents    │  (local SDK / MCP server)
   └─────────────────┘

Core Operational Areas

1. Deployment Topologies

  • Single-Region Container: Run Postgres and the Hono API server in a single Docker Compose stack. Best for development, testing, or lower-throughput workloads.
  • Edge Deployment: Deploy the edge function on Deno Deploy or Supabase Edge Functions with a globally distributed Postgres backend. Best for multi-device agent deployments requiring minimal latency.

2. Hardware Sizing Guidelines

Sizing scales based on the concurrent write volume (replications) and read requests:

  • Hobby / Sandbox (1-10 agents): 1 vCPU, 1 GB RAM, standard SSD storage.
  • Production (10-100 agents): 2 vCPUs, 4 GB RAM, high-IOPS storage.
  • Enterprise (100+ agents): 4+ vCPUs, 8 GB+ RAM, clustered Postgres instance.

3. Backup & Disaster Recovery

  • Relational database schema and snapshots can be backed up using standard utility dumps (pg_dump).
  • Vector collections are preserved via vector database collection snapshot engines.

4. Upgrades & Migrations

  • Schema upgrades are managed through Alembic migration scripts.
  • Client SDK implementations can transition from self-hosted environments to the managed Platform without data loss by executing the Qdrant import script.

On this page