Skip to main content

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.

This page covers how credentials flow through the system and the guarantees we make about their handling.

​
Credential Ownership

There are three categories of credentials in a deployment:

​
Credentials You Provide

These are secrets the application needs from you - API keys, tokens, database passwords, webhook URLs. During setup, the interface tells you exactly what’s required and gives you the commands to create them. How they flow:
1

Run command

You run a command on your workstation (kubectl or AWS CLI).
2

Secret created locally

The secret goes directly from your terminal into your cluster or cloud secret manager.
3

Detection

The controller detects the secret exists.
4

Confirmation

The setup interface updates to show a checkmark.
At no point does the secret value pass through our systems. The path is: your terminal - your infrastructure. We see only the checkmark.

​
Credentials We Provide

Some secrets come from us - internal service credentials, license keys, or pre-configured tokens. These are injected automatically during deployment. You don’t need to create or manage them.

​
Credentials Generated at Deploy Time

Some secrets are generated fresh during deployment - random passwords, internal tokens, auto-generated keys. These are created directly in your infrastructure by the controller. They never transit through our systems.

​
Where Secrets Are Stored

Kubernetes Secrets (in your namespace), created by you via kubectl.

​
During Part 2 Configuration

After the controller is online, some deployments have a second configuration step where you provide secrets and domain settings. This step uses a direct connection:
1

Start

You run a setup command on your workstation.
2

Local server

A local server starts on your machine (localhost only).
3

Direct connection

The server communicates directly with the controller over your network.
4

Secrets stay local

Secrets travel from your workstation to your controller.
5

No external transit

The connection never leaves your infrastructure.
This means even during interactive configuration, your secrets stay within your network perimeter.

​
Secret Rotation

You can rotate any secret you created by replacing it in your secret store: 
kubectl delete secret <name> -n <namespace>
kubectl create secret generic <name> -n <namespace> --from-literal=key=<new-value>
The controller detects the change automatically. In most cases, no application restart is needed.

​
What We Guarantee

  • We never see your secret values - only existence/absence status
  • We never store your credentials on our infrastructure
  • We never transmit your secrets over the network between your infrastructure and ours
  • You can rotate at any time without coordinating with us