Try Tensor9 in 5 Minutes: Our New BYOC Sandbox Is Live

What you can do

Upload a stack. Pick one of the four example stacks, or upload your own Terraform (not retained after the session). Tensor9 discovers every service from your Terraform and Helm configs and models it as your origin stack: the description of how your product runs today, and the starting point for compiling to other environments. (More on origin stacks in the docs.)

Create a form factor. A form factor is a deployment option you offer your customers: which target (AWS, Azure, GCP), what connectivity, ingress modes, and service adaptations. When you create one, Tensor9 compiles your origin stack for that target, swapping AWS-native services for equivalents that run there (more on how below).

Generate a signup link. From a form factor you generate a signup link, the URL you’d share with a customer.

Walk the customer setup. Follow that signup link and see exactly what your customer sees when they set up the appliance that runs your product in their own environment (more on this below). This is usually the part that surprises people. Most vendors haven’t thought about what this experience actually looks like from the customer side.              

Try day-two operations. These are the things you do after go-live. Create an observability sink to see how logs, metrics, and traces would flow back to your team. Try the ops command interface to run a command against a remote customer deployment. And walk a break-glass session end to end: request access, watch the customer approve and sign, and see it expire and tear down. You can experience all of this before you’ve onboarded a single customer.  

Prefer the terminal? There’s a CLI. The sandbox has an in-browser CLI drawer, and you can install the same tensor9 CLI locally. It’s the same commands the portal runs, scriptable and ready for automation, so you can drive the whole loop from your shell instead of clicking it.

How Tensor9 handles service translation

How Tensor9 handles a service depends on the service, and it falls into one of three categories.

Wire-compatible open-source replacements. For services whose equivalent is open-source and speaks the same protocol (RDS to Postgres via CloudNativePG, ElastiCache to Redis/Valkey, DocumentDB to MongoDB via Percona), Tensor9 points the network endpoints at the replacement and translates the configuration: engine version, storage, replica topology, connection strings, access grants. Your application code keeps working because the protocol is the same. Behavior isn’t always identical, though, and the comparison card (below) shows you where the replacement differs from the original.

Adapted services. For a set of other popular AWS services, Tensor9 puts a service adapter in front that speaks the AWS API and translates to a target cloud’s managed service. DynamoDB maps to Firestore, Spanner, or BigTable on GCP (the decision of which depends on your preferred tradeoffs); and to Cosmos DB on Azure. A similar approach covers SQS, S3, Lambda, and API Gateway, among others. Your application keeps calling the AWS API it already knows, and underneath it’s running on the target cloud’s managed infrastructure. We also support VPC by mapping to the native GCP VPC and Azure VNet abstractions, and IAM by mapping to Cedar policy language. An upcoming blog post on service adaptation will go into much more detail.

Not supported yet. Some services we deliberately don’t offer, because there’s no faithful equivalent off AWS. SageMaker is one: there’s no open-source training and inference plane we’d trust to behave the same. AppMesh and SES are others. When that’s the case, we tell you why.

See what it compiles to

The sandbox allows you to view the origin and compiled Terraform side by side. How much changes depends on the adaptation tier. An infra-only form factor compiles to real target-cloud resources you can read line by line: an EKS cluster becomes a GKE cluster, a VPC becomes a Google Cloud network. A max-adaptation form factor keeps its Terraform close to the origin, because that adaptation happens at runtime rather than in the file.

Trova compiled from AWS to Google Cloud on an infra-only form factor: origin Terraform on the left, the compiled Google Cloud resources on the right.

The Service Mappings view lays out every service and what it becomes on the target cloud, grouped by domain. A clean swap like EKS to GKE maps one to one; an emulated service expands to show the pieces that stand in for it on the target cloud you picked.

The service mappings for the same form factor: each AWS service and its Google Cloud equivalent.

The service catalog

The service catalog in the sandbox: your AWS services and how they map across each target cloud.

In the catalog every service shows up with its status: fully evaluated, mapped, coming soon, or deliberately not offered. Before you commit to anything, you know exactly where each one stands, including the services we don’t support.

A service card in the sandbox: how S3 maps to each cloud’s storage, compared feature by feature.

For the services we’ve evaluated, there’s a comparison card: the AWS original next to the replacement, the fidelity of the match, and the knobs you can tune. They’re backed by service-equivalence evals, workload benchmarks that run the replacement and the AWS original through the same operations and measure how close the behavior is. Where we’ve certified a mapping end to end, the sandbox surfaces the result as a signed attestation: measured evidence that the replacement behaves like the original, which you can download and verify yourself.

