Customer Appliances

An appliance is a secure, self-contained system that you deploy into a customer’s cloud infrastructure or private environment. Tensor9 BYOC appliances package all the components needed to run your app - compute, storage, networking, and the Tensor9 BYOC 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 cloud deployments where all customers share common infrastructure, each Tensor9 BYOC 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: Application data and components stay within the appliance and do not leave the customer’s environment. The exception is a third-party managed equivalent your customer chooses, such as MongoDB Atlas or Confluent Cloud, which is hosted externally by design; service adapters marks which equivalents those are
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 BYOC-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.

Tensor9 BYOC appliances are provisioned with your app installed.

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 BYOC 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, 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 BYOC 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 State	Description
Setup	The appliance is being provisioned and configured. Infrastructure is being created, networking is being established, and the Tensor9 BYOC controller is being deployed.
Live	The appliance is fully operational and serving traffic. Your app is deployed and running in the customer’s environment.
Retiring	The appliance is being decommissioned. Existing workloads continue to run, but no new deployments are accepted.
Retired	The 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 has three components: a controller, a runtime environment, and artifact storage. For any service at the Max Adaptation Tier it also runs the Tensor9 BYOC adapter, which answers the AWS API your application calls; see service adapters for which services need it.

Controller

The controller is Tensor9 BYOC-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 Mode	Description	Use Cases
Connected	The 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. Within Connected mode, the outbound channel from the appliance’s controller to your control plane is established over the public internet by default. AWS PrivateLink is optionally available as an additional path when both your control plane and the customer’s controller are on AWS, and a vendor-provided Tailscale tailnet is optionally available as a path on any cloud. See the security model for the underlying handshake, the AWS form factor page for how the choice is exposed when authoring an AWS form factor, and the Connectivity page for a side-by-side comparison of all available network paths.

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.

You can also generate signup links from the Vendor Portal under your app’s detail page.

# Generate a signup link for your app
tensor9 app signup-link -appName my-app

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

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

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 BYOC portal.

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.

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 BYOC controller that manages the appliance

Establish connectivity

The appliance establishes a secure, outbound-only connection to your control plane. This connection:

Uses mutual TLS authentication (see Connection Security)
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

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 or the Vendor Portal. The Vendor Portal shows your appliances on the main dashboard with real-time health status.

tensor9 report

This generates a 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 BYOC 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
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, create two separate appliances - one for each app.

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, 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 BYOC 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 and each appliance authenticate each other with mutual TLS (see Connection Security)
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 BYOC 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

Naming conventions

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

Testing before production

Always create and test releases in test appliances before deploying to customer appliances:

Create a test appliance for your target form factor
Deploy and validate your release in the test appliance
Once validated, deploy the same release to customer appliances

Monitoring appliance health

Regularly monitor the health of your appliances using tensor9 report or the Vendor Portal dashboard. 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:

Deployments: Learn how to deploy to appliances
Observability: Monitor your appliances
Operations: Operate your appliances remotely

Tensor9 BYOC

Getting Started

How It Works

Deploying

Your Customer's Environment

Service Adapters

Auto-Customizations

Security

Connectivity & Networking

Observability & Operations

tensor9 CLI

Customer Appliances

What is an appliance?

Environment vs appliance

Why appliances?

Appliance types

Customer appliances

Lifecycle

Test appliances

Appliance architecture

Controller

Runtime environment

Artifact storage

Connectivity modes

Creating a customer appliance

Monitoring appliance setup and status

Creating test appliances

Example: Creating a test appliance

Retiring test appliances

Appliances and installs

Appliances and form factors

Security and isolation

Network isolation

Data isolation

Access control

Observability

Operations

Best practices

Next steps

​What is an appliance?

​Environment vs appliance

​Why appliances?

​Appliance types

​Customer appliances

​Lifecycle

​Test appliances

​Appliance architecture

​Controller

​Runtime environment

​Artifact storage

​Connectivity modes

​Creating a customer appliance

​Example: Generating a signup link

​Customer signup flow

​Monitoring appliance setup and status

​Creating test appliances

​Example: Creating a test appliance

​Retiring test appliances

​Appliances and installs

​Appliances and form factors

​Security and isolation

​Network isolation

​Data isolation

​Access control

​Observability

​Operations

​Best practices

​Next steps

What is an appliance?

Environment vs appliance

Why appliances?

Appliance types

Customer appliances

Lifecycle

Test appliances

Appliance architecture

Controller

Runtime environment

Artifact storage

Connectivity modes

Creating a customer appliance

Example: Generating a signup link

Customer signup flow

Monitoring appliance setup and status

Creating test appliances

Example: Creating a test appliance

Retiring test appliances

Appliances and installs

Appliances and form factors

Security and isolation

Network isolation

Data isolation

Access control

Observability

Operations

Best practices

Next steps