Start a local adapter
This guide’s bounded example uses S3 backed by Google Cloud Storage:1
Install or update the Tensor9 CLI
Install the customer CLI with Homebrew, then confirm the binary is available:If
tensor9 is already installed, run brew upgrade tensor9 instead of the install command.2
Authenticate with Tensor9
A Tensor9 API key is required. Use the key issued during onboarding, or email [email protected] to request one for your organization. Do not share your account or key with another customer or organization.If your secret manager has already supplied Check that the variable is set without printing it, then verify your Tensor9 identity:Confirm that the reported identity belongs to the intended customer account. Do not continue if authentication fails or the account is wrong. Keep shell tracing disabled while using the key. Do not paste the key into commands, shell profiles, source files, screenshots or support messages.See Install and Authenticate for the planned license lifecycle, entitlements and credential boundaries.
T9_API_KEY, skip the prompt. Otherwise, enter your key at a hidden prompt in the terminal where you will run tensor9:- Bash
- Zsh
3
Inspect the S3 to Google Cloud Storage mapping
Ask Tensor9 to describe the exact directed service mapping used by this guide:Read the supported S3 operations and Google Cloud Storage limitations before starting the process. The mapping is directional: this command describes S3 requests adapted to Google Cloud Storage, not the reverse direction.
4
Prepare Google Cloud access
Authenticate with Google Cloud using its standard Application Default Credentials chain. The adapter uses that identity when it calls Google Cloud Storage.Use a dedicated test project and narrowly scoped credentials. Do not put credentials in the command line, source code, or screenshots.
5
Start the S3 service adapter
Run the S3 to Google Cloud Storage adapter as a foreground process:Leave this terminal open. This is the current foreground launcher, not the pending Docker launcher for local development mode. It calls your actual target-cloud services; it is separate from the in-memory emulator. Acquisition and license renewal require Tensor9 authentication. Keep the endpoint local to your test.
6
Copy the listening endpoint
When the command reports its listening endpoint, copy that exact value into a second terminal:Keep the endpoint local to the test unless you have deliberately configured network access and authentication for another machine.
7
Run one bounded S3 request
Continue with this page’s client or tool instructions. Point only S3 at
T9_CLOUD_ADAPTER_ENDPOINT, then perform one operation whose Google Cloud Storage effect you can verify independently.Check both sides: read the S3-shaped response and inspect the native object or bucket in Google Cloud Storage. A successful client response alone does not prove that the target state is correct.8
Stop the local adapter
Return to the first terminal and press Control-C. Confirm the process exits before deleting the test object or bucket with Google Cloud’s native client.If the request failed, preserve the request ID, adapter endpoint, S3 operation name, Google Cloud request ID, and any
x-t9-explain-* receipt headers before stopping the process.Choose how to set the endpoint
Set it for the process
The AWS-standard S3 environment variable applies to every S3 client created by a supported SDK in this process:endpointOverride:
Set it on one client
Keep endpoint selection in one factory rather than scattering it through business logic.endpointOverride changes where the AWS request is sent. It does not change the service model, add unsupported operations, or provide credentials to the target service. Backend credentials stay in the service adapter configuration.
An explicit client override takes precedence over AWS_ENDPOINT_URL_S3. Choose one approach for a client factory so configuration remains easy to audit.
For SDK 1.x, use AmazonS3ClientBuilder with an endpoint configuration and path-style access. Do not mix 1.x and 2.x configuration examples in the same client factory.
Verify a lifecycle
Use a unique key and a small payload:putObject, not only through the adapter. That catches name, region, metadata, and identity mistakes that an origin-shaped response alone may hide.
Preserve failure evidence
Catch service and transport failures separately:Explain one SDK request
For a difficult request, add a signed per-requestx-t9-explain control and retain the returned report ID. ExecuteAndExplain performs the operation and preserves the ordinary SDK response; explicit Explain does not perform it and returns a diagnostic document that needs explanation-aware handling.
The complete Explaining SDK Requests guide shows:
- the Java 2.x request override, applied before SigV4 signing;
- the exact mode and format values;
- success, service-error and no-response handling;
- report retrieval without replaying the original operation;
- report-owner acknowledgment and out-of-band evidence sharing.
x-t9-explain: true for a dry run: that shorthand selects ExecuteAndExplain in Human format.
Production client checklist
- Make endpoint, origin region, and credential provider explicit.
- Bound connection, request, and retry timeouts for the target path.
- Reuse the client; do not create one per request.
- Test the exact paginator, waiter, conditional request, and multipart features the application uses.
- Keep AWS-origin credentials separate from the adapter’s target-cloud identity.
- Run an expected not-found or validation error to verify error translation.