Aller au contenu

Self-hosting overview

Ce contenu n’est pas encore disponible dans votre langue.

Self-hosting means running SpeculaPro inside your own network, on servers you control. Your transaction data never leaves your environment, which is often what a bank’s risk committee or a data protection officer needs before they will approve a monitoring system.

A self-hosted installation is the same software as the SaaS version. It simply has one tenant (your institution) instead of many.

What you run

Section titled “What you run”

A SpeculaPro installation has one application and three supporting services.

Piece What it is What SpeculaPro uses it for
SpeculaPro One container image holding a single program, speculapro, with the web app built into it. See The image and its commands Serving the web app and API, evaluating rules, managing alerts and cases
PostgreSQL 18 A relational database The permanent record: customers, transactions, rules, alerts, cases, audit log
Kafka or Redpanda A durable event log (“message bus”) Moving events between parts of SpeculaPro in order, without losing any
Redis or Valkey An in-memory data store Fast counters for rules (“how much did this account receive in the last 24 hours?”), the answers to repeated decision requests, rate limits
ClickHouse (optional) An analytics database A second, rebuildable copy of transactions, decisions, hits, alerts and cases for long backtests and the 24-month Analytics page. SpeculaPro works fully without it. See Analytics store

You do not need Node.js, a separate web server or a separate frontend deployment in production. The web app is compiled into the program, and you don’t build anything yourself: you receive a signed container image.

Docker Compose and the Helm chart are the two packaged ways to deploy it. Because it is one program in one image that carries everything, it also runs under any container runtime or from plain Kubernetes manifests, such as kustomize, with the roles split by SP_ROLES. The first workspace is created from the command line, with speculapro tenant create, because a new installation has nobody who could sign in yet.

How the pieces talk to each other

Section titled “How the pieces talk to each other”
  1. Your core banking system or payment platform sends transactions to SpeculaPro (over the API, a Kafka topic, or files).
  2. SpeculaPro puts each event on Kafka, keyed by customer or account so events for one customer are always processed in order.
  3. Background workers read from Kafka, update counters in Redis, evaluate rules and write results to Postgres in batches.
  4. Analysts use the web app, which reads from Postgres through the API.

Postgres is never written to on the real-time decision path, which is how SpeculaPro keeps decisions fast. Redis holds only derived numbers, never the record; keep it highly available with persistence on, because there is no command to refill it (see Redis / Valkey). See Architecture for the full picture.

Roles: one binary, several jobs

Section titled “Roles: one binary, several jobs”

The binary can run several roles. A small installation runs them all in one process; a large one runs each role on its own machines and scales them independently.

Terminal window
speculapro run --role=all          # everything in one process
speculapro run --role=api          # just the web app and API
speculapro run --role=ingest,persist   # a comma-separated mix
Role Job Status
api Web app, case management, configuration API Available
ingest The ingest API for transactions, customers, accounts, account events and FX rates Available
persist Batch writer from Kafka into Postgres. See Persister Available
worker Partition maintenance, idempotency-key clean-up, notifications, webhooks, scheduled rules, daily CTR drafts, backtests, sanctions-list fetching and screening, risk-model training, the retention purge and licence housekeeping. See Worker Available
stream Updates the running totals rules need, evaluates the enabled rules on every transaction and turns hits into alerts. See Stream evaluator Available
decision The real-time decision API: allow, step-up, review or block before a payment goes through Available
connector Reads institution Kafka topics, SFTP / S3 file drops and change data capture sources. See Connector Available
analytics Optional. Fills the analytics store (ClickHouse) for long backtests and the 24-month Analytics page. Runs only where SP_CLICKHOUSE_URL is set Available (optional)

all means the seven standard roles, plus analytics where the analytics store is set up. How to split them across machines is covered in Running roles.

Sizing

Section titled “Sizing”

These are starting points. They will be revised once pilot institutions provide real volumes.

Small Large
Typical institution A fintech or PSP up to a few hundred transactions per second A bank or large mobile money operator, thousands of transactions per second
SpeculaPro 1–2 nodes running --role=all Separate node groups per role, scaled independently
Postgres One primary with a streaming replica Pigsty cluster (Patroni for failover) with read replicas; which connections may go through PgBouncer differs by role
Kafka/Redpanda 1 node is acceptable; 3 recommended 3+ brokers, replication factor 3
Redis/Valkey One node, or Sentinel (1 primary, 1–2 replicas, 3 sentinels) Sentinel, or Cluster for the highest volumes
Packaging Docker Compose Helm on Kubernetes

The engineering targets the platform is designed for are 5,000 transactions per second sustained and 15,000 at peak, with a p99 decision latency of 50 ms or less. See Scaling and performance.

What to install

Section titled “What to install”

For running SpeculaPro:

  • PostgreSQL 18 or later. Earlier versions will not work: the schema uses the built-in uuidv7() function introduced in Postgres 18.
  • Kafka or Redpanda. Any recent version. SpeculaPro talks the Kafka protocol, so either works.
  • Redis or Valkey. Standalone, Sentinel or Cluster.
  • ClickHouse, only if you want the optional analytics store.

You don’t need Go, Node.js or the source code: those are only for building from source, which SpeculaPro’s own engineers do.

Where to go next

Section titled “Where to go next”
  1. The image and its commands: what you receive, and how to verify the release before you deploy it.
  2. Choose how to run it: Docker Compose on one server (also the quickest way to try it on a test server), or Kubernetes with Helm.
  3. Encryption keys: read this before you store any real data.
  4. Licensing: how the licence works, and why it can never stop your monitoring.
  5. Configuration reference: every setting, with its default.
  6. Production checklist: everything to check before go-live.

Running a hosted service in more than one region? See Running more than one region. A self-hosted installation is a single installation and needs none of it.

Section titled “Related”