Prerequisites
Before deploying Conncentric, make sure the following tools and infrastructure are in place.
Bring Your Own Infrastructure
Conncentric follows a Bring Your Own Infrastructure (BYOI) model. You are responsible for provisioning and managing all underlying infrastructure. The platform boundary begins at the Helm chart: you provide a running Kubernetes cluster and a reachable PostgreSQL database; Conncentric runs inside it.
We do not provide Terraform modules, CloudFormation templates, or any other IaC scripts for your environment. Use your organization's own internal, compliance-approved provisioning tools and processes to set up the resources listed below. This ensures your deployment meets your security, networking, and compliance requirements from day one.
Tools You Need
| Tool | Version | What It's For |
|---|---|---|
| kubectl | Track your cluster (within one minor) | Managing your cluster from the command line. |
| Helm | 4.1+ | Installing and upgrading Conncentric |
kubectl has no fixed minimum here. Install the version that matches your cluster and keep it within one minor version of your cluster's control-plane version (the standard Kubernetes version-skew policy). The supported cluster floor is Kubernetes 1.30 (see below), so a cluster on 1.30 wants a kubectl in the 1.29 to 1.31 range, not a newer release pinned ahead of it. See Version Compatibility for the authoritative version matrix across all dependencies.
Infrastructure You Need
Kubernetes
You must provide a running Kubernetes cluster on a CNCF-conformant distribution (version 1.30 or later). We support Amazon EKS (k3s for local development and evaluation only). Other distributions such as GKE or AKS are not validated and are not supported by default; contact Connamara to discuss before you commit to one. See Version Compatibility.
Size the cluster to fit the default deployment's resource requests. The defaults run 2 orchestrator replicas, 4 adapter replicas, and 1 Portal replica. The orchestrator replicas use hard anti-affinity, meaning the scheduler will not place both replicas on the same node, so they require 2 separate schedulable nodes (on a single node the second replica stays unscheduled):
| Component | Replicas (default) | CPU request (each) | Memory request (each) |
|---|---|---|---|
| Orchestrator | 2 | 1.5 cores | 2.5 GB |
| Adapter | 4 | 0.5 cores | 0.5 GB |
| Portal | 1 | 0.1 cores | 0.128 GB |
That is roughly 5 cores and 7 GB of requests, plus your cluster's system overhead and headroom for the short-lived migration and installer Jobs. These are the minimums for a supported production deployment:
| Requirement | Value |
|---|---|
| Kubernetes version | 1.30+ |
| Nodes | 3+ (at least 2 schedulable nodes are required by the orchestrator's hard anti-affinity) |
| Node size | 4 vCPU / 8 GB (recommended) |
Prefer several smaller nodes over one large node. The orchestrator's hard anti-affinity already requires at least two schedulable nodes for HA, and spreading adapter replicas across nodes (soft anti-affinity) isolates their resources, so a busy adapter or a single node failure affects fewer protocol sessions.
These minimums are the supported floor for production. A deployment below the resource requests above, on a single node, or with the replica counts scaled down is an evaluation topology only and is not supported for production: a single node cannot run the two-replica orchestrator, and dropping below the floor gives up the redundancy and resource isolation the platform depends on. Size production to at least the minimums above.
Provision this cluster using your organization's standard IaC tooling (Terraform, Pulumi, CloudFormation, or equivalent). Conncentric has no opinion on how the cluster is created, only that it meets the specifications above.
Smaller footprint for evaluation: to fit a smaller cluster, scale the replica counts down in your values file (orchestrator.replicaCount: 1, adapter.replicaCount: 1). The default rolling-update strategy (orchestrator.rollingUpdate: maxSurge: 0, maxUnavailable: 1) completes on as few as one node, so rolling upgrades are never blocked; during an orchestrator roll, redundancy briefly drops by one replica. If you run a spare control-plane node and want rollouts that never reduce capacity, set maxSurge: 1, maxUnavailable: 0.
Time synchronization
Keep the clocks on your cluster nodes synchronized (NTP, or PTP where you already run it). The platform relies on node time for FIX sequencing and heartbeat timing and for event-log timestamps; uncorrected clock skew produces misleading logs and can disrupt sessions. Time synchronization is part of your infrastructure and is your responsibility.
PostgreSQL
Conncentric stores all its configuration and state in a PostgreSQL database. You need to provision this before installing.
| Requirement | Details |
|---|---|
| Version | 15 or newer |
| Database | One dedicated database (e.g. conncentric) |
| User | A dedicated account with permission to create tables in that database |
| Storage | 20 GB minimum (more if you need long event log history) |
Provide a PostgreSQL 15+ endpoint. We support Amazon RDS for PostgreSQL; other managed services or self-hosted instances are not validated and are not supported by default (contact us to discuss). See Version Compatibility. The platform sets up its own database tables automatically on first start. You do not need to run any SQL scripts manually.
Additional Infrastructure
Some plugins require additional infrastructure in your environment (for example, message brokers, counterparty network paths, or external authentication systems). These prerequisites are plugin-specific; provision them through your own IaC processes and consult the Official Plugins documentation for the exact requirements of each plugin you deploy.
Network Access
Submit the following port matrix to your network and security teams to request firewall rule approvals before deployment.
Plugin-driven traffic (inbound from external systems into adapter pods, or outbound from adapter pods to external systems) varies by plugin and by the specific adapter configurations you deploy. The rows below cover only the platform-level paths that apply regardless of which plugins are installed. For every plugin you deploy, consult the plugin's own documentation for the port profile, protocol, and direction its adapters require, and add those rows to the matrix you submit to your network team.
Ingress (into the cluster)
| Source | Destination | Port | Protocol | Purpose |
|---|---|---|---|---|
| End users (browsers) | Ingress Controller | 443 | HTTPS | Portal web UI access |
| External systems | Adapter pods (via LoadBalancer, NodePort, or Ingress) | 6700-6750 by default (configurable via adapter.networking.portRange) | Varies by plugin | Inbound connections from external systems the plugin supports. Acceptor ports are allocated from the configured range; adjust the range and open it on your firewall to match the plugins you deploy. Defined by the specific plugin's documentation. |
Egress (from the cluster)
| Source | Destination | Port | Protocol | Purpose |
|---|---|---|---|---|
| Orchestrator pods | PostgreSQL database | 5432 | TCP | Configuration and state persistence |
| Adapter pods | PostgreSQL database | 5432 | TCP | Event log writes |
| Adapter pods | External systems the plugins integrate with | Varies by plugin and adapter configuration | Varies by plugin | Outbound connections to the systems each deployed plugin integrates with. Defined by the specific plugin's documentation. |
| Orchestrator pods | OIDC identity provider (issuer) | 443 | HTTPS | Fetch the issuer's JWKS signing keys to validate the JWT presented on every API request. The Orchestrator itself must reach the issuer, not only the browser. |
| End-user browser (not the cluster) | OIDC identity provider | 443 | HTTPS | Interactive sign-in and token exchange happen in the user's browser. Listed for completeness; this leg is not cluster egress. |
| Installer job (if custom bundle configured) | Bundle hosting URL | 443 or 80 | HTTPS/HTTP | Download custom bundle during installation |
| All pods | Container image registry | 443 | HTTPS | Pull platform container images |
Internal (within the cluster)
| Source | Destination | Port | Protocol | Purpose |
|---|---|---|---|---|
| Adapter pods | Orchestrator service | 8080 | HTTP | Lease heartbeats, session claims, plugin/artifact downloads |
| Portal pods | Orchestrator service | 8080 | HTTP | API calls for configuration and monitoring |
| Installer job | Orchestrator service | 8080 | HTTP | Manifest and plugin uploads during installation |
NetworkPolicy (default-deny clusters)
If your cluster enforces default-deny NetworkPolicies, add policies that permit the flows in the tables above. At minimum: pod-to-pod traffic on 8080 within the namespace (adapters, the Portal, and the installer job all reach the Orchestrator), and egress to your PostgreSQL (5432), your container registry (443), your OIDC issuer (443), and any custom bundle host. Pods without a matching allow rule will fail to start or hang on connection.
Support Boundary
Connamara supports the Conncentric platform software (the shipped images, Helm chart, and official plugins) running on the supported platforms and at or above the minimums in this document. If you hit an issue, our support team can help diagnose whether it originates in the platform or in the surrounding environment.
The following are part of your environment and are your responsibility:
- Infrastructure: provisioning and operating the cluster, database, networking, IAM, and compliance controls, and keeping node clocks synchronized.
- Capacity and sizing: running at or above the supported minimums and sizing the database (see Database). Deployments below the minimums, on a single node, or with replica counts scaled down are evaluation topologies and are not supported for production.
- Resource isolation: honoring the pods' resource requests. Adapters hold stateful protocol sessions, so co-scheduling them onto oversubscribed nodes where their requests are not met can drop sessions, which is a capacity issue, not a platform defect.
- Performance: throughput and latency depend on your environment (node sizing, network, database, the counterparty, and your message profile). The platform does not commit to a specific throughput or latency figure; benchmark in your environment and size to your target.
- Custom code: plugins you build with the SDK and custom bundles you author. We support the SDK contract and the official plugins; defects in your custom plugin logic or a malformed custom bundle are yours to resolve.
- Supported path: hand-edited manifests or direct changes to the shipped chart are outside the supported path. The internal local-development authentication mode is not for production; production uses an external OIDC provider (see Authentication).
Helm Chart and Container Images
Connamara provides the Helm chart and a production values.yaml as part of onboarding. These artifacts contain image names, registry coordinates, and version-specific configuration that are not published in this documentation.
Before deploying, confirm you have received the following from your Connamara representative:
| Artifact | What it contains |
|---|---|
| Helm chart | The chart archive (.tgz) or repository URL for your version |
| Production values file | A values.yaml pre-configured with image references, registry coordinates, and recommended defaults for your deployment |
| SDK image | A container image (conncentric/sdk) providing a self-contained build environment for custom plugins. Available through the same registry as the platform images. See Plugin SDK Getting Started. |
Container image access
Platform container images are distributed into your own container registry, which your cluster pulls from using your existing authentication. You populate that registry from the source with an eager one-time mirror. See Platform Images for the mirror procedure and the image pull secret your cluster needs.
This approach means your cluster never needs direct credentials to an external registry, and image access is governed by your organization's standard container registry policies.
See Helm Reference for the complete configuration surface.
Before you install: common gotchas
A few platform behaviors surprise first-time operators. Skim these before your first helm install:
- TCP acceptors (FIX and similar) need a layer-4 LoadBalancer, not the Portal's HTTP ingress. See Networking.
- Metrics require the Prometheus Operator. Enabling
prometheus.serviceMonitorwithout its CRDs installed makeshelm installfail with a "no kind ServiceMonitor" error. See Metrics. - Pre-create the required secrets (database credentials, and the internal API key if you reference an existing Secret) before installing. See Database and Security.