> 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/managed-service.md). # Managed Service In the managed model Tieto hosts and operates the platform, and the customer consumes it as a service. The software is identical to the on-premises deployment — what differs is who runs it. ## What Tieto operates | Area | Included | | ------------------------ | ----------------------------------------------------------------------------------------------------------- | | Infrastructure | Hosting, capacity, networking and the container platform | | Supporting services | The SQL database, search clusters, secret store and mail service the platform depends on | | Platform operations | Deployment, configuration, scaling, upgrades and recovery, driven by the platform's own Kubernetes operator | | Monitoring | Availability and performance monitoring of the interface, and of the bank health probes behind it | | Maintenance | Platform releases, security patching and dependency currency | | Secrets and certificates | Secret storage and the platform-issued certificate lifecycle | Nothing on the [infrastructure list](/deployment/on-premises.md) is yours to provide, procure or operate in this model. ## What the customer retains Control of everything that is commercially or regulatorily theirs: tenant and third-party onboarding, subscriptions, limits and tariffs, consent oversight, developer portal content, and the publication and versioning of API products. Those are administrative functions in the portals, not infrastructure tasks, so they do not change between deployment models. The bank still implements and operates its own SCA and Core interfaces. Those systems remain in the bank's estate in either model — the platform integrates with them, it does not absorb them. ## Why choose it * **Time to market.** No infrastructure procurement, no cluster build, no operational runbook to write before the first API is published. * **Regulatory currency without project overhead.** Berlin Group releases and national profile changes arrive as platform updates. * **Predictable operations.** Availability and performance monitoring, the statistics behind fallback exemption, and the audit trail are all operated as part of the service. * **Smaller operational footprint.** No requirement to run and maintain a Kubernetes platform, a search cluster, a secret store, a mail service and a database estate for this purpose alone. ## Considerations The managed model suits institutions comfortable with a hosted arrangement for this workload. Where data residency, internal governance or an existing operational model requires the platform to run inside the institution's own estate, [on-premises](/deployment/on-premises.md) delivers the same platform under the customer's control. High availability and disaster recovery topologies, environment separation between sandbox and live, and retention periods are agreed as part of the service definition. Specific hosting regions, service levels and commercial terms are set out in the service agreement. --- # 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/managed-service.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.