Skip to main content
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.
  • 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.
  • 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.
  • 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.

​
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.
  • 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.
  • 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.
  • 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.

​
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 and 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.
  • 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.
  • 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.
  • 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.

​
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 instead: the data stays in their account while the operational load stays with Galtea.