Tensor9 FAQ

What is Tensor9?

Tensor9 is an enterprise any-prem platform. We enable software vendors, like you, to unlock hard enterprise customers that can’t share sensitive data. To do this, we help you convert your existing product for delivery inside the customer’s cloud or datacenter, so that sensitive data stays with the customer. You can learn more here.

What problem does it solve?

Selling to enterprise customers is challenging due to concerns about data leaving the enterprise, driven by regulatory requirements, heavy/siloed datasets, strict access control, and the need for operational resilience. Solving these challenges in-house requires costly engineering, maintenance, and support investments—culminating in you being forced to build, maintain, and support multiple products. Tensor9 eliminates this friction by enabling you to deliver your existing product directly into your customer’s environment, reducing costs and expanding access to sensitive or regulated enterprise markets. With Tensor9, you build, maintain, and support a single product and deliver it to any enterprise customer.

How does Tensor9 work?

The simplest mental model for Tensor9 is that it delivers your existing SaaS stack into any customer environment. Your customers then use your product by interacting with their own private instance of your stack. To make this easy for you, Tensor9 watches your existing SaaS stack (in your cloud) and continuously synchronizes to your customers (in their environment).

Tensor9 is able to accomplish this for a variety of customer environments by reading the infrastructure-as-code representation of your stack (such as CloudFormation) and compiling it into a form suitable for deployment to your customers' environments.

What is your roadmap and pricing model?

Reach out to us at [email protected] or contact us to learn more.

How many appliances do I need?

Each of your end customers will typically need a single appliance. If an end customer needs multiple isolated instances of your application, or has multiple geographically separated regions, then that customer will need multiple appliances.

Who manages the appliances?

You (the vendor) manage your end customers’ appliances, including their deployed software and auto-scaling. Tensor9 provides support.

What managed services can I deploy into a customer’s AWS account?

We support any managed service definable via infrastructure as code. We currently support CloudFormation, with Terraform coming soon.

What is a digital twin?

A digital twin is a real-time, miniature representation of the infrastructure inside a customer’s appliance that enables you to observe and operate customer appliances. By default, you have one digital twin in your cloud for each customer appliance. Your digital twin gives you access to logs and metrics, but does not contain the actual running instance or software data. If you have your own observability solution (such as Datadog), you can disable digital twin observability. All the other deployment-related features will continue to work.

Are the digital twins as large as the customer’s appliance?

No. Your digital twins are miniature. For example, a container digital twin costs approximately $0.01/hr. Each digital twin will percentage-wise mirror the operational state of its paired appliance (such as its CPU usage). This means that auto-scaling works.

Can I use my own observability solution instead of digital twins?

Yes. If you have your own observability solution (such as Datadog), you can disable digital twin observability. All the other deployment-related features will continue to work.

Who pays for the appliance cloud costs?

The end customer pays for appliance cloud costs; the appliance runs in the customer's cloud account.

What cloud account permissions does the customer need to set up their appliance?

A customer needs admin rights to the cloud account that will host the appliance. We are working on adding the ability to restrict this to a scoped set of permissions.

What customer data do I have access to via the digital twin?

All logs emitted by your ECS containers will be sent back to the digital twin. It is up to you to make sure those logs do not externalize sensitive customer data.

Can I deploy a code change to a subset of customer appliances?

Yes. You specify customer names during a release.

How do I shut down customer appliances?

An appliance can be shut down by deleting its digital twin stack, which removes the software from the customer’s appliance (which they can then delete on their own).

Can I enable a customer to run multiple versions of my app?

Yes. That customer should have multiple appliances. Each appliance will have its own private endpoint and digital twin. You can release different versions of your software to each appliance independently.

How does my customer manage the capacity of their appliance?

You manage capacity for them. Each digital twin you deploy in a customer-specific stack deploys corresponding capacity in the customer’s appliance. All resources within the appliance are tagged. Your customer can create budget alerts based on that tag to monitor their costs. We recommend that your customer use an isolated cloud account with spending limits to explicitly control costs.

Does my customer need to have a business relationship with Tensor9?

No. You manage your relationship with your own customer. Tensor9 white-labels our product, and will act as part of your team if you ever would like us to interact with your customer.

Do I have to use the Tensor9 CLI to create new releases? How should I automate this?

Yes, you must use the Tensor9 CLI to create new releases. You should use a continuous deployment tool like GitHub Actions or CircleCI to automate the Tensor9 CLI commands. We recommend that you group sets of customer appliances into waves and deploy one wave at a time.

What customer data does Tensor9 have access to?

Tensor9 only receives metadata from customer environments. This can include:

• The versions of Tensor9 software running in your and your customers’ environments.
• The number of machines in each environment and the function of each machine (for example, whether it is a control plane machine or a compute plane machine).
• The memory/CPU/network capacity of each machine.
• The uptime of each machine (that is, how long since the last software restart or hardware restart).
• The cloud (such as AWS, Azure, Google Cloud, or on-prem) and the region where an instance is located.
• Time series data about the memory/CPU/network utilization of each machine in every environment.
• Logs about errors occurring in each machine in your environment. These are logs about Tensor9 software operation, not about your software. For example, how long it took to prepare a deployment of your software to a customer environment, including to which customer environments (identified by an opaque identifier for that customer).
• Logs about errors occurring in each machine in the customer’s environment. These are logs about Tensor9 software operation, not about the operation of your software. For example, how long it took to apply a specific version of your software (identified by the version number of your choosing) on each machine in your customer’s environment.

In all cases, we are happy to share a full-fidelity copy of all data sent to Tensor9 from your and customers’ environments.

I need help!

Please contact us.