Deployment & White-Label

Enterprises do not clear shared clusters or cosmetic branding exercises. Compliance teams need to see where workloads run, how identities are governed, how evidence is captured, and how easily they can take the keys. This chapter distills the deployment and white-label options that already exist in the codebase and high-level documentation, keeping the focus on what matters to decision-makers rather than deep implementation detail.

Procurement sees real controls, not another slide deck, and that changes the tone of every diligence meeting.

Deployment choices that pass review

ATK supports three delivery patterns that all run the same code and APIs:

White-label and UX control without rework

• The Next.js application (kit/dapp) ships with a theming system, design tokens, and brand packs described in the UI Component documentation, so new tenants can deliver a branded portal without rewriting screens.
• Helm ingress values let you point custom domains, certificates, and CDN strategies at every surface (public dApp, APIs, Hasura, block explorer) while keeping TLS termination and routing under your policies.
• Portal APIs and webhooks remain consistent across deployments, letting partners embed flows or build their own UIs while keeping the regulated functions inside your controlled environment.

Infrastructure building blocks you can swap or extend

• The default charts provision Hyperledger Besu nodes, Blockscout, and supporting services, but you can switch images, storage classes, or cloud primitives through values overrides without touching code.
• Tooling such as kit/charts/tools/aws-marketplace-automation.ts and the environment hierarchy in the documentation cover promotion paths from local through staging to production, including feature-branch environments when needed.
• Observability comes bundled: Prometheus, Grafana dashboards (including Besu-specific views), Loki/Fluent Bit log pipelines, and alert routing are wired in so operational evidence lands in your SIEM from day one.

Security, identity, and audit guardrails

• Secrets and credentials are handled through Kubernetes secrets and external stores; the charts expose hooks for OIDC integration (e.g., MinIO identity settings) and network policies to enforce least privilege between pods.
• The dApp and REST API backend (OpenAPI-documented and implemented in the orpc module) already model OAuth flows, multi-factor checks, and granular role validation, so you can integrate with existing identity providers instead of bolting on custom auth late in the project.
• Every component emits structured logs and metrics; streaming those into your SIEM or observability stack gives compliance teams the audit trails they expect without extra development.

Operational readiness and migration paths

• The CI command bun run ci packages formatting, contract compilation, code generation, linting, and testing. That same workflow underpins Console deployments and your own pipelines, creating a single definition of "ready for release."
• Automated backups, disaster-recovery playbooks, and capacity guidance in the deployment documentation shorten the time from procurement to production because the answers to RTO/RPO and scaling questions are already documented.
• Moving between models is a configuration exercise: Compose for development, Helm for self-managed clusters, and Console for managed service all rely on the same contracts, database schema, and REST endpoints defined by the OpenAPI catalog. That portability is what lets institutions start in the cloud and bring the stack in-house when mandated.

Bottom line: The Asset Tokenization Kit is deployable market infrastructure. Own the runtime, brand the experience, and every subsequent chapter (user experience, regulatory coverage, liquidity) builds on a platform you already control.