> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Getting Started

> Evaluate a service mapping and prepare a Cloud Adapter deployment.

Start with one service and a small set of operations your application actually uses. This makes it possible to verify compatibility before connecting a larger workload.

Cloud Adapter includes [Support Agents](https://docs.tensor9.com/cloud-adapter-early-access/support/agents.md) to help assess the mapping and investigate your first results. Give the agent your intended operations and selected target; keep setup and verification scoped to the test environment.

Before continuing, [install the CLI and authenticate with `T9_API_KEY`](https://docs.tensor9.com/cloud-adapter-early-access/getting-started/install-and-authenticate). The key identifies your Tensor9 customer account for online commands; it is separate from application and target-cloud credentials.

## Try one mapping locally

Choose one directed pair from the service catalog and run the smallest useful operation before evaluating a larger deployment. This example uses S3 backed by Google Cloud Storage:

```bash theme={null}
export T9_ORIGIN_SERVICE="aws::1.0.0::s3"
export T9_BACKEND_SERVICE="google::1.0.0::gcs"
```

**1. Install or update the Tensor9 CLI**

Install the customer CLI with Homebrew, then confirm the binary is available:

```bash theme={null}
brew tap tensor9ine/tensor9
brew trust tensor9ine/tensor9
brew install tensor9
tensor9 --version
```

If `tensor9` is already installed, run `brew upgrade tensor9` instead of the install command.

**2. Authenticate with Tensor9**

To create a Tensor9 account and download an API key yourself, follow [Get a Tensor9 API key](https://docs.tensor9.com/byoc/getting-started/api-key.md).

A Tensor9 API key is required. Use the key issued during onboarding, or email [hello@tensor9.com](mailto:hello@tensor9.com) 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 `T9_API_KEY`, skip the prompt. Otherwise, enter your key at a hidden prompt in the terminal where you will run `tensor9`:

> [tab] Bash
>
> ```bash theme={null}
> set +x
> IFS= read -r -s -p 'Tensor9 API key: ' T9_API_KEY
> printf '\n'
> export T9_API_KEY
> ```

> [tab] Zsh
>
> ```zsh theme={null}
> set +x
> IFS= read -r -s 'T9_API_KEY?Tensor9 API key: '
> printf '\n'
> export T9_API_KEY
> ```

Check that the variable is set without printing it, then verify your Tensor9 identity:

```bash theme={null}
: "${T9_API_KEY:?Set T9_API_KEY before continuing}"
tensor9 whoami
```

Confirm that the reported identity belongs to the intended customer account. Do not continue if authentication fails or the account is wrong. While `T9_API_KEY` is set, `tensor9` commands in this terminal use the key instead of any controller profile, so use a separate terminal for this work and run `unset T9_API_KEY` when you finish. 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](https://docs.tensor9.com/cloud-adapter-early-access/getting-started/install-and-authenticate.md) for the planned license lifecycle, entitlements and credential boundaries.

**3. Confirm the directed service mapping**

Confirm that you exported the canonical origin and backend service names supplied by this quickstart:

```bash theme={null}
: "${T9_ORIGIN_SERVICE:?set the origin service name shown above}"
: "${T9_BACKEND_SERVICE:?set the backend service name shown above}"
printf 'Origin:  %s\nBackend: %s\n' \
  "$T9_ORIGIN_SERVICE" "$T9_BACKEND_SERVICE"
```

Then inspect the mapping before starting a process:

```bash theme={null}
tensor9 explain \
  -origin "$T9_ORIGIN_SERVICE" \
  -target "$T9_BACKEND_SERVICE" \
  -fmt Human
```

Read the supported operations and limitations for that direction. A similarly named service in the target cloud is not enough. If no directed profile exists, choose another mapping before continuing.

**4. Prepare target-cloud access**

Authenticate with the target cloud using its standard credential chain. The adapter uses that target identity when it calls the backend service.

Keep credentials in your shell, workload identity, or local credential store. Do not put secrets in the command line, source code, or screenshots.

**5. Start the service adapter**

Run one service adapter as a foreground process:

```bash theme={null}
tensor9 adapt svc run \
  --origin "$T9_ORIGIN_SERVICE" \
  --backend "$T9_BACKEND_SERVICE"
```

Leave this terminal open. This is the current foreground launcher, not the pending Docker launcher for [local development mode](https://docs.tensor9.com/cloud-adapter-early-access/deployment/single-binary.md). 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:

```bash theme={null}
export T9_CLOUD_ADAPTER_ENDPOINT="<endpoint printed by tensor9>"
```

Keep the endpoint local to the test unless you have deliberately configured network access and authentication for another machine.

**7. Run one bounded request**

Continue with this page's client or tool instructions. Point only the service under test at `T9_CLOUD_ADAPTER_ENDPOINT`, then perform one operation whose target effect you can verify independently.

Check both sides: read the origin-shaped response and inspect the native target resource. 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 resource with the target cloud's native client.

If the request failed, preserve the request ID, adapter endpoint, operation name, target request ID, and any `x-t9-explain-*` receipt headers before stopping the process.

## 1. Check your service mapping

Find the origin service in the service reference under each cloud in the sidebar. Compare the backend choices and list the operations, request options and behaviors your application needs.

Include less frequent operations: initial resource creation, policy changes, pagination, deletion and recovery after a timeout. A successful read or write alone is not a compatibility assessment.

## 2. Choose the deployment scope

For a focused integration, begin with one service adapter. For a workload using several origin services, configure a cloud adapter with the required mappings. The [deployment guide](https://docs.tensor9.com/cloud-adapter-early-access/deployment/overview.md) explains the choices and who operates each component.

## 3. Prepare configuration and credentials

Record the target cloud and region, backend resources, storage and networking requirements, and the identity used to access the backend. Separately decide how application requests will be authenticated at the adapter endpoint.

Setup accepts a complete configuration file or asks guided questions to generate one. Both routes converge on the same configuration. See [configuration](https://docs.tensor9.com/cloud-adapter-early-access/configuration/overview.md).

Do not reuse production credentials in a first experiment. Use dedicated test resources and a scoped identity. Keep secrets out of configuration examples, issue reports and shared transcripts.

## 4. Define your first verification

Choose an operation with an observable outcome. For an object-store mapping, a useful test writes a small uniquely named object, reads it back, verifies its bytes and deletes only that test object.

Verify the result through the origin API and confirm it reached the intended backend. Capture status, response headers and resource identifiers. Include one expected failure, such as a missing object, so you also understand the error path.

## 5. Expand deliberately

Run the [local-testing checks](https://docs.tensor9.com/cloud-adapter-early-access/local-testing/overview.md), then repeat the relevant cases against the real target with test credentials. Measure your workload before and after any [tuning changes](https://docs.tensor9.com/cloud-adapter-early-access/tuning/overview.md).

Carry the tested configuration, native results and remaining questions into [Operations with Agents](https://docs.tensor9.com/cloud-adapter-early-access/operations/overview.md). Give ongoing work an owner, explicit permissions and a stopping condition.

If a required mapping or operation is absent, ask the included [Support Agents](https://docs.tensor9.com/cloud-adapter-early-access/support/agents.md) to assess the exact direction and operation list, then escalate to Tensor9 where needed. Do not infer support from a similar service name or a cloud logo.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.