Infrastructure plan

This page lists what has to be in place to run DigiFIR: a developer machine for the full stack, and for the pilot a set of Kubernetes clusters hosted in India with HSMs and the platform services the manifests expect.

A development machine

Need	Detail
Operating system	Linux or macOS with bash 3.2 or newer
Containers	Docker with Compose v2; give Docker 4 GB of memory
Measured host	4 CPUs, 16 GB RAM (Linux, Docker 29)
Network	27 containers using about 1 GB of memory after the smoke test; no internet access needed inside the containers
Backend	Node.js 22.12 or newer, openssl; Dart 3.13 for the Dart SDK
Chaincode	Go 1.27.3 (the module pins it; an older Go fetches it with GOTOOLCHAIN)
Apps	Flutter; Android Studio or Xcode for device builds
Kubernetes rehearsal on kind	About 7 GB of memory for the full development topology (k8s.sh dev-up)

Every image is pinned by digest. A missing one is pulled through mirror.gcr.io, so Docker Hub's rate limit does not matter.

Pilot clusters

Cluster	Owner	Runs
Ordering	National platform (NIC / NBF)	Orderer CA and three orderers in three zones, hlf-operator, monitoring
Backend	National platform, a second cluster	api, projector and worker; PostgreSQL, Redis and object storage; the console
State A police	State A	CA, two peers, two CouchDB, four chaincode servers, hlf-operator, monitoring
State B police	State B	The same
Judiciary	High Court / eCommittee	The same, with a second peer for availability
Forensics	State forensic science laboratories	The same, with a second peer for availability

Each cluster needs:

• Kubernetes 1.36 or newer (the manifests are validated against 1.37);
• a CNI that enforces NetworkPolicy and encrypts pod traffic (WireGuard or IPsec);
• a StorageClass digifir-fabric: encrypted at rest, Retain reclaim policy, volume expansion, CSI snapshots;
• Istio with an ingress gateway labelled istio: ingressgateway;
• kube-prometheus-stack in the monitoring namespace;
• the images of versions.env mirrored into a registry hosted in India.

Node sizing

Requests and limits from the Kubernetes base manifests:

Component	CPU request / limit	Memory request / limit	Pilot volume
Peer	250m / 2	512 Mi / 2 Gi	200 GiB (blocks, private data, transient store, snapshots)
CouchDB	100m / 1	256 Mi / 1 Gi	100 GiB (world state)
Orderer	100m / 1	256 Mi / 1 Gi	100 GiB (blocks and the Raft log)
Fabric CA	50m / 500m	64 Mi / 256 Mi	10 GiB
Chaincode server	50m / 1	64 Mi / 512 Mi	None
Backend api	250m to 500m / 2	512 Mi / 1.5 to 2 Gi	None; 2 to 10 replicas
Backend projector, worker	250m to 500m / 2	512 Mi / 1.5 to 2 Gi	None; 2 replicas each

These are starting values for a pilot of two or three districts in two states. They have to be confirmed with a load test on the pilot's own hardware.

Data stores for the backend

Store	Pilot choice	Notes
PostgreSQL 16	Managed or self-run, in India	TLS with sslmode=verify-full; four schemas: read models, operational data, identity vault, audit log
Redis 7	In India	TLS (rediss://); rate limits, job queues, event fan-out
Object storage	Ceph RGW or NIC object storage	S3-compatible; versioning; object-lock legal holds for evidence while its keys exist
Log store	India-hosted, write-once after 24 hours	CERT-In access logs for 180 days, audit exports

HSMs

Each institution needs its own HSM partition (FIPS 140-2 Level 3 in the pilot), and the backend needs one token per institution for that institution's gateway and document keys, plus one for its own keys.

Keys in the HSM	Used by
Fabric CA root keys	Each institution's CA. The CA must run outside the hlf-operator, which can generate CA keys only in software.
Peer and orderer signing keys	The peer and orderer images rebuilt with PKCS#11 from the pinned Fabric source
MSP administrators' keys	Smart cards, used through the admin-sign tool
Gateway keys, service keys, token-signing key, vault and document key-encryption keys	The backend

TLS keys stay in files, because Fabric reads TLS keys only from files. The PKCS#11 path is proven on the development network with SoftHSM 2.6.1: the judiciary's CA and peer generate and use their keys in tokens, and the smoke test passes. A hardware HSM has not yet been used.

Hosting requirements

• Hosted in India: a State Data Centre, NIC MeghRaj, NBF, or a MeitY-empanelled cloud.
• Clocks synchronised with chrony to time.nplindia.org and samay1.nic.in. The backend refuses to start with a clock offset above one second, and the peers refuse transactions more than 120 seconds from their clock.
• Logs of every system kept in India for 180 days, and incidents reported to CERT-In within 6 hours.
• A gov.in domain, and GIGW 3.0 and CERT-In audit clearance before go-live.

Outside services the pilot connects to

The backend reaches these through its egress gateway: Google Play Integrity and FCM, the NIC SMS gateway with a TRAI DLT sender, the NIC mail relay, DigiLocker / Meri Pehchaan, a CCA-licensed eSign provider, eCourts, CCTNS, ICJS, e-Sakshya, e-Forensics, an India-hosted geocoder and the CERT-In log store. External systems gives the approvals and lead times.

Sources: digifir-network README.md, docs/KUBERNETES.md, docs/HSM.md, docs/EGRESS.md, deploy/k8s/base/; digifir-backend README.md, deploy/helm/README.md, docs/architecture/BACKEND.md sections 5, 15.3 and 15.4, docs/PLAN.md section 6.