Model 1: Shared SaaS
- Users’ browsers and CI runners can reach the platform dashboard and API over HTTPS 443
- Users’ browsers can reach the object storage endpoint over HTTPS 443, for direct file upload
- A decision on how Galtea reaches your AI product under test: a reachable endpoint with an authentication method, or results pushed in from your own pipeline with the SDK
- An owner named on your side for user and role management
Model 2: Enterprise organization
Everything from model 1, plus:- Identity provider protocol decided: SAML or OIDC
- Galtea registered as an application in your identity provider [Galtea provides the redirect URLs and metadata]
- Groups that will map to Galtea roles created in your directory, and the mapping agreed [Galtea provides the role list]
- Your MFA and conditional-access policy confirmed as applying to this application
- Expected evaluation volume shared, so dedicated worker capacity can be sized
Model 3: Private tenant
- Region chosen, for data residency
- Network exposure decided: public with IP restrictions, or private only
- If private only: connection method chosen (per-user VPN client, site-to-site routing peer, private link or peering)
- If site-to-site: a host inside your network available to run the routing peer, and the private ranges to advertise agreed
- Outbound HTTPS 443 from your side to the VPN control plane allowed (no inbound rule needed)
- Your source IP ranges provided, if access is restricted by IP
- Endpoints of your AI product that the platform must call, with hostnames, for the egress allowlist
- Authentication method for those endpoints, and the credentials, to be stored in the managed secret store
- Fixed egress IPs requested, if you need to allowlist source addresses on your side [Galtea provides the addresses]
- Identity: built-in provider, or federation to yours (same items as model 2 if federating)
- LLM inference decided: Galtea’s provider accounts, or your own [if yours: endpoint, credentials and available model set]
- SMTP relay decided: Galtea’s, or your own [if yours: host, port, credentials, sender address]
- Data retention period agreed
- Upgrade window and notice period agreed
- Named contacts on both sides for operations and security
Model 4: Galtea-managed in your cluster
The infrastructure items are the same as model 5 below, because you provide the same things. What is specific to this model:- Cluster credentials issued to Galtea, scoped to the platform namespaces rather than
cluster-admin, because the default mechanism is Galtea running
helm upgradeagainst your cluster. Decide the form, the lifetime and whether it is standing or per change - Network path for that access decided: through your VPN, bastion or private endpoint
- Break-glass access agreed: whether any Galtea engineer can reach the cluster for troubleshooting, and under what conditions
- Change-control mechanism chosen: Galtea upgrades as versions ship, an agreed window, or approval by pull request if you already run ArgoCD or Flux
- Named approvers on your side, if you choose approval by pull request
- Agreed whether Galtea can read logs and metrics from your cluster for diagnosis, and by what route. Without it, incident handling relays through your team and takes longer
- Escalation path and contacts on both sides
- All infrastructure items from model 5 below
Model 5: Self-hosted
Grouped the way the work actually happens. For what the commands look like on AWS and on Azure, see Installation examples: AWS and Azure. The authoritative command-level version ships with the deployment package.Tools and access
-
kubectlinstalled and working against your cluster -
helm3.12 or later, with OCI registry support - Access granted to Galtea’s container and chart registry [Galtea]
- Registry credentials received [Galtea]
Cluster
- Kubernetes 1.28 or later. That is the floor the charts require; Galtea itself runs and tests on 1.34. Pick a version still in upstream support rather than the floor.
- At least 14 vCPU and 28 GB of allocatable RAM of node capacity available for the platform, or 15 vCPU / 30 GB if you deploy the task monitor. This is a floor for one replica of each service, not a sizing recommendation: the charts’ declared requests, summed across every release including the broker, the cache and the gateway, total 11.25 vCPU / 22 GiB, and the scheduler also has to fit system pods and the kubelet reserve
- A storage class with dynamic provisioning, for the broker and cache volumes
- An ingress controller or cloud load balancer
- TLS certificate and DNS record for the dashboard and API hostnames
- Outbound HTTPS 443 allowed to: the Galtea registry, your LLM provider, your SMTP relay, and your AI product endpoints. The complete host-by-host list is Outbound connectivity reference; write the firewall rules from that table
Database
Managed service recommended (Azure Database for PostgreSQL, Amazon RDS, Cloud SQL). A PostgreSQL you run yourself is supported; the backups and the failover are then yours.- PostgreSQL 14 or later, reachable from the cluster
- Two databases created: one for the platform, one for the LLM gateway
- The cluster’s node subnet allowed through the database firewall
- Credentials available for the secret templates
- Backup schedule and retention configured
Object storage
Managed service recommended (Azure Blob Storage, Amazon S3, Google Cloud Storage). A self-hosted S3-compatible store such as MinIO is supported, with the same reachability and CORS requirements below.- Storage account or bucket and container created
- Access granted to the platform: workload identity preferred, key-based access acceptable
- The network your users sit on can resolve and reach the storage endpoint. Uploads go directly from the browser using a signed URL. Missing this makes file upload appear to hang. If your policy forbids browser-to-storage connections, raise it early: an upload path through the API is on the roadmap, ask for its current status.
- CORS configured on the storage account to allow a cross-origin
PUTfrom your dashboard origin
LLM provider
- A model provider account with the models you will use. The package ships configured for Azure OpenAI out of the box, regardless of which cloud you deploy on, and any provider can be connected through the LiteLLM gateway configuration [tell Galtea which provider and models before the deployment is designed]
- Endpoint URL and API key available
- If your approved model set differs from the default, the substitute models identified so the gateway configuration can be adjusted [Galtea reviews the substitution]
- Quota confirmed as sufficient for your expected evaluation volume
- SMTP relay available: host, port, credentials, sender address
- The sender domain authorized to send, so invitations do not land in spam
Optional
- KEDA installed, if you want worker autoscaling on queue depth
- A secret operator, if you do not want plain Kubernetes secrets
- A service mesh, if you want mutual TLS between platform services
- A monitoring stack able to scrape Prometheus metrics and receive OpenTelemetry traces
Before go-live
- A restore from backup tested successfully
- One evaluation run end to end, with a file upload, from a browser on your users’ network
- Alerting configured on at least queue depth, job failure rate and database saturation
- The platform version you are running recorded, so a support request can reference it