Logical view
Components
Application layer
The workers are several independent services, one per capability, so capacity can be
sized per workload. In the shared models this is invisible to you. In a self-hosted
install they are deployed as two Helm releases: one for the request-serving services and
one for the asynchronous workers.
Data layer
Every stateful dependency can run self-hosted with a compatible component, and Galtea
recommends the cloud provider’s managed service wherever one exists. The platform does not
care which you choose: it speaks standard PostgreSQL, the S3 API, AMQP and the Redis
protocol, so a compatible self-hosted component works and is supported.
The recommendation is about who carries the operational risk. With a managed service, backups
and point-in-time recovery, patching, failover and storage growth are the provider’s problem.
Self-hosted, they are yours, and in practice a self-run database or object store is the most
common source of data-loss and downtime incidents in a customer-operated install. If your
policy or your cost model requires self-hosting, do it, but plan the backup and restore
testing explicitly.
Note on the broker and the cache. These two are the exception to the recommendation: the
Galtea charts deploy RabbitMQ and Redis in-cluster by default, and that is the tested path. They hold
queues and transient state, not your data, so losing them costs queued jobs that can be re-run
rather than records. Pointing them at a managed equivalent is supported if you prefer it.
Object storage carries one requirement that is easy to miss: browser uploads go directly
from the user’s browser to the store using a short-lived signed URL, so the network your users
sit on must be able to reach that endpoint. This applies to a managed service and a
self-hosted one alike.
External dependencies
Kubernetes requirements (self-hosted and private tenant)
Optional components, off by default, each behind a single switch:
- Horizontal autoscaling driven by queue depth
- Node autoscaling
- Automatic pod restart on secret change
- A service mesh for in-cluster mutual TLS
Recommended for anything you run yourself
Not required to install, and strongly recommended before you put real load through the platform, because without them a failed asynchronous job is invisible until someone notices a missing result:
Galtea’s own environments run all three, and a Galtea-operated deployment includes them. In a
self-hosted install they are yours to deploy, and skipping them is the single most common reason
an incident takes hours instead of minutes. Budget cluster capacity for them: the search store
in particular is not small.
What is deliberately not in the picture
- No agent inside your network, in any model where the platform is reachable over HTTPS. Automation talks to the API using the SDK or the CLI. The exception is a private tenant with private-only access, where reaching the platform means running a NetBird client, a routing peer or the operator on your side.
- No inbound connection from Galtea into your network for the platform to function. Traffic toward your product endpoints is outbound from the platform, with you as the server. In model 4 you issue Galtea scoped, revocable credentials to your cluster, which is the one case where access runs in that direction, by design and under your control.
- No model training on your data by Galtea. Your data is used to run the tests you define. Because inference runs through LLM providers, what governs training on submitted data is the terms of the provider account in use: Galtea’s enterprise terms in shared SaaS, your own account and terms in a private tenant or self-hosted install.