> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sovseal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Platform vs Self-Hosted: Choosing Your Deployment

> Compare the managed sovseal Platform and self-hosted edge function across features, compliance, cost, and migration to choose the right fit.

<style>
  {`
      main, article, .prose {
        margin-left: 2.5cm !important;
        margin-right: 2.5cm !important;
      }
      `}
</style>

Choosing between the managed **sovseal Platform** and a **self-hosted** edge function comes down to your operational priorities, not your security requirements. Because both options enforce client-side encryption, your choice does not affect the zero-knowledge guarantees — **the server remains blind to your plaintext regardless of where it runs.** The difference is who operates the replication infrastructure.

***

## Feature matrix

| Feature                 | Platform (Managed)                                               | Self-Hosted                                        |
| ----------------------- | ---------------------------------------------------------------- | -------------------------------------------------- |
| **Read latency**        | 0 RTT (local vector search)                                      | 0 RTT (local vector search)                        |
| **Write latency**       | Local commit — 3.8ms p50                                         | Local commit — 3.8ms p50                           |
| **Replication sync**    | Managed write-behind queue                                       | Self-operated Hono edge function                   |
| **Replication storage** | Managed Supabase + storage bucket                                | Your Postgres + S3 / object storage                |
| **Key custody**         | Client-only (OS keychain; HKDF subkeys)                          | Client-only (OS keychain; HKDF subkeys)            |
| **Key authorization**   | `sov_live_` API key (DB-backed)                                  | Custom auth or static token                        |
| **High availability**   | Single hosted region (Frankfurt); best-effort outside Enterprise | DIY routing and cluster setup                      |
| **Replication latency** | Managed queue draining                                           | Bound by your infrastructure capacity              |
| **Maintenance**         | Zero-ops — updates managed by sovseal                            | Self-managed schema migrations and runtime updates |

***

## Compliance and security decision guide

Use these callouts to align your hosting choice with your regulatory environment.

<Steps>
  <Step title="Start here: does your security policy prohibit third-party cloud storage of ciphertext?">
    If your policy prohibits **any** external cloud storage — even of opaque encrypted blobs — you must use Self-Hosted. Deploy the edge function inside your own VPC or GovCloud environment and point the SDK at your endpoint.

    If your policy permits external storage of non-readable ciphertext, continue to the next step.
  </Step>

  <Step title="Does your application fall under a strict regulatory framework?">
    If your app is not subject to specific regulatory mandates (no HIPAA, FedRAMP, or equivalent), use the **managed Platform**. It's the fastest path to production with zero infrastructure to operate.

    If your app is subject to specific compliance frameworks, continue to the next step.
  </Step>

  <Step title="GDPR and SOC 2 workloads">
    The managed **Platform** narrows the surface these frameworks care about, but read the posture honestly:

    <Note>
      **What is true:** the managed server only ever stores AES-256-GCM ciphertext and `client_payload_hash` SHA-256 integrity anchors. Plaintext personal data is never processed or held on sovseal's servers, and plaintext never crosses a border because it never leaves the host machine. Erasure is handled client-side via rollback or local deletion tombstones.

      **What we do not claim:** sovseal is not certified under GDPR or SOC 2. GDPR readiness is **In Progress** and **no SOC 2 report has been issued** — see [Trust](/platform/trust). The architecture makes the audit surface narrow; it does not substitute for an audit.
    </Note>

    For a SOC 2 assessment, the Platform's audit surface is narrow: the server receives and stores opaque ciphertext, so there is no plaintext data flow to document.
  </Step>

  <Step title="HIPAA and FedRAMP workloads">
    <Note>
      If your company policy requires that even encrypted payloads cannot reside on third-party SaaS infrastructure, use **Self-Hosted**. Deploy the replication edge function to your own Supabase project. The SDK configuration is a single `endpoint` change — no other code modifications required.
    </Note>

    Self-Hosted gives you full control over network topology, storage location, and access logging for the replication endpoint. The encryption and key custody model is identical to the Platform.
  </Step>
</Steps>

***

## Cost and resource comparison

| Metric                   | Platform                                                                  | Self-Hosted                                        |
| ------------------------ | ------------------------------------------------------------------------- | -------------------------------------------------- |
| **Setup time**           | Under 5 minutes                                                           | 15–30 minutes                                      |
| **Infrastructure costs** | Flat monthly plan with fair-use ceilings — storage and sync included      | Your compute, Postgres, and object storage billing |
| **Scale limits**         | Soft fair-use ceilings, reviewed by a human — not runtime-throttled       | Constrained by your DB connection pools            |
| **Support SLA**          | Enterprise only (99.9% uptime, per contract); all other plans best-effort | Community + GitHub                                 |

***

## Migration paths

Moving between Platform and Self-Hosted requires no source code changes beyond a single configuration update. Your local LanceDB index is unaffected — it doesn't move when your replication endpoint does.

### Platform → Self-Hosted

<Steps>
  <Step title="Deploy the edge function to your infrastructure">
    From your sovseal repo checkout, deploy the Deno edge function and apply the database migrations to your Postgres instance.

    ```bash theme={null}
    supabase functions deploy v2-agent-state
    supabase db push
    ```
  </Step>

  <Step title="Drain or export your existing replication queue">
    Either wait for the in-flight write-behind queue to drain completely, or export your local LanceDB snapshot directory directly. The local index is the source of truth — nothing is lost if you switch endpoints mid-flight.
  </Step>

  <Step title="Update your SDK configuration">
    Point `replicationUrl` at your new endpoint and swap in your self-hosted auth token.

    ```typescript theme={null}
    import { AgentStateClient } from "@sovseal/sdk";

    const memory = new AgentStateClient({
      endpoint: "https://your-project.supabase.co/functions/v1/v2-agent-state",
      apiKey: process.env.MY_SELF_HOSTED_TOKEN,
    });
    ```

    The background worker will automatically begin replicating new writes to your endpoint from this point forward.
  </Step>
</Steps>

### Self-Hosted → Platform

<Steps>
  <Step title="Create a managed project and generate an API key">
    Register at [app.sovseal.com](https://app.sovseal.com) and generate a `sov_live_` API key from the **Devices** page.
  </Step>

  <Step title="Update your SDK configuration">
    Point `replicationUrl` at the managed Platform endpoint and swap in your `sov_live_` key.

    ```typescript theme={null}
    import { AgentStateClient } from "@sovseal/sdk";

    const memory = new AgentStateClient({
      endpoint: "https://ksrlmubaxzwufziwarps.supabase.co/functions/v1/v2-agent-state",
      apiKey: process.env.SOVSEAL_API_KEY, // sov_live_...
    });
    ```
  </Step>

  <Step title="Let the background worker sync">
    The background worker automatically synchronizes your existing local LanceDB records to the Platform. No manual data export or import step is required. You can watch sync progress on the **Home** and **Devices** pages of the [dashboard](https://app.sovseal.com).
  </Step>
</Steps>

<Tip>
  Migration in either direction is reversible at any time. Because the local LanceDB index is always the canonical store, you can point your `replicationUrl` at a new target and the background worker will reconcile from there — no data is at risk during the switch.
</Tip>