Skip to main content
An appliance is a secure, self-contained system that you deploy into a customer’s cloud infrastructure or private environment. Tensor9 appliances package all the components needed to run your app - compute, storage, networking, and the Tensor9 controller - into a single deployable unit.

​
What is an appliance?

Each appliance is a complete, isolated system that runs in a customer’s environment. Unlike traditional SaaS deployments where all customers share common infrastructure, each Tensor9 appliance is:
  • Customer-hosted: The appliance runs entirely within the customer’s cloud account or private infrastructure - their “environment”
  • Isolated: Each customer’s appliance is completely separated from other customers’ appliances
  • Self-contained: All application data and components stay within the appliance and never leave the customer’s environment
  • Abstracted: Customers interact with the appliance as a cohesive unit, not individual infrastructure components
  • Mirrored: The appliance mirrors your origin stack configuration, adapted to the customer’s specific form factor
All application data stays in the customer’s environment and never leaves their infrastructure. This provides complete data sovereignty and meets strict compliance requirements.

​
Environment vs appliance

It’s important to understand the distinction:
  • Environment: The customer’s infrastructure - their cloud account (AWS, Azure, GCP), Kubernetes cluster, or data center. This is what the customer owns and controls.
  • Appliance: The Tensor9-provided system that runs within that environment. This is what you (the vendor) deploy into the customer’s infrastructure.
  • App: The software that runs on the appliance. This is what gets installed.
Today, Tensor9 appliances come bundled with your app pre-installed. In the future, customers will be able to provision empty appliances and choose which apps to install - similar to an app store model. The appliance abstraction is designed to support both models.

​
Why appliances?

Appliances solve a critical challenge for software vendors: how to deliver modern, cloud-native applications to customers who require data sovereignty, regulatory compliance, or disconnected environments. With Tensor9 appliances, you can:
  • Meet compliance requirements: Deploy into regulated industries (healthcare, finance, government) that mandate data residency
  • Support multi-cloud: Deliver your application consistently across AWS, Google Cloud, Azure, Digital Ocean, or private Kubernetes
  • Maintain control: Observe and operate customer appliances remotely through secure, audited channels
  • Scale efficiently: Avoid the engineering overhead of maintaining multiple product versions for different customer environments

​
Appliance types

Tensor9 supports two types of appliances: customer appliances and test appliances.

​
Customer appliances

Customer appliances are production environments that run your application for end customers. These appliances are:
  • Owned and controlled by the customer
  • Managed through your control plane with appropriate customer approval workflows
  • Long-lived and follow a defined lifecycle (Setup → Live → Retiring → Retired)
  • Configured with customer-specific form factors, regions, and security requirements

​
Lifecycle

Every customer appliance progresses through four lifecycle states:
Lifecycle StateDescription
SetupThe appliance is being provisioned and configured. Infrastructure is being created, networking is being established, and the Tensor9 controller is being deployed.
LiveThe appliance is fully operational and serving traffic. Your app is deployed and running in the customer’s environment.
RetiringThe appliance is being decommissioned. Existing workloads continue to run, but no new deployments are accepted.
RetiredThe appliance has been fully decommissioned. All resources have been cleaned up and the appliance is no longer accessible.

​
Test appliances

Test appliances are automatically managed environments used for testing and development. These appliances allow you to:
  • Quickly spin up a temporary environment to test new releases
  • Validate deployments before rolling out to production customer appliances
  • Experiment with different form factors and configurations
Test appliances have a simplified lifecycle and can be retired when no longer needed.

​
Appliance architecture

Each appliance consists of several key components: a controller, a runtime environment, and artifact storage.

​
Controller

The controller is Tensor9-provided software that runs inside the appliance and acts as the bridge between your control plane and the customer’s infrastructure. The controller:
  • Receives deployment instructions from your control plane
  • Executes infrastructure-as-code deployments (Terraform, Kubernetes, etc.)
  • Collects telemetry (logs, metrics, traces) and forwards it to your control plane
  • Handles operations commands securely with proper authentication and audit logging

​
Runtime environment

The runtime environment is where your application code actually runs. This includes:
  • Compute resources (containers, virtual machines, serverless functions)
  • Data stores (databases, caches, object storage)
  • Networking (load balancers, service meshes, DNS)
  • Any managed services specified by the form factor
