What you get
- Your perimeter, your account. Nothing runs in Galtea-operated infrastructure. Your security team owns the network, the IAM and the data governance.
- Galtea operates the platform. Installation, upgrades, configuration and health are Galtea’s, not a runbook your team has to follow.
- Change control as far as your tooling allows. By default Galtea upgrades when a version ships; scheduling it inside your window is the next step; and if you already run GitOps, a release can arrive as a pull request your team approves before anything reaches production.
- Traceability of what is running. Every release is a pinned chart and image version, so what is deployed is always an exact, reproducible reference, and rolling back is deploying the previous one.
- Much less adoption effort than self-hosted, because the part that takes real expertise, running the platform, does not move to your team.
Architecture
How upgrades reach your cluster
Four mechanisms, and you pick the one your change process allows. The first two are what this model exists for; the last two are also available in self-hosted.
Once the environment exists, an upgrade is minutes of work, not a maintenance window measured
in hours.
What Galtea needs from you
This is the part to settle early, because it is the one your security team will focus on.- Credentials to run Helm against your cluster. This is the trade-off at the centre of
this model: the default mechanism is plain Helm, run by Galtea, so Galtea needs working
access to your cluster. Not to your cloud account, and not to your database, but enough to
install and upgrade releases in the platform’s namespaces. Concretely:
- The access should be scoped to the namespaces the platform runs in rather than cluster-admin, and it is your side that issues it, so you decide the scope, the form and the lifetime of the credential, and you can revoke it.
- It can be network-restricted like any other access to your cluster: through your VPN, your bastion or your private endpoint, rather than from the internet.
- Whether it is standing or requested per change, and whether any Galtea engineer holds break-glass access for troubleshooting, is agreed per deployment and written into the contract rather than assumed.
- If standing access is unacceptable to your security policy, the GitOps option in the table above removes it: Galtea proposes the change, your controller applies it, and nobody at Galtea touches the cluster. It requires that you already run ArgoCD or Flux.
- Prerequisites, same as self-hosted. Cluster, database, object storage, ingress and certificates, LLM provider access and an SMTP relay. See Prerequisites checklist.
- Named contacts on both sides for operations and change approval.
Where the data lives
In your cloud account, in your region, under your governance. Galtea does not hold a copy.Limits to know
- Your infrastructure, your bill and your capacity. If the cluster runs out of room, that is a change on your side. Galtea can size it with you but cannot provision it.
- Diagnosis needs your cooperation. Galtea sees what your cluster exposes. If your policy blocks Galtea from reading logs or metrics, incident handling becomes a relay through your team, and slower.
- Your cluster’s constraints become the platform’s constraints. A restrictive network policy, an old Kubernetes version or a locked-down storage class can hold back a release, and resolving that is a joint conversation.
- Not the same as a private tenant. Here you carry the infrastructure work and the cloud cost. If what you actually want is dedicated infrastructure with none of the work, that is model 3.