Skip to main content
Tensor9 Cloud Adapter emulates your cloud inside another. Keep using your existing cloud SDKs, CLI commands and Terraform providers while running your software in a different cloud or on-prem. Cloud Adapter translates the APIs your application already uses into calls to your chosen backend, then returns responses in the formats your tools expect.
Your stack connects through Tensor9 Cloud Adapter to services in another cloud or private environment.Your stack connects through Tensor9 Cloud Adapter to services in another cloud or private environment.
Your stack connects through Tensor9 Cloud Adapter to services in another cloud or private environment.Your stack connects through Tensor9 Cloud Adapter to services in another cloud or private environment.

​
Who Cloud Adapter is for

Cloud Adapter is for software vendors and enterprises that want the freedom to choose their cloud while keeping the cloud integrations they already have.
  • Software vendors expanding into new marketplaces. Reach customers in additional cloud marketplaces by running your product in those environments, while keeping its existing cloud integrations.
  • Software vendors reducing infrastructure costs. Move your product to a lower-cost cloud or choose a more cost-effective backend for individual services, while retaining your existing SDKs, CLI commands and Terraform configurations.
  • Enterprises using multiple clouds to control costs. Choose the cloud and backend that offer the best economics for each workload. Keep the APIs your applications already use across those environments, so each cloud choice does not require a separate application integration.
  • Vendors deploying into customer environments. Offer the same product in a customer’s chosen cloud or on-prem environment, including deployments driven by data-location requirements.
For example, your product can keep using the S3 API while storing objects in Google Cloud Storage, or the DynamoDB API while using Azure Cosmos DB. Your team works with the APIs it knows; Cloud Adapter handles the backend translation.

​
Request access

We have a backlog of customers and are ramping up capacity. Request access to discuss your workload with Tensor9.

​
How it works

  1. Choose what to emulate and where to run it. Select the cloud APIs your software uses and the backend services that will provide them in the new environment.
  2. Point your existing tools at Cloud Adapter. Configure the adapter endpoint in your SDK, CLI or Terraform provider, along with the application credentials.
  3. Run your software. Cloud Adapter translates supported API calls to the selected backend and returns responses in the format your application expects.
Each mapping connects a familiar cloud API to a specific backend. The examples below use AWS APIs with services in Google Cloud and Azure.

​
Request and response architecture

Your application sends familiar cloud API requests to Cloud Adapter. The adapter calls the chosen backend services and translates their responses back for your application.
An application sends origin API requests through a Cloud Adapter service adapter to native target services. The Tensor9 CLI provides configuration outside the request path.An application sends origin API requests through a Cloud Adapter service adapter to native target services. The Tensor9 CLI provides configuration outside the request path.

​
Use a standard SDK

Use the standard, unmodified SDK for the cloud your software was built for. Configure the adapter endpoint using the SDK’s normal endpoint option; request signing and response parsing continue to use that cloud’s API. For example, the standard AWS SDK for Python, boto3, can write the same object through the S3 API. Configure your region and origin-side credentials through the normal AWS credential chain before running this example. With the selected S3-to-Cloud Storage profile and bucket configured:
endpoint_url and path-style S3 addressing are standard SDK configuration. No SDK fork or custom request format is required for this example. The same operation and service-pair limitations apply to SDK and CLI requests.

​
Examples with the AWS CLI

Before trying either example, the adapter must be running, its endpoint and origin-side credentials must be configured, and the named target resources must exist. Set T9_CLOUD_ADAPTER_ENDPOINT to your adapter endpoint. The commands below use illustrative resource names.

​
Store an object in Google Cloud Storage using S3

With S3 mapped to Google Cloud Storage, send an S3 PutObject request:
The object lands in the configured Cloud Storage bucket. The AWS CLI still sends an S3 request and receives an S3-shaped response, so the client keeps the same command and request format.

​
Read an Azure Cosmos DB item using DynamoDB

For a DynamoDB table mapped to provisioned Azure Cosmos DB, send a supported GetItem request:
Cloud Adapter reads the mapped Cosmos DB item and returns DynamoDB-typed attributes. Configure the corresponding table and key names before using this example. Confirm the selected pair’s supported request shape before relying on it in your workload.

​
Use Terraform or OpenTofu

Terraform and OpenTofu use a cloud provider’s normal API calls. Configure the provider to send supported service calls to Cloud Adapter, which translates them to your chosen backends. You keep the provider and its familiar resource definitions. For an existing test bucket using S3 backed by Google Cloud Storage, the AWS provider’s standard endpoints setting directs S3 calls to the adapter. This configuration fragment comes from the bounded S3 example for AWS provider 5.100.0; adapter_endpoint is the endpoint of your running adapter:
Supply origin-side credentials through the provider’s normal credential chain. The four skip_* options keep that provider version’s startup checks from contacting metadata, region validation or AWS STS outside the configured S3 route; they do not disable Cloud Adapter authentication. Reassess the provider’s API calls before changing versions. Start with an isolated workspace and an existing test bucket. Check the exact resource lifecycle you need, including create, read, refresh and delete, through both the origin API and the target service. Changing a provider endpoint is not application-data migration and can affect refresh or replacement plans. Verify behavior before redirecting a production workspace.

​
Get started with Cloud Adapter

Install the Tensor9 CLI with Homebrew:
The CLI bundles its own runtime. No separate Java installation is required. Homebrew 7 and later requires trusting the Tensor9 tap once per machine before installing or upgrading. Installing the CLI is the first step. Running an adapter requires a Tensor9 customer account, access to the selected service pair, target-cloud resources and appropriately scoped identities. Your Tensor9 API key is for the operator’s CLI; it is separate from application and target-cloud credentials. Setup accepts a complete configuration file or guides you through questions to generate one. For a focused evaluation, begin with one service pair and disposable test resources using the existing foreground tensor9 adapt svc run workflow. Full deployments use tensor9 adapt cloud install to prepare the target-cloud fabric that hosts the serving image, with configuration, networking and credentials prepared for that environment. The local container launcher is pending. The Homebrew commands above install the CLI; they do not deploy a running adapter or establish production readiness. Confirm supported operations and verify one bounded request before expanding the workload.

​
Connect locally for development and testing

Once your early-access Cloud Adapter installation is running, keep your application, debugger and tests on your laptop. Open a tunnel to the installation using the directory printed by adapt cloud install, and leave this terminal running:
In another terminal, load the installation’s AWS profile and local endpoint, then make an identity request:
Run your application or tests from that shell, using your SDK’s normal endpoint settings. Requests go through http://127.0.0.1:65534 to your installed Cloud Adapter and its configured cloud backends. The application runs locally; target resources and cloud billing remain in your development project or subscription. connect without --forward or --env prints instructions. Ctrl-C stops the tunnel and leaves the installation running for your next session. Use a dedicated development shell and test resources so these endpoint and profile settings stay separate from other workloads.

​
Request access

We have a backlog of customers and are ramping up capacity. Request access to discuss your workload with Tensor9.

​
Supported services

The table below shows AWS API mappings as a concrete service catalog. Each row is a distinct backend option; a cloud icon identifies an environment where it is offered. A dash (-) means that backend is not offered for that environment. A mapping does not promise every API operation. Availability and behavior depend on the selected service profile, release and your account’s entitlements. The Preview labels apply to the indicated target environments, not to individual AWS services. On-prem refers to Kubernetes-based deployments in the catalog. Scroll horizontally to compare all six environments. Backend names are the human-readable names from the directed service profiles.

​
Request access

We have a backlog of customers and are ramping up capacity. Request access to discuss your workload with Tensor9.