> ## 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.

# Boundaries: what Galtea does not support

> Every limit on what Galtea supports, collected in one place.

The do-not rules from every deployment page, in one place. Each already lives in its own page
with its full context, and stays there; this page exists so that nobody has to have read
every page to avoid the known failure modes. Format: the rule, then what goes wrong if you
break it.

## Install and configuration

* **Do not rename the `redis` release.** The workers and the APIs are configured to reach
  `redis-redis-ha-haproxy`, a name the chart derives from the release name, so renaming it
  makes every consumer lose the cache with no obvious error.
  Context: [Installation examples](/deployment/installation-examples).
* **In the phased RabbitMQ install, the final release must be named `rabbitmq`.** The
  cluster's generated service name is what the workers and the APIs are configured to reach,
  so a different name leaves them pointing at a service that does not exist.
  Context: [Installation examples](/deployment/installation-examples).
* **On Azure, do not leave a value in `AWS_S3_BUCKET_NAME`.** The workers select S3 over
  Blob Storage by whether that key has a value, so a stale bucket name sends the workers to
  S3 while the API writes to Blob Storage, and uploads appear to succeed and are unreadable
  afterwards. Context: [Installation examples](/deployment/installation-examples).
* **Do not commit your filled-in values or secrets to a Galtea repository.** Nothing you
  fill in belongs in Galtea's hosting; committing it puts your credentials in a repository you do
  not control. Keep your clone in your own Git hosting instead.
  Context: [Installation examples](/deployment/installation-examples).

## Upgrades

* **Do not run the APIs and the workers on different versions.** They share the database
  schema, so a version split is unsupported and fails in ways that look like data bugs
  rather than an upgrade mistake.
  Context: [Installation and lifecycle](/deployment/install-and-lifecycle).
* **Do not run two upgrades concurrently.** The schema migration must not run twice at the
  same time; concurrent runs can leave the schema in a state neither version expects.
  Context: [Installation and lifecycle](/deployment/install-and-lifecycle).
* **Do not jump minor versions on upgrade** unless the release notes state that a jump is
  safe. Migrations are cumulative but tested only between consecutive versions, so a jump
  runs a path nobody has exercised. Context:
  [Installation and lifecycle](/deployment/install-and-lifecycle).
* **Do not upgrade without a database backup you have restored at least once.** A schema
  migration is not automatically reversible, so rolling back a release that included one
  means restoring the pre-upgrade backup, and an untested backup is a hope, not a rollback
  plan. Context: [Installation and lifecycle](/deployment/install-and-lifecycle).

## Scope and environment

* **Self-run PostgreSQL, or a self-run object store, moves backup responsibility to you.**
  Supported, but backups, restore testing, failover, patching and capacity for those
  components become your team's permanent work, and the first unrehearsed restore is where
  data gets lost. Context: [Model 5: Self-hosted](/deployment/model-self-hosted) and
  [Installation examples](/deployment/installation-examples).
* **Clouds other than AWS EKS and Azure AKS are an adaptation, not a run-unchanged
  target.** GKE, OpenShift and other conformant distributions run the same charts once four
  pieces are mapped to their equivalents: object storage, secret storage, workload identity
  and ingress. That mapping is scoped work done with Galtea, typically alongside the first
  install, not something to attempt alone.
  Context: [Cloud-specific details](/deployment/cloud-specifics).
* **Do not run an air-gapped install without a mirroring agreement.** With no path to the
  registry, nothing can pull images or charts; the air-gapped path mirrors both into your
  internal registry and is agreed separately.
  Context: [Cloud-specific details](/deployment/cloud-specifics).
* **Do not penetration-test the shared SaaS without written authorization.** It is
  multi-tenant, so your traffic is indistinguishable from an attack on other customers.
  Against a private tenant or your own self-hosted install, only a window needs agreeing.
  Context: [Security assurance](/deployment/security-assurance).
* **Do not plan around outbound mutual TLS.** It is on the roadmap, not available today, so
  a design that requires your side to cryptographically verify the platform as the caller
  has a dependency with no date. Context: [Security assurance](/deployment/security-assurance).

## Staffing prerequisite

Self-hosted operation assumes named people, not spare cycles: a platform engineer with
production Kubernetes experience who owns the install, the upgrades and the capacity reviews;
DBA time for PostgreSQL, because backups, restore tests and migration windows are recurring
work rather than setup; and on-call ownership for the platform, since Galtea cannot see your
environment and your team is the first responder. Teams that cannot commit those roles
typically choose the [Galtea-managed-in-your-cluster model](/deployment/model-managed-in-your-cluster)
instead: the data stays in their account while the operational load stays with Galtea.