Vendor
A vendor refers to you: a software vendor that seeks to deliver your software into customer environments. Tensor9 BYOC helps vendors like you to package, deploy, and support your application as a Tensor9 BYOC app installed into a customer-controlled environment called an appliance. Your vendor metadata defines your app’s branding, presentation to customers and deployment configuration.Customer
A customer represents your end customer who purchases and runs your Tensor9 BYOC app in their own infrastructure. Customers are organizations such as enterprises, financial institutions, healthcare providers, and other regulated organizations that require software to run securely within their own controlled environments. Each customer is associated with metadata that defines their organization, preferences, and any custom configurations related to their appliances.App
A Tensor9 BYOC app represents the software product that you package and deliver to your customers. An app includes the application code, infrastructure, and any associated services required to run your software in a customer’s appliance. An app is designed to be deployed in customer-controlled environments, allowing customers to run your software securely within their own infrastructure.Appliance
An appliance is a secure, self-contained system that Tensor9 BYOC deploys into a customer’s infrastructure. The appliance runs in the customer’s cloud account or data center while you maintain the ability to deploy, observe, and operate it remotely. Each appliance mirrors your origin stack configuration and provides the necessary compute, storage, and networking resources while ensuring that all data remains under the customer’s control.Install
An install represents a specific app running on a specific appliance.Service adapter
A service adapter lets your app use a service from its origin stack in a different customer environment. For example, an adapter can translate your app’s S3 requests into Azure Blob Storage operations. Depending on the mapping and adaptation tier, Tensor9 BYOC adapts your infrastructure definitions, runtime API calls, or the service’s state and behavior. Each mapping documents the supported operations and differences that affect your app. See How Service Adapters Work for adaptation tiers and examples.Form factor
A form factor defines the environment and constraints in which an appliance runs. It specifies the cloud provider, connectivity, available services and security requirements that the customer’s environment must satisfy. A form factor describes essential attributes such as:- whether the appliance runs in AWS, Azure, Google Cloud, or private;
- whether it is connected to the internet;
- whether managed services like AWS S3, Kubernetes, MongoDB Atlas, or Lucenia OpenSearch are available - as well as which versions are available;
- and any regulatory requirements such as FIPS or CMMC compliance.
Service requirements
Form factors can specify service requirements - the services your app needs to run in that environment. Service requirements can be specified in two modes:- Exact: A single, specific service (e.g., “CloudNative PostgreSQL >= 14.0”)
- OneOf: Multiple options where the customer chooses (e.g., “CloudNative PostgreSQL OR Bring Your Own PostgreSQL”)
Form factor versioning
Form factors are versioned to track how your app’s infrastructure requirements evolve over time. Each version has a status that controls its availability:- Preferred: The recommended version for new installs. Exactly one version is Preferred at any time.
- Active: Supported but not recommended for new installs. New versions start as Active until validated and promoted to Preferred.
- Retiring: Being phased out. Existing installs continue to work, but customers are signaled to upgrade.
- Retired: No longer in use. A version is automatically retired when no installs reference it.
Origin stack
An origin stack represents the original definition of the software, infrastructure, and services that make up your app. The origin stack is defined as infrastructure-as-code (e.g., Terraform/OpenTofu, Kubernetes, CloudFormation) and serves as the source of truth for deployments. Tensor9 BYOC compiles the origin stack into a deployment stack for the customer’s form factor, such as a cloud account or private environment. The origin stack specifies all the infrastructure components (e.g., databases, storage, compute clusters) and configurations that Tensor9 BYOC synchronizes within customer appliances.Deployment stack
A deployment stack is the environment-specific, deployable infrastructure-as-code artifact generated by your control plane from an origin stack. It contains all the necessary service equivalents and configuration adjustments required to deploy an application into a specific form factor. The deployment stack is the final output of the compilation process and is what gets executed by the controller in the target environment to create an appliance.Audit stack
An audit stack is a companion copy of the deployment stack that your control plane produces during compilation, with the Tensor9 BYOC runtime plumbing stripped out. It contains only the application infrastructure the customer is being asked to host - no Tensor9 BYOC Terraform provider, runtime links, or reflection resources - so it can be reviewed with the customer’s standard infrastructure-as-code security, policy, and compliance tooling before the deployment stack is applied. The audit stack is downloaded side-by-side with the deployment stack and is intended for review only, not forapply. See Stack audit for the review workflow.
Stack tuning
A stack tuning document is an optional configuration file that allows you to customize deployment-specific settings without modifying your origin stack. It enables you to adjust parameters like resource allocations (CPU, memory), custom DNS endpoints, and other appliance-specific configurations on a per-release basis. Stack tuning documents allow you to maintain a single origin stack while customizing deployments for different customer tiers, environments, or requirements. For example, you might allocate more resources for enterprise customers or use different endpoints for development versus production appliances.Vendor Portal
The Vendor Portal is a web-based dashboard where you manage your Tensor9 BYOC setup. You can create and configure apps, define form factors with service mappings, generate customer signup links, customize the customer experience, monitor appliance health, configure observability sinks, manage operations templates and commands, handle break-glass sessions, and manage your team. Deployments are handled through the CLI and your CI/CD pipeline.Customer Portal
The Customer Portal is a web-based interface that your customers use to interact with their appliance. It covers the full lifecycle: setting up a new appliance (selecting their environment, applying infrastructure templates, configuring DNS, secrets, and services), and ongoing management (viewing appliance health, reviewing and approving operations requests, viewing deployed infrastructure, configuring release windows, and managing upgrades). The Customer Portal is white-labeled with your branding. Your logo and company name appear in the interface, and your customers see it as part of your product experience.Control plane
Your Tensor9 BYOC control plane is your central management plane hosted within your designated cloud account. It is provisioned directly within your own dedicated AWS account, ensuring that your code, data, and infrastructure credentials always remain under your ownership and control. Your control plane is responsible for orchestrating the entire lifecycle of your applications, from compiling your origin stack into a deployable artifact, to enabling you to manage ongoing operations and observability for every customer appliance.Controller
A Tensor9 BYOC controller is Tensor9 BYOC-provided software that runs in both your control plane and your customer’s appliances. It is responsible for coordinating deployments, observability, and operations between your control plane and your customer’s appliances. When running in your control plane, it manages the origin stack and compilation process. When running in a customer’s appliance, it receives commands, executes actions, and coordinates sending telemetry back to your control plane.Observability sink
An observability sink is a destination your appliance telemetry (logs, metrics, and traces) is forwarded to: Datadog, CloudWatch, Loki, Prometheus, or any OpenTelemetry-compatible backend. You can configure multiple sinks and control which telemetry sources feed each one, per signal (see Telemetry routing). This allows you to use your existing monitoring and analysis tools to get a unified view of your entire fleet of appliances.Operations endpoint
An operations endpoint is a secure API in your control plane that lets you issue remote commands to appliance-hosted resources. It supports both asynchronous operations and synchronous operations, with approval workflows and audit logs so your customers stay in control.Auto-Customization
Auto-Customization is the agreement between you and each customer that shapes their install. At appliance setup time, your customer declares a small set of properties about their environment, and the compiler emits a deployment stack that honors them. Your application code does not change between customers; the same origin stack compiles into a per-customer build. The form factor defines the permitted set of choices, and Auto-Customization is your customer picking from what the form factor allows. Three configuration choices are available:- Ingress posture: how end users reach the deployed application (public, allowlisted, Tailscale).
- Controller connectivity: how the appliance reaches your control plane (public internet, AWS PrivateLink, Tailscale).
- Customer-provided services: which managed services the install uses your customer’s existing instance of, instead of provisioning a default equivalent.