> ## Documentation Index > Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt > Use this file to discover all available pages before exploring further. # How Auto-Customization Works At appliance setup time, your customer declares three properties of their environment. The compiler reads those properties and emits a deployment stack that honors them. Your application code does not change between customers. Your origin stack compiles into per-customer installs. Each customer's install is shaped by the ingress posture, controller-connectivity path, and customer-provided services they declared at appliance setup time. Your origin stack compiles into per-customer installs. Each customer's install is shaped by the ingress posture, controller-connectivity path, and customer-provided services they declared at appliance setup time. | Surface | What your customer asserts | Why customers ask for this | Page | | ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ | | **Ingress posture** | How end users reach the deployed application. | Compliance boundary controls. A public-internet path is disqualifying for many regulated customers; allowlist and Tailscale are the levers their security teams accept. | [Ingress Control](/customizations/ingress) | | **Controller connectivity** | How the appliance reaches your control plane. | Third-party-risk findings. Outbound HTTPS to a third-party SaaS is a common audit finding; PrivateLink (or Tailscale) lets your customer eliminate the public-internet path entirely. | [Controller Connectivity](/customizations/connectivity) | | **Customer-provided services** | Which managed services the install should use your customer's existing instance of, instead of provisioning a default equivalent. | Data residency and existing controls. Your customer's Temporal, PostgreSQL, or MongoDB is already inside their certified perimeter, already on their patch schedule, already in their backup policy. | [Customer-Provided Services](/customizations/customer-provided-services) | Each surface is independent. Common combinations: public ingress + public controller + default services; allowlist or Tailscale ingress + PrivateLink controller + customer-provided PostgreSQL. The full Cartesian product is the design intent; untested combinations are work to validate, not guarantees. ## What stays the same regardless of customer choice These hold for every customer regardless of the choices above: * One codebase. No per-customer forks, branches, or porting. * New features ship to every customer through the same release pipeline. * One operational posture. The deployment stack changes; what you run and support does not. ## What this section is NOT * **Not application behavior.** This shapes the plumbing your application runs on. It does not change what your application does. Your customers cannot turn features on or off through this surface; that is your product roadmap, not this surface. * **Not version selection.** Your customers cannot pick alternate versions of your application or its dependencies. You ship one release per cadence to every customer. * **Not telemetry opt-out.** The appliance-to-controller link is required and carries the operational telemetry you need to support the install. Your customer customizes the *path* (see [Controller Connectivity](/customizations/connectivity)), not whether telemetry flows. * **Not unbounded substitution.** Each customer-provided service is an explicit, named substitution. The currently-supported set is what's documented here; the set is actively expanding as customer requirements drive new substitutions. * **Not a guarantee that every combination has been validated in production.** Composability is the design intent. Untested combinations are work to validate jointly with you and the customer. ## Form factor defines the permitted choices The choices on this page are not freely available to every customer. You author a [form factor](/fundamentals/key-concepts#form-factor) that defines the *permitted* set of choices for a given install template, and your customer (or you on their behalf) picks from what the form factor permits at appliance setup time. The form factor is also a security-review artifact: a customer's procurement team can read it to see every permitted path and substitution their install can use. For FedRAMP-adjacent customers, you might publish a form factor that requires Allowlist or Tailscale ingress and PrivateLink controller; for less-regulated customers, you might leave all three ingress options open with public as the default. ## How this relates to service equivalents [Service equivalents](/fundamentals/service-equivalents) covers the *automatic* substitution axis: the compiler maps RDS to Cloud SQL when the form factor's cloud is GCP. You author one stack against AWS primitives; the compiler emits a GCP-native deployment when the form factor calls for GCP. The substitution is automatic; your customer does not pick. This section covers the *customer-driven* substitution axis: your customer explicitly says "use my Temporal" and the compiler honors that. The two axes compose. A customer on GCP can use the default-shipped Cloud SQL (automatic, form-factor-driven) while bringing their own Temporal (customer-driven). ## Supported third-party auto-customizations Tensor9 supports these third-party services as choices on the corresponding surface in this section: | Service | Supported Variants | Surface | | ------------------------------------ | --------------------------------------------------------------------------------- | ------------------------------------------- | | **Tailscale** | - | Ingress posture and controller connectivity | | **AWS PrivateLink** | Cross-region attachments | Controller connectivity | | **Temporal** | Temporal Cloud, self-hosted | Customer-provided service | | **PostgreSQL** | RDS, Cloud SQL, Aurora, self-hosted | Customer-provided service | | **MongoDB** | Atlas, self-hosted (K8s, VMs) | Customer-provided service | | **Redis** | ElastiCache, MemoryDB, Redis Enterprise, self-hosted | Customer-provided service | | **Valkey** (BSD-licensed Redis fork) | ElastiCache for Valkey, Memorystore for Valkey, self-hosted | Customer-provided service | | **Kafka** | Confluent Cloud, MSK, Strimzi, Redpanda | Customer-provided service | | **Elasticsearch family** | Elastic Cloud, [Lucenia](https://lucenia.io/), OpenSearch, AWS OpenSearch Service | Customer-provided service | If you operate a managed service that should be a customer-provided substitution for installs running on Tensor9, [contact us](mailto:hello@tensor9.com).