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), 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 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 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:
If you operate a managed service that should be a customer-provided substitution for installs running on Tensor9, contact us.