Prerequisites
The CCV Starter Kit is a brownfield kit: it deploys into a Kubernetes cluster and stateful services you already run, rather than provisioning new infrastructure. You bring the cluster, the database, the secret store, and the ingress. This page assumes you already operate production Kubernetes, TLS, gRPC ingress, secret management, and a production database. If you do not, set them up first.
Platforms and dependencies
Secret stores
Signer key custody (KMS)
AWS KMS
Cloud KMS signer on AWS.
GCP KMS
Cloud KMS signer on Google Cloud.
Azure Key Vault
KMS signer on Azure.
Coming soonYou provision each dependency below with your cloud's own tooling; the table links the vendor docs. The off-chain kit's Prerequisites and Configure documentation has the field-level detail.
Dependency matrix
| Dependency | What the kit needs | Per-cloud vendor doc |
|---|---|---|
| Kubernetes cluster | A conformant cluster on a supported version | GKE / EKS / AKS getting-started, or any conformant on-premise Kubernetes |
| Managed Postgres | Postgres 15+ over TLS, reachable from inside the cluster | Cloud SQL / Amazon RDS for PostgreSQL / Azure Database for PostgreSQL |
| Secret store | A store the chart references and mounts (five backends) | GCP Secret Manager / AWS Secrets Manager (ASCP) / Azure Key Vault (AKS CSI) / External Secrets Operator |
| Workload identity | Keyless pod access to your secrets and KMS | GKE Workload Identity / EKS IRSA or Pod Identity / Microsoft Entra Workload ID |
| Signer key (KMS) | Optional cloud KMS for the signer key, recommended on a managed cloud; the Postgres keystore holds it otherwise | GCP KMS / AWS KMS / Azure Key Vault KMS signer (coming soon; use the Postgres keystore) |
| Ingress for gRPC | TLS-terminated, HTTP/2 and gRPC end to end, a stable public hostname | GKE Gateway / AWS Load Balancer Controller / Azure Application Gateway for Containers; on-premise MetalLB with Envoy Gateway |
| RPC per source chain | Multiple independent providers with failover, not a single endpoint | RPC requirements |
| On-chain contracts | The resolver, committee-verifier addresses, and selectors (deploy them first) | The CCV on-chain contracts kit book |
Postgres databases
The cell keeps its state in separate logical databases on your Postgres server, one per component. Two always
exist: an aggregator database for the aggregator's state, and a verifier database for the verifier's state.
With the default Postgres keystore, the verifier generates its signing key on first boot and stores it in a
third bootstrapper database, so your Postgres backups then contain the signing key. Point the keystore at
cloud KMS instead and the signing key lives in KMS, never in Postgres. See
Signer key custody and KMS for that choice. Create
the databases your configuration uses and give each component its own connection string; those strings are part
of the secrets covered in Choose a secret backend.
Certificate: use a publicly trusted CA
The aggregator's TLS certificate must be issued by a publicly trusted certificate authority. The clients are your peer verifiers and the CCIP indexer, and neither trusts your private CA. A certificate from a private or internal CA passes every check you run against your own cell and fails only when a peer or the indexer connects. A Google-managed certificate, cert-manager with an ACME issuer such as Let's Encrypt, or a certificate bought from a public CA all work.
RPC providers
Give each cell its own RPC providers, with more than one per chain for failover. Each provider should meet Chainlink's RPC requirements: independent providers, no rate limits, and the performance SLAs. Cells in a committee must not share a provider; Scale to a committee explains why.
Local development only
The off-chain kit ships a local/ folder for experimentation only: a docker-compose stack you can run anywhere
Docker and docker-compose are available. Use it to try the cell out, not to run it for real. Production is
bring-your-own for every dependency above.