Infrastructure & deployment
A dedicated deployment model for each institution.
Every ChainGuard deployment runs on its own isolated database, secrets, network access and provider integrations. It is governed by that institution's own policies, users and roles, without shared tenancy.
Deployment modes
Three decisions to make before go-live.
Each institution chooses how it reads the networks, what runtime isolation it requires, and which providers fall inside its boundary.
Network access
How the deployment reads the ledgers it monitors.
- Bank-provided network access
- ChainGuard-managed network access
- Private Bitcoin node
- Private account-based network node
Isolated runtime
What is dedicated to the institution rather than pooled.
- Dedicated application instance
- Dedicated database
- Dedicated secret set
Provider boundary
Which external relationships the deployment carries.
- Dedicated provider integrations
- Institution-specific provider selection
Architecture
Isolated by design, from the node down to the roles.
One dedicated stack per institution. The diagram below is the deployment boundary, not a marketing abstraction of it.
One dedicated stack per institution. No shared multi-tenant infrastructure.
What isolation means here
Four things that are never pooled.
No shared database
One institution’s customers, cases and evidence never sit in a table alongside another’s.
No shared secrets
Credentials and provider keys belong to the deployment, referenced rather than inlined.
No shared policy
Rules, thresholds and models are configured for the institution that owns them.
No shared identity
Users, roles and permissions are scoped entirely within the deployment.
Scope a deployment architecture for your institution.
Map ChainGuard to your institution’s transaction, policy and evidence workflows.