Challenge
Owning the platform that runs the bank
For a retail bank serving millions of customers, reliability isn't a feature. It's table stakes. Any outage, delay, or inconsistency is immediately visible to customers and directly affects trust. Sustained downtime also draws regulatory attention, with banking authorities expecting notification after roughly 15 minutes of disruption.
Historically, DKB ran only its development environments internally. Integration and production systems were operated by an external service provider. For a regulated institution, that arrangement carried a real cost. Operational ownership is closely tied to digital sovereignty, and running critical banking infrastructure through outside operators limited DKB's ability to control its own processes, enforce consistent standards, and see directly into how its systems behaved.
At the same time, provisioning on AWS had grown fragmented. Different teams and services stood up infrastructure their own way, which made consistency, security review, and change control harder as the bank's digital footprint expanded.
The problem was not adopting Kubernetes. It was standing up an operational platform that could:
Standardize how teams provision and own infrastructure on AWS across services
Reliably support customer-facing banking workloads at national scale
Enable teams to ship changes safely, repeatedly, and in a way that can be reconciled.
Meet regulatory requirements, allowing full auditability, security, and resilience
As the platform grew, several classes of workloads converged on the same foundation: Online Banking for millions of customers, internal systems such as fraud detection and credit approval, and shared developer tooling including a self-hosted GitLab. Each needed strong isolation, but also consistency. Without clear platform boundaries and automation, operational risk would scale faster than delivery.
The central question became how to give development teams self-service infrastructure while keeping centralized control, visibility, and operational discipline, without ever exposing customers to unnecessary risk.
Solution
A self-operated banking platform on the Upbound Platform
DKB approached this as a platform engineering initiative, not a Kubernetes migration. The bank built its platform on the Upbound Platform and CNCF projects end to end. Kubernetes and its APIs provide the foundation, Flux delivers changes continuously from Git, and Upbound Crossplane is the integral layer on top, serving as the infrastructure control plane and the source of the APIs DKB's teams consume. DKB started with open source Crossplane v1 and community providers before moving to Upbound as it scaled into production.
The Upbound Platform is the enterprise platform for building, operating, and scaling intelligent control planes across any environment, with a unified console, centralized governance, built-in policy enforcement, and developer self-service. Upbound Crossplane is the production-hardened control plane engine that extends Kubernetes with declarative infrastructure APIs, backed by enterprise tooling, security, and support. DKB runs on Upbound's Business Critical offering, built for regulated and sensitive industries. The bank deploys the platform into its own AWS environment, so control planes, data, and access stay inside the bank's boundary. Moving to Upbound also opened DKB's path to Crossplane v2, through capabilities such as Spaces and improved providers for Amazon RDS and other services.
Treating Kubernetes as long-lived operational infrastructure rather than a per-team runtime, DKB uses Upbound Crossplane 2.0 to expose bank-approved, Kubernetes-native infrastructure APIs to its application teams. To standardize provisioning on AWS, those APIs are built on Upbound Crossplane compositions and Upbound Official Providers for AWS, which allows us to control the integrity of our packages using SLSA. Developers request infrastructure through these abstractions. Platform teams retain control over standards, compliance, and the full lifecycle behind them. The operating principle is simple: you build it, you run it, with strong platform guardrails underneath.
The platform follows a GitOps model end to end:
Kubernetes provides a consistent runtime and API surface across every environment.
Upbound Crossplane 2.0 extends Kubernetes with cloud infrastructure APIs, so infrastructure is defined, governed, and reconciled declaratively.
Flux continuously reconciles desired state from Git, keeping environments consistent, auditable, and recoverable.
Several architectural decisions define the platform:
Standardized APIs. Upbound Crossplane compositions provide higher-level abstractions that hide cloud-specific complexity while enforcing bank-wide standards.
Everything as Code. Infrastructure and application configuration are versioned, reviewed, and continuously reconciled. If it isn't in Git, it doesn't exist.
Lower cognitive load. A single platform architecture, reused across teams, lowers cognitive load and operational variance.
Environment isolation. Separate Kubernetes clusters for customer-facing services, internal systems, security-sensitive workloads, and dedicated control planes, all following the same design.
Because DKB installs and operates the Upbound Platform on AWS infrastructure it provisions itself, the bank keeps its control planes, data, and access inside its own cloud environment. For a regulated institution where digital sovereignty is not optional, that is the point: DKB offloads the toil of operating control planes at scale to Upbound's software while keeping ownership of the systems that run the bank. Upbound's compliance posture, including SOC 2 Type 2, ISO 27001, and GDPR, supports the controls and evidence a regulated bank must maintain.
"DKB shows what the Upbound Platform was built for. A regulated bank running its own control planes at scale, in production, in its own environment. With Upbound Crossplane as the engine, DKB standardized how the bank provisions and governs infrastructure while keeping full ownership of the systems that run it." Bassam Tabbara, CEO and Founder, Upbound
In 2025, the platform reached a major milestone: DKB's customer-facing Online Banking system entered full production on this architecture. Internal business systems, developer tooling, and rebuilt web applications run on the same foundation.
~6 million retail customers served by DKB's Online Banking platform, in full production since 2025
25,000+ cloud resources managed declaratively and continuously reconciled
~95% of platform workloads managed through the Upbound control plane
~31 Kubernetes clusters running a single, shared platform architecture in DKB's own AWS environment
~90% fewer major incidents caused by infrastructure since migrating to the platform
One platform design reused across Online Banking, fraud detection, credit approval, and internal developer systems
Internal GitLab hosted on the platform, supporting the bank's repositories and artifacts across engineering teams
GitOps end to end: if it isn't in Git, it doesn't exist
Products used: Upbound Platform, Upbound Crossplane (UXP), Upbound Official Providers, Kubernetes, Flux, Helm, GitLab, Zscaler, AWS, Cilium
Overview
DKB AG (Deutsche Kreditbank) is Germany's second-largest direct bank. Every day, roughly 6 million retail customers depend on its Online Banking platform for payments, account management, and transactions. For a bank with no branches, the platform is the bank. When it works, customers trust it. When it stalls, that trust erodes within minutes, and European banking authorities expect to be notified after roughly 15 minutes of disruption.
That standard shaped a decision. Instead of continuing to run critical banking systems through external operators, DKB chose to bring its online banking backend in-house—remaining on the public cloud while taking direct control of operations and access.The goal was operational ownership at national scale: a platform DKB could run itself, with the security, auditability, and governance that regulated banking demands, plus the self-service speed its engineering teams need.
DKB started with open source Crossplane v1 and community providers, and now runs that platform on the Upbound Platform, deployed on Kubernetes in the bank's own AWS environment, as it moves to Upbound Crossplane 2.0. Today it carries DKB's Online Banking in full production, alongside fraud detection, credit approval, developer tooling, and the control planes that govern them all.
Looking Ahead | A foundation that scales with the bank
DKB continues to expand the platform to new services and engineering teams. The architecture is built to grow with the bank's digital services while holding the same operational model and governance principles steady. As adoption widens, the Upbound Platform gives DKB a consistent foundation for both customer-facing systems and internal engineering platforms, so the bank can deliver new capabilities without adding operational complexity.
Why Upbound
The Upbound Platform is the infrastructure platform that runs itself: one AI-native platform to build, run, and govern control planes across your entire estate, ready to serve both the engineers who run it and the AI systems increasingly acting on it. Humans govern, agents consume, and machines execute, all through the same path and under the same rules, with one view of everything running, one API to query it, and one governance model wherever each control plane is deployed. Upbound Crossplane is the production control plane engine at the core of the platform. Self-hosting covers the entire platform, so regulated organizations like DKB get the same capabilities and governance inside their own environment. Upbound is the creator and primary maintainer of Crossplane, a CNCF Graduated project with more than 100 million downloads and adoption by over 1,000 organizations in production worldwide, and of Modelplane, the open source control plane for AI inference.