You see the whole picture up front: what’s a clean drop-in, what runs through emulation, what needs tuning, and what we won’t pretend to do.

Read more about the service catalog in our docs.

What your customer experiences

The other thing people ask is: what does my customer actually have to do? The signup link answers it. Open it in the sandbox and you walk the setup exactly as your customer would. It all runs in their environment. Tensor9 never gets their standing cloud credentials; they apply the Terraform themselves, in their own account, and watch it come up.

The setup moves through a short set of named steps:

• Prepare. The customer picks where it runs (AWS, Azure, GCP), along with region, how it connects, and how traffic reaches it (public, private, IP allowlist, or over a private overlay).

• Infrastructure. Tensor9 generates a Terraform file for their chosen environment: the networking, compute, and IAM your product needs. They download it and run terraform apply in their own account. Nothing is provisioned by us; the customer’s own Terraform run creates it and reports back. It’s a separate apply from the next step, so they can review the infrastructure on its own before anything else comes up.
• Controller. A second Terraform file brings up the controller that runs and manages your product inside their environment. They apply it the same way, and the setup waits while it boots.
• Configure. If your form factor asks for anything from the customer (secrets they own, a DNS domain, which optional services to turn on), this is where they provide it. Secrets they hold stay theirs; they land in their own secrets manager, not yours.

In the sandbox the applies are simulated so the flow completes in seconds, but you see every screen your customer would. It’s the fastest way to answer “what are we actually asking our customers to do?”

Day-two operations

Once your product is running in a customer’s environment, you still have to operate it, and you have to do that without standing access. The sandbox lets you try the three ways Tensor9 makes that work, before you have a single customer live.

See what’s happening. Point an observability sink at your stack and logs, metrics, and traces flow back to your own tooling, so a remote deployment isn’t a black box.

Run a command. For routine work (list pods, restart a service, rotate a worker), you run scoped, pre-approved commands against the remote deployment. No shell and no standing credentials: the customer approves the command templates, and every run is recorded. We go deep on this in our post on operational commands. 

Break glass. When a command isn’t enough and you need an actual shell to chase down an incident, break-glass gives you one-time, time-bounded access to a single resource, granted only when the customer signs off. It’s deliberately higher-friction than a scoped command: approved per session, minted under the customer’s own key, and torn down when the clock runs out, with nothing left standing. Because the grant is authorized by the customer’s signature against their own environment, even a compromised Tensor9 couldn’t mint access, widen it, or extend it. The full walkthrough is in our break-glass deep dive.

What the customer sees: the resource, the access window, the reason, and an approval they sign locally with their own key.

You can experience all three in the sandbox before you onboard anyone. In a sandbox break-glass session the resource is synthetic and the credential self-evidently fake, but the approval workflow (request, approve or reject, sign, expire) is the real production path, not a mockup.

The example stacks

Solvo. AI service management. EKS, Temporal, Postgres, Redis. Five stack layers including a Helm-deployed application tier.

Claris. ML observability. The largest example. 87 services across four layers, heavy AWS-native with multiple database engines and monitoring infrastructure. A good one to watch the catalog sort what maps cleanly today from what’s still coming.

Veris. Identity and access management. 13 Terraform modules. Security-focused with identity providers and policy engines. 53 services.

Trova. Search platform. Lean and focused. 12 services. A clean example of what a smaller stack looks like compiled for on-prem.

A few common questions

Can I bring CloudFormation, or only Terraform? Terraform and Helm are the main path, and they’re what the sandbox is tuned for. If your stack is in CloudFormation, we can ingest it too by translating it to Terraform; reach out and we’ll run it with you.

Does my product have to run on AWS today? Yes. Right now your origin stack starts from AWS, and Tensor9 compiles it out to the target you pick. GCP-origin and Azure-origin will be available soon. If your product runs somewhere else today, tell us where; it helps us prioritize.

Which environments can I deploy to? AWS, Azure, GCP, as well as preview versions of OCI, on-prem Kubernetes, Digital Ocean, Akamai, Scaleway, and more.

What if you don’t support one of my services? The catalog tells you plainly. Some services are already mapped, some are on the way, and a few (like SageMaker and AppMesh) we don’t adapt because there’s no equivalent off AWS we’d trust. If a service you depend on isn’t there yet, tell us: that’s how the catalog grows. A new mapping is a change we make on our side, not a rewrite on yours.       

Try it

The sandbox is at sandbox.tensor9.com. Browse the example stacks or upload your own. Serval, an AI-agents-for-IT vendor, went from signup to their product running in a customer environment on Tensor9 in three weeks. If you want to go further with a full stack analysis, reach out.