Deployment Models and Scope

SynckHub uses separate operating and entitlement concepts:

  • operating model: customer-operated or SynckHub-managed;
  • deployment topology: how services are wired;
  • entitlement: the active-user and feature limits.

Do not mix them.

Customer-operated model

SynckHub Free Self-Hosting uses the pinned env/self-hosted Compose stack, one API process, local password hashes, local PostgreSQL, and filesystem blobs. Its free entitlement permits five active human users. Common does not authenticate users to the data plane and SynckHub has no support-access credential.

SynckHub-managed model

Shared SaaS and dedicated enterprise deployments are operated by SynckHub. Their Ansible inventory, Vault, support access, topology, and Common authentication belong to that managed service and are documented separately.

What a real production deployment must cover

At minimum, production self-hosting means:

  • TLS-terminated public edge with stable hostnames
  • durable Postgres and blob storage
  • Common to SynckHub control-plane wiring
  • pinned release images
  • backup and restore discipline
  • a maintenance-window deploy process
  • explicit handling for every optional integration you enable

For self-hosted production:

  • no insecure auth bypasses
  • TLS edge is mandatory
  • stable Postgres and blob persistence are mandatory

Scope warning

Do not promise features operationally just because code exists somewhere in the tree. Only enable what you can route, secure, back up, and support.

Previous
Deployment
Next
Explorer