Skip to main content

​
Vendor

A vendor refers to you: a software vendor that seeks to deliver your software into customer environments. Tensor9 helps vendors like you to package, deploy, and support your application as a Tensor9 app installed into a customer-controlled environment called an appliance. Your vendor metadata defines your branding, deployment setup, and configuration. This metadata helps you deliver a seamless experience by customizing how your app is presented to customers and how they are managed through Tensor9.

​
Customer

A customer represents your end customer who purchases and runs your Tensor9 app in their own infrastructure. Customers are organizations such as enterprises, financial institutions, healthcare providers, and other regulated industries 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 app represents the software product that you package and delivers 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 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. When you install an app onto an appliance, you create an install - the manifestation of your app deployed and running in a customer’s environment.

​
Form factor

A form factor defines the environment and constraints in which an appliance runs. It specifies the cloud provider, connectivity level, managed service availability, and security requirements - ensuring that the vendor’s app adapts to the customer’s infrastructure while meeting operational and compliance needs. 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”)
OneOf requirements give customers flexibility to use their preferred service equivalent while ensuring your app’s needs are met.

​
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.
When you create a new form factor version, existing installs stay pinned to their original version until explicitly upgraded. This ensures stability for your customers while allowing you to evolve requirements over time.

​
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 builds a deep understanding of the origin stack in order to manifest it across different form factors, such as cloud accounts or private environments. The origin stack specifies all the infrastructure components (e.g., databases, storage, compute clusters) and configurations that Tensor9 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.

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

​
Control plane

Your Tensor9 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 controller is Tensor9-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 the destination where all telemetry data (logs, metrics, and traces) from your appliances is sent. Your control plane forwards this data from each appliance to your preferred sink, such as Datadog, New Relic, CloudWatch, or any other OpenTelemetry-compatible backend. 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 surface in your control plane that enables you to issue remote commands to appliance-hosted resources. It facilitates both asynchronous operations and synchronous operations - with approval workflows and audit logs so your customers stay in control.