Bank-in-a-Box

Runs in your cluster

Your cluster. Your database. Your keys.

Bank-in-a-Box ships as a Helm chart and signed container images. Your platform team installs it next to the systems it already runs. We never operate it and never see your customers’ data.

Kubernetes
1.26 or later
Database
PostgreSQL 16, or DynamoDB
Packaging
Helm chart, OCI images
Supply chain
cosign signatures, SPDX SBOM
Status
Early access, evaluation mode
Design target
All pods Ready within 10 min on 3 nodes

Topology

What gets installed, and where the lines are.

Everything runs inside the bank's Kubernetes cluster. Inside the bank's cluster: an ingress, the web pods, the API pods and the worker. They use the bank's PostgreSQL or DynamoDB and Kubernetes Secrets, and call the bank's core through the adapter. Outside, the vendor only publishes signed images, an SBOM and the Helm chart, which the bank pulls. There is no connection from the vendor into the cluster. US (VENDOR) Container images signed with cosign SPDX SBOM attached to each image Helm chart values you control No access to your cluster, data or customers. you pull YOUR KUBERNETES CLUSTER · namespace biab Ingress your TLS, your domain web × 2 static banking app 20m CPU · 32Mi api × 2 API + adapter 100m CPU · 128Mi worker × 1 transfers, cleanup 50m CPU · 96Mi Your database PostgreSQL 16 or DynamoDB Kubernetes Secrets DSN, core API key, email credentials Your observability /metrics for Prometheus, logs to your stack Your core Mambu, CDR data holder, or next 5 s timeout adapter Everything runs inside the bank's Kubernetes cluster. Inside the bank's cluster: an ingress, the web pods, the API pods and the worker. They use the bank's PostgreSQL or DynamoDB and Kubernetes Secrets, and call the bank's core through the adapter. Outside, the vendor only publishes signed images, an SBOM and the Helm chart, which the bank pulls. There is no connection from the vendor into the cluster. US (VENDOR) Signed images · SBOM · Helm chart No access to your cluster, data or customers. you pull YOUR KUBERNETES CLUSTER Ingress · your TLS and domain web × 2 banking app api × 2 API + adapter worker × 1 · transfers, cleanup Your database PostgreSQL 16 or DynamoDB Kubernetes Secrets DSN, core API key, email credentials Adapter → your core Mambu, a CDR data holder, or the next adapter we build
Resource figures are the chart’s default requests. Tune them, pin images by digest, and bring your own ingress class.

Install

Four steps your platform team already knows.

Abridged. The full install guide, deploy/README.md, covers every value, image verification, ingress and store options, and upgrades.

  1. 01

    Verify what you’re about to run

    Every release is signed with cosign and ships an SPDX SBOM as a signed attestation. The public key, cosign.pub, is attached to each release. The full verification commands are in deploy/README.md.

    VERSION=<release tag>
IMAGE=ghcr.io/ryabinski-labs/bank_in_a_box/channel:$VERSION

cosign verify --key cosign.pub "$IMAGE"
cosign verify-attestation --key cosign.pub --type spdxjson "$IMAGE"
  2. 02

    Create your Secrets

    The chart never contains a credential. It references Secrets you create, by name and key.

    kubectl create namespace biab

kubectl -n biab create secret generic biab-postgres \
  --from-literal=dsn="$BIAB_POSTGRES_DSN"

kubectl -n biab create secret generic biab-ses \
  --from-literal=access-key-id="$SES_ACCESS_KEY_ID" \
  --from-literal=secret-access-key="$SES_SECRET_ACCESS_KEY"
  3. 03

    Install the evaluation profile

    Evaluation access is granted on request: we share the chart and signed images with your platform team. The evaluation profile runs a fictional sandbox tenant on localhost with one-click persona sign-in, so no mail server is needed. The production profile, for your own domain and real customers, comes with general availability.

    helm upgrade --install biab deploy/helm/bank-in-a-box -n biab \
  --set profile=simulation \
  --set demo.enabled=true \
  --set origin=http://localhost:8080 \
  --set-file 'tenantConfig.files.tenant\.json=examples/kesef-bank.tenant.json' \
  --wait --timeout 10m
  4. 04

    Wait for ready, then open it

    Readiness checks the database. If PostgreSQL is unreachable, /health/ready returns 503 and the pod stays out of service.

    kubectl -n biab wait --for=condition=Ready pods --all --timeout=10m

kubectl -n biab port-forward svc/biab-bank-in-a-box-web 8080:8080 &
curl -fsS http://localhost:8080/health/ready

Data residency

What stays with the bank: all of it.

DataWhere it lives
Customer accounts, balances, transactions, loans Your core. The adapter reads them live and the API caches them briefly (30 s fresh, 5 min at most, by default).
Sessions, passkeys, transfer operations, audit trail Your PostgreSQL or DynamoDB, through one store interface with the same tests on both.
Core API key, database DSN, email credentials Kubernetes Secrets you create. The chart only references them.
Logs and metrics Your cluster. Prometheus metrics on /metrics. Request logs leave out bodies, cookies, tokens and query strings.
Anything sent to us Nothing. There is no telemetry or call-home in the code: the software makes outbound calls only to your core system, your mail provider and your database. That describes how it’s built, not a third-party audit; you can enforce it with a default-deny egress NetworkPolicy.

Guardrails

Hard to misconfigure on purpose.

  • Demo mode can’t reach production

    The chart has two profiles, customer and simulation. Turning on demo mode in the customer profile fails at render time with demo mode requires simulation profile.

  • Unknown adapters stop startup

    A typo in integration.adapterId exits non-zero with unknown adapterId instead of falling back to something else.

  • Bundled database is demo-only

    The chart can run its own PostgreSQL for our demo cluster. With the customer profile, that option fails rendering: you bring your own.

Want the chart and a sandbox tenant to try in your own cluster?

Ask for an evaluation