The exact composition depends on your origin stack and the appliance’s form factor.

​
Artifact storage

Each appliance includes dedicated storage for:
  • Container images and other deployment artifacts
  • Infrastructure-as-code state files
  • Configuration and secrets specific to this appliance
  • Backup and disaster recovery data

​
Connectivity modes

Appliances support different connectivity modes to accommodate various customer requirements:
Connectivity ModeDescriptionUse Cases
ConnectedThe appliance establishes an outbound connection to your control plane. This connection is used to receive deployments, send telemetry back to your control plane, and receive operational commands. The appliance never opens inbound network ports - all communication is outbound from the appliance to your control plane.Most common deployment model. Works in cloud environments and on-premises environments where outbound HTTPS is allowed.
Disconnected

(private beta)		The appliance cannot establish a connection to your control plane. Deployments, observability, and operations must be manually proxied by your customer through offline processes.Highly restricted networks with no outbound internet access.
Even connected appliances never open ingress ports to allow inbound requests from your control plane. The communication direction is always outbound from an appliance to your control plane. This means you don’t have to ask your customers to open ingress ports, which is often a logistically challenging requirement.
The connectivity mode is specified as part of the appliance’s form factor.

​
Creating a customer appliance

Customer appliances are created through a self-service signup flow. As a vendor, you generate a signup link and send it to your customer: 
tensor9 app signup-link -appName <APP_NAME>
This command generates a signup URL that you can send to your customer. 
# Generate a signup link for your app
tensor9 app signup-link -appName my-app

# Output:
# https://portal.tensor9.com/buyerSignup?appId=0000000000000213

​
Customer signup flow

When a customer appliance is created, Tensor9 orchestrates the following process:
1

Generate signup link

You generate a signup link using the tensor9 app signup-link command and send it to your customer. The customer uses this link to sign up and create their appliance through the Tensor9 portal.
2

Customer provisions appliance

Through the signup portal, your customer selects:
  • The form factor (cloud provider, connectivity, managed services)
  • The cloud region where the appliance will run
  • Any specific configuration options
The customer then runs the provided setup script in their environment.
3

Provision infrastructure

The setup script provisions the foundational infrastructure for the appliance in the customer’s environment, including:
  • A dedicated VPC or namespace (depending on the form factor)
  • Networking components (load balancers, DNS, routing)
  • Storage for runtime artifacts and configuration
  • The Tensor9 controller that manages the appliance
4

Establish connectivity

The appliance establishes a secure, outbound-only connection to your control plane. This connection:
  • Uses mutual TLS authentication
  • Allows your control plane to send deployment instructions
  • Enables telemetry to flow from the appliance to your observability sink
  • Provides the foundation for operations endpoints
5

Deploy your app

Once the appliance is ready, you compile your origin stack for the appliance’s form factor and deploy it using standard tooling (e.g., terraform apply, tofu apply).
Tensor9 architecture showing control plane and customer appliances The setup process typically takes 5-15 minutes, depending on the cloud provider and form factor complexity.

​
Monitoring appliance setup and status

