Skip to main content
Cloud Adapter gives you an endpoint that speaks your origin cloud’s API. Point your existing cloud CLI or SDK at that endpoint and keep using its familiar commands and request formats. For supported operations, Cloud Adapter calls the selected target service and returns an origin-cloud response. You do not switch your application to the target cloud’s API.
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.

Why use Cloud Adapter

A move to another cloud can mean changing the APIs your application calls, the tools your team uses, or both. Cloud Adapter lets you evaluate supported target services while keeping the origin API your application already understands. For example, an application that writes objects through the S3 API can store them in Google Cloud Storage. A supported DynamoDB read can retrieve an item from Azure Cosmos DB. Your application continues to send the origin request format; the adapter handles the selected target API.

How it works

  1. Choose the service pair. Configure the origin service, the selected target service and the resources the workload will use. Confirm that the operations and request shapes you need are supported for that pair.
  2. Point your client at the adapter. Use the adapter endpoint with your familiar CLI or SDK and its configured origin-side credentials.
  3. Send a supported request. Cloud Adapter calls the selected target service, then returns a response in the origin API’s format.
Support is directional and specific to each origin service, target service and operation. These examples illustrate the request path, not complete compatibility with every origin-cloud feature.

Request and response architecture

Your client speaks its normal origin API. Cloud Adapter handles the selected target API and returns the origin response format.
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

You can use standard, unmodified SDKs for the supported origin API. Configure the adapter endpoint using the SDK’s normal endpoint option. The SDK continues to build, sign and parse requests using that origin 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 can call Cloud Adapter through a standard origin-cloud provider. Cloud Adapter is not a Terraform provider: it implements the supported cloud API operations that the provider calls. 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 sip 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.

Request access

Tell Tensor9 which origin API, target cloud and operations your workload needs so we can discuss the appropriate service pair. We have a backlog of customers and are ramping up capacity. Request access to discuss your workload and the right service profiles with Tensor9.

Supported services

Find the AWS service API your software calls, then read across to the environment where you want to run it. A checkmark (✓) means Cloud Adapter offers a service adapter for that direction. A dash (-) means no mapping is offered. This is the full AWS-origin service catalog. A mapping does not promise every API operation; verify the supported behavior your application depends on. Preview labels retain the catalog’s Preview status. Availability also depends on the selected release and your account’s entitlements. The Service name column lists the origin API identifier. Some customer-facing services combine more than one API surface. Scroll the table horizontally to compare all seven target environments.
Confirm your target environment, required operations and profile limitations with Tensor9 before connecting a workload. The table describes service directions, not a guarantee of complete API compatibility or production qualification.

Request access