> 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.md). # Deployment Run the platform on your own infrastructure or consume it as a managed service operated by Tieto. The same software, under different operational ownership. Two operating models, one platform. The software, the portals and the APIs are identical; what differs is who runs the infrastructure.
Managed ServiceHosted and operated by Tieto — infrastructure, deployment, upgrades, monitoring and maintenance. Fastest route to a published API.
On-PremisesInstalled on the customer's own infrastructure and orchestrated on Kubernetes, with data residency and security governance retained in full.
| | | | ------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | | [Managed Service](/deployment/managed-service.md) | What Tieto operates, what the customer retains, and when the model fits | | [On-Premises](/deployment/on-premises.md) | The deployment shape, what the customer provides, resilience topologies and operational responsibilities | ## Choosing between them | | Managed Service | On-Premises | | ---------------------------------------- | ------------------------- | -------------------------------------- | | Infrastructure | Tieto | Customer | | Platform upgrades | Included in the service | Applied by the customer, declaratively | | Data residency | Per the service agreement | Entirely within the customer's estate | | Time to first published API | Shortest | Dependent on infrastructure readiness | | Tenants, subscriptions, tariffs, content | Customer | Customer | | Bank SCA and Core interfaces | Bank | Bank | The last two rows matter most. Administrative control of the platform stays with the customer in both models, and the bank's own SCA and Core systems remain in the bank's estate either way — the platform integrates with them, it does not absorb them. ## What you provide The platform runs on five kinds of supporting service. On-premises you supply them; as a managed service Tieto does. | Service | Purpose | Managed Service | On-Premises | | ------------------ | -------------------------------------------------------- | --------------- | ----------- | | Kubernetes cluster | Runs the platform's units | Tieto | Customer | | SQL database | Operational and business data | Tieto | Customer | | Search cluster | System logs and the audit trail | Tieto | Customer | | Secret store | Certificates, private keys and credentials | Tieto | Customer | | Mail service | Portal notifications to administrators and third parties | Tieto | Customer | Each of these is a **category of service rather than a named product**. Any mainstream SQL engine, Elasticsearch or OpenSearch, any vault, any SMTP relay — the platform reaches them through standard interfaces, so you use what your organization already runs, already backs up and already knows how to audit. Nothing on the list has to be procured for this purpose alone, and nothing is licensed through Tieto. [On-Premises](/deployment/on-premises.md) carries the full list, including the edge device and, where aggregation is used, storage for Aggregation SDK artifacts. ## Common to both 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 apply without an outage window. Sandbox and live are separate environments throughout, with independent policies, channels and statuses. Configured to Tieto's recommendations, either model supports exemption from the fallback mechanism under the RTS on SCA and CSC. --- # 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.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.