You can view the status of all your appliances using the tensor9 report command: 
tensor9 report
This generates a comprehensive report showing all your apps, form factors, customer appliances, and test appliances. Here’s an example of what the output looks like: 
Vendor: Acme Software [id: 000000000000003b]:
            Name: Acme Software

    Apps: (1)
        my-app [id: 0000000000000213]:
            Name:   my-app
            Domain: my-app.customers.alpha.tensor9.com
            Stacks: (1)
                Terraform: (1)
                    my-stack | s3://t9-ctrl-000001/my-stack.tf.tgz
            Form Factors: (2)
                aws-connected [id: 0000000000000213:6d86e442e68ae6b8]:
                    Name:         aws-connected
                    Description:  AWS + Connected
                    Env:          Aws
                    Connectivity: Connected
                azure-connected [id: 0000000000000213:7e97f553f79bf7c9]:
                    Name:         azure-connected
                    Description:  Azure + Connected
                    Env:          Azure
                    Connectivity: Connected

    Customer Appliances: (2)
        Customer Appliance: acme-corp-production [id: 000000000000007e]:
            Status:              Live
            Name:                acme-corp-production
            Customer:            Acme Corp [id: 000000000000004a]
            Cloud Details:       Aws(us-west-2)
            Form Factor:         aws-connected
            Appliance Id:        000000000000007e

            Installs:
                Acme Software/my-app → Acme Corp [id: 0000000000000213:000000000000007e:0000000000000159]
                    Vendor:   Acme Software [id: 000000000000003b]
                    App:      my-app [id: 0000000000000213]
                    Customer: Acme Corp [id: 000000000000004a]
                    Release:  Acme Software/my-app → Acme Corp [version: 1.2.0]
                        Version: 1.2.0
                        Outputs:
                            api_endpoint: https://api.acme-corp-production.my-app.customers.alpha.tensor9.com
                            web_endpoint: https://web.acme-corp-production.my-app.customers.alpha.tensor9.com

            Releases:
                Effective Releases: (1)
                    Acme Software/my-app → Acme Corp [version: 1.2.0]
                        Version:      1.2.0
                        Lifecycle:    Submitted
                        Deployment:   Deployed
                        Created:      2 days ago
                        Updated:      2 days ago
                        Description:  Production release with new features
                        Origin:       s3://t9-ctrl-000001/my-stack.tf.tgz
                        Id:           s3://t9-ctrl-000001/my-stack.tf.tgz:4de31b51:0000000000000754
                        Notes:        Deployed successfully
                Prepped Releases: (0)

            Hardware: (updated 30 seconds ago)
                Uptime:              3 days 4 hours
                Capacity Machines:   3

        Customer Appliance: bigco-staging [id: 000000000000008f]:
            Status:              Setup
            Name:                bigco-staging
            Customer:            BigCo Inc [id: 000000000000005b]
            Cloud Details:       Azure(eastus)
            Form Factor:         azure-connected
            Appliance Id:        000000000000008f

            Installs:

            Releases:
                Effective Releases: (0)
                Prepped Releases: (0)

    Test Appliances: (1)
        Test Appliance: test-aws-us-west-2 [id: 000000000000009a]:
            Status:              Live
            Name:                test-aws-us-west-2
            Customer:            Acme Software Test [id: 000000000000003c]
            Cloud Details:       Aws(us-west-2)
            Form Factor:         aws-connected
            Appliance Id:        000000000000009a

            Test Appliance Name:  test-aws-connected
            Test Appliance Id:    000000000000003b:0000000000000006

            Installs:
                Acme Software/my-app → Acme Software Test [id: 0000000000000213:000000000000009a:000000000000016a]
                    Vendor:   Acme Software [id: 000000000000003b]
                    App:      my-app [id: 0000000000000213]
                    Customer: Acme Software Test [id: 000000000000003c]
                    Release:  Acme Software/my-app → Acme Software Test [version: 1.3.0-rc1]
                        Version: 1.3.0-rc1
                        Outputs:
                            api_endpoint: https://api.test-aws-us-west-2.my-app.customers.alpha.tensor9.com

            Releases:
                Effective Releases: (1)
                    Acme Software/my-app → Acme Software Test [version: 1.3.0-rc1]
                        Version:      1.3.0-rc1
                        Lifecycle:    Submitted
                        Deployment:   Deployed
                        Created:      4 hours ago
                        Updated:      4 hours ago
                        Description:  Release candidate for testing
                        Origin:       s3://t9-ctrl-000001/my-stack.tf.tgz
                        Id:           s3://t9-ctrl-000001/my-stack.tf.tgz:5ef42c62:0000000000000812
                        Notes:        Testing new features
                Prepped Releases: (0)

            Hardware: (updated 45 seconds ago)
                Uptime:              6 hours 23 minutes
                Capacity Machines:   1
You can also list all appliances individually using: 
tensor9 appliance list
This outputs detailed reports for each appliance, one at a time.

​
Creating test appliances

Test appliances can be created directly using the CLI: 
tensor9 test appliance create \
  -appName <APP_NAME> \
  -formFactorName <FORM_FACTOR_NAME> \
  -region <CLOUD_REGION>

​
Example: Creating a test appliance

# Create a test appliance for testing in AWS us-west-2
tensor9 test appliance create \
  -appName my-app \
  -formFactorName aws-connected \
  -region aws:us-west-2

# The test appliance will be automatically provisioned and show up in tensor9 report
Test appliances are provisioned automatically by Tensor9 and typically become available within 10-15 minutes.

