Architecture

Cloud Adapter is a runtime translation layer between software that speaks an origin cloud API and the native services selected for its target environment. The request path stays inside your environment. The local Tensor9 CLI configures and operates that runtime, but does not proxy application traffic.

​

The request path

Each request crosses three adapter stages:

1. API endpoint. Your existing SDK, CLI or infrastructure tool sends an origin-shaped request to the configured Cloud Adapter endpoint.
2. Service adapter. The selected origin-to-backend mapping interprets the request and translates its supported behavior.
3. Target client. Cloud Adapter calls the native target service using the backend identity configured for that mapping.

The response follows the reverse path. Cloud Adapter translates the target result into the origin API’s response shape. When emitted, diagnostic response headers can supply correlation identifiers or narrowly defined request-effect evidence. A cloud adapter is therefore composed of service adapters. Each service adapter owns one origin-service-to-backend mapping; the cloud adapter gives those mappings one operating boundary for a particular origin-to-target direction.

​

The operations path

The local Tensor9 CLI reads the installation’s configuration, validates changes and coordinates setup and updates. Configuration has two scopes:

• Cloud adapter configuration defines settings shared by the installation, such as its origin and target clouds, networking and deployment shape.
• Service adapter configuration selects a backend and supplies the settings needed for one service mapping.

Both scopes feed the runtime, but neither sits in the application request path. This separation lets the CLI stop after an operation while the adapters continue to serve traffic. See Configuration and Deployment.

​

Identity and trust boundaries

Cloud Adapter crosses distinct security boundaries. Treat them separately: An origin-shaped request does not inherit permission to the target service. Likewise, a target-cloud credential does not decide who may call the adapter. Apply least privilege independently at each boundary and keep provisioning credentials separate from runtime credentials.

​

Where state lives

Application data belongs to the selected target service. For example, an S3-to-Cloud Storage adapter stores objects in Cloud Storage; it does not keep a second object copy inside Cloud Adapter. Configuration is another durable input. Keep it under review and change control, because changing a backend can change data ownership and migration requirements even when the file remains syntactically valid.

​

How deployment mode changes the topology

Both modes use the same service implementations. What changes is where the serving runtime runs: A mode does not expand a service mapping’s operation coverage. The in-memory emulator is separate from both modes. See deployment modes for current availability and the pending local launcher.

​

Observe a request

Use tensor9 explain to inspect the directed service profile without contacting a deployment. To preview one deployed request, send a signed x-t9-explain control with explicit mode Explain through an explanation-aware request path. During live diagnosis, combine the resulting report with the adapter’s response headers, runtime logs and the resulting target-service state.