> ## Documentation Index
> Fetch the complete documentation index at: https://docs.galtea.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Prerequisites checklist

> What to prepare for each model, including the values Galtea provides.

What you prepare before a deployment can start, per model. Items marked **\[Galtea]** are
values Galtea provides; request them upfront so you are not blocked halfway through.

The five models in one line: **1** shared
SaaS, **2** the same with dedicated workers and your identity provider, **3** a dedicated cloud
account Galtea operates, **4** your cluster with Galtea operating the platform on it, **5** your
cluster and your team operating it. Full descriptions are in
[Choosing a deployment model](/deployment/choosing-a-model).

## 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 upgrade` against 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](/deployment/installation-examples). The authoritative
command-level version ships with the deployment package.

### Tools and access

* [ ] `kubectl` installed and working against your cluster
* [ ] `helm` 3.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](/deployment/connectivity-reference); write the firewall
  rules from that table

Real sizing depends on evaluation volume and is agreed per deployment.

### 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 `PUT` from 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

### Email

* [ ] 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