Startup: what you get, and why pay

Startup is the tier for people running more than one site, or one site that has outgrown a single file-backed node. It is everything in Single Site, moved onto PostgreSQL, with a control plane and per-domain management. Detection itself is unlimited on every tier: run Stylo.Bot across as many domains as you like and they are all protected, sharing one reputation pool. Startup's £50/mo base includes management for one domain; £10/mo per additional domain you want its own dashboard and policy for.

The free engine still does the detection

As with every tier, the detection is the same AGPL-3.0 engine you can run for free: 49 detectors, AI escalation, the read-only dashboard, zero-PII hashed signatures, nothing calling home. FOSS runs a single node with SQLite and hand-edited config, and that is genuinely enough for one host. Startup is not better detection. It is the persistence, scale, and management you need once one SQLite file on one box stops being the right shape.

What Startup adds over Single Site

• PostgreSQL + pgvector persistence (details below).
• Per-domain management: a dedicated dashboard and detection policy for each domain you manage, priced per managed domain. Domains you have not added stay protected by the shared global pool, they just do not get their own dashboard or policy.
• Redis pub/sub for live config: a policy change propagates to every gateway instance at once, not one box at a time.
• Control plane and multi-gateway fleet: register any number of gateways, see them in one fleet view, share reputation across them.
• OIDC relying-party: plug the dashboard into your Keycloak, Azure AD, Okta, Auth0, or Google Workspace.
• The full editor UI and every pack, same as Single Site but across the fleet.

Why Postgres: scale

SQLite is excellent for one node. It stops fitting when you have concurrent gateways writing session and signature state, when your history outgrows a single file, or when you want a query engine behind your analytics. Postgres is what you move to:

• Concurrent, multi-gateway writes: several gateways persist session vectors, signatures, and reputation into one store without file-lock contention.
• pgvector HNSW session similarity: approximate-nearest-neighbour search over behavioural session vectors at a scale brute-force SQLite similarity will not reach. This is what makes "show me sessions that behave like this one" fast on a large corpus.
• Durable, queryable history: retention bounded by your database, not a file, with real indexes and a real planner behind reports and investigation.
• High availability: run Postgres with replicas and failover (the Helm chart ships an HA topology). A gateway node can die without taking your fleet state with it.
• Bring your own or bundle it: point at a managed Postgres, or use the bundled charts.

For how this lands on a cluster, see Add StyloBot on Kubernetes (multi-domain, fleet).

Why Postgres: encryption and data protection

Moving off a single local file is also what lets you protect data properly in transit and at rest:

• Encryption in transit: gateway-to-Postgres and gateway-to-Redis connections run over TLS, so fleet state and live config never cross your network in the clear. SQLite on a local disk never had a connection to encrypt; a fleet does.
• Encryption at rest: Postgres sits behind whatever at-rest encryption your storage or managed provider gives you (encrypted volumes, TDE, KMS-backed disks), so your session and signature history is encrypted on disk under your keys, not ours.
• Data residency: because it is self-hosted, every byte stays in your database, in your region, under your compliance boundary. There is no per-request call to a vendor and no telemetry tax.
• Least-privilege access: the gateway authenticates to Postgres and Redis as scoped roles you control, and the control plane is the only writer.

Field-level column encryption and customer-managed keys are an Enterprise capability; Startup gives you the transport TLS, at-rest, and residency story that a self-hosted Postgres fleet is built for.

Who it is for

Early-stage SaaS, agencies, and small teams running several domains, or one busy domain that needs durable fleet state and the query engine behind it. If you need SSO with SAML, SCIM provisioning, signed compliance exports, field-level encryption, or air-gapped activation, that is Enterprise.

Get started

• Add StyloBot on Kubernetes for the multi-domain, Postgres, fleet setup.
• Add StyloBot to a Docker Compose stack to bring up the gateway plus Postgres and Redis together.
• Add StyloBot as a reverse proxy in front of an existing app.

Start a 30-day trial and evaluate the full surface, or see the plans.