> For the complete documentation index, see [llms.txt](https://doc.api.tieto.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.api.tieto.com/deployment/on-premises.md). # On-Premises The platform can be installed and operated on the customer's own infrastructure, which is the model most often chosen by banks and national infrastructure operators with strict data residency, security or governance requirements. ## Shape of the deployment The platform is a set of microservices grouped into units, each managed by a Kubernetes custom resource and reconciled by the platform's own operator. The operator handles deployment, configuration, scaling, upgrades and recovery, so day-to-day lifecycle management is declarative rather than manual. Orchestration runs on Kubernetes; Red Hat OpenShift is the reference platform. ## What the customer provides | Component | What it is for | What the platform supports | | ------------------ | ------------------------------------------------------------------------------------- | ----------------------------------------------------------------- | | Kubernetes cluster | Runs the platform's units | Any conformant distribution; Red Hat OpenShift is the reference | | SQL database | Operational and business data, one database per unit | Any mainstream relational engine | | Search cluster | Two clusters — one for system logs, one dedicated to the audit trail | Elasticsearch or OpenSearch | | Secret store | Certificates, private keys and credentials | Any vault — AWS Secrets Manager, HashiCorp Vault or an equivalent | | Mail service | Portal notifications: registration, approvals, certificate and subscription events | Any SMTP relay or hosted mail service | | Edge device | Load balancing and TLS termination, where client certificate trust is also configured | Your existing load balancer or ingress | | Object storage | Aggregation SDK plugin artifacts, where aggregation is used | A network volume or an object store | **The platform is deliberately technology-agnostic about all of it.** These are categories of service, not products: it reaches a relational database, a search cluster, a vault and a mail relay through standard interfaces, so you supply whichever ones your organization already runs — and already knows how to size, patch, back up and audit. Nothing on the list has to be procured for this purpose alone, and nothing is licensed through Tieto. Tieto supplies container images and the Kubernetes object definitions. Installation is a matter of preparing the namespace and prerequisites, then applying the custom resource definitions and unit manifests; the platform comes online within minutes of the operator starting, and state can be verified by inspecting the custom resources. ## Availability and resilience High availability and disaster recovery support active-active, active-passive with automatic failover, and active-passive with manual failover. Business services are stateless, so scaling is horizontal, and updates can be applied without an outage window. Deployed to Tieto's recommendations, the configuration supports exemption from the fallback mechanism under the RTS on SCA and CSC — which is usually the operative reason for caring about the availability topology at all. ## What the customer operates The infrastructure and the platform's runtime, including capacity, patching of the underlying stack, backup and restore of the database and search clusters, and the secret store. Retention periods for logs and audit records are configured per record type to the institution's own compliance requirements. Where the deployment is large or the audit volume high, the database can be partitioned chronologically for the largest consent tables, with the partitioning window and retention period configurable. ## Why choose it * **Data residency and control.** Customer data never leaves the institution's estate. * **Alignment with existing operations.** The platform sits inside the same Kubernetes, database, logging and secret-management practices already in place. * **Security governance.** Network placement, certificate trust and access paths are configured to the institution's own standards. * **Customization headroom.** Integration with internal systems beyond the bank's SCA and Core interfaces is unconstrained by a hosting boundary. Where those requirements do not apply, [managed service](/deployment/managed-service.md) delivers the same platform without the operational commitment. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://doc.api.tieto.com/deployment/on-premises.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.