​
Retiring test appliances

When you no longer need a test appliance, you can retire it: 
tensor9 test appliance retire \
  -testApplianceName <TEST_APPLIANCE_NAME>
This will decommission the test appliance and clean up all associated resources. Note: Customer appliances cannot be retired through the CLI for safety reasons. Contact Tensor9 support if you need to retire a customer appliance.

​
Appliances and installs

An appliance is the system, while an install is a specific app running on that appliance. The relationship is:
  • One appliance hosts exactly one install (current limitation)
  • One install belongs to exactly one appliance
  • Each install represents a specific app deployed onto a specific appliance
For example, if you have two apps (“Analytics” and “Dashboard”) and customer “Acme Corp” needs both, you would currently create two separate appliances - one for each app.
Multi-app support (multiple installs per appliance) is planned for a future release. When available, a single appliance will be able to host multiple apps, similar to how a single device can run multiple applications.

​
Appliances and form factors

The form factor defines the characteristics of the customer’s environment where the appliance will be deployed. When you create an appliance, you specify its form factor, which determines:
  • Cloud provider: AWS, Google Cloud, Azure, Digital Ocean, or private Kubernetes
  • Connectivity: Connected or disconnected
  • Managed services: Which managed services are available (e.g., AWS RDS, Google Cloud SQL)
  • Security requirements: FIPS compliance, CMMC compliance, etc.
  • Compute requirements: Minimum CPU, memory, storage
Your control plane uses the form factor to compile your origin stack into a deployment stack that’s optimized for deploying the appliance into that specific environment.

​
Security and isolation

Appliances are designed with security and isolation as core principles:

​
Network isolation

  • The appliance’s Tensor9 controller runs in a dedicated VPC, Kubernetes namespace, or set of virtual machines (depending on the appliance’s environment)
  • The software defined network mirrors the origin stack’s network topology as closely as possible
  • Appliances communicate with your control plane through secure, authenticated channels

​
Data isolation

  • All application data remains within the appliance (and thus within the customer’s control)
  • Telemetry sent to your control plane is limited to logs, metrics, and traces - no customer business data
  • Secrets and credentials are stored encrypted and scoped to the specific appliance

​
Access control

  • All operations commands require customer approval (configurable by the customer)
  • Every action is logged and auditable
  • Your control plane uses mutual TLS to authenticate with appliances
  • Temporary access (e.g., JIT IAM roles) is granted only with explicit customer approval

​
Observability

Once your appliance is live and your app is deployed, you can observe its state, performance, and usage through telemetry synchronized back to your control plane. Tensor9 automatically configures the appliance to forward:
  • Logs: Application logs from containers, VMs, and serverless functions
  • Metrics: System metrics (CPU, memory, disk) and custom application metrics
  • Traces: Distributed traces for request flow analysis
All telemetry is forwarded from the appliance to your control plane, which then routes it to your configured observability sink (Datadog, New Relic, CloudWatch, etc.).

​
Operations

Your control plane provides operational endpoints that allow you to perform day-2 operations on appliances:
  • Remote shell access: Execute commands inside the appliance for debugging
  • Configuration management: Update secrets, environment variables, and configuration
  • Service restarts: Restart services or trigger state changes
  • Database migrations: Run one-off scripts or database migrations
All operations are authenticated, authorized, and logged, with configurable customer approval workflows.

​
Best practices

Use clear, descriptive names for appliances that include:
  • Customer identifier
  • Environment type (production, staging, etc.)
  • Optional region or purpose
Examples:
  • acme-corp-production
  • bigco-staging
  • megacorp-emea-compliance
Always create and test releases in test appliances before deploying to customer appliances:
  1. Create a test appliance for your target form factor
  2. Deploy and validate your release in the test appliance
  3. Once validated, deploy the same release to customer appliances
Regularly run tensor9 report to monitor the health of all your appliances. Pay attention to:
  • Status: Ensure appliances are “Live” and not stuck in “Setup” or “Starting up”
  • Deployment: Check that releases show “Deployed” status
  • Hardware: Monitor uptime and capacity machines
  • Blocking Issues: Address any blocking issues in prepped releases before deployment

​
Next steps

Now that you understand appliances, explore these related topics: