Skip to main content
Your customers run your software inside their own cloud accounts. You have no SSH keys, no kubectl context, no AWS credentials. When something goes wrong (a pod crash-looping, a disk filling up, a backfill that needs kicking) you cannot just ssh in. Operations is the surface that bridges that gap. You ship vetted templates to your customers, submit a request to run one against one of your customer’s appliances, and your customer reviews and approves the request through a web link. The command runs inside their appliance, the output is held encrypted in the appliance’s secret store, and your customer signs a release before you see anything. How operations work in five steps: define a reusable script with named variables, request an execution against your customer's appliance, your customer reviews and approves it, the script executes on the appliance, and your customer signs again to release the output back to you.

​
The four entities

Operations works in terms of four objects. Knowing what each one is makes the rest of the docs much shorter.
EntityWhat it is
TemplateA small file you author (*.tensor9.tf, *.t9.sh, or *.t9.kubectl) describing one runnable operation: its body, declared data access, variables, and required permission tier.
SourceA Git repository whose templates are auto-imported into your control plane. You re-sync to pull new and modified templates as the repo evolves.
Ops commandA single submission of a template against a single customer appliance, with values bound for the template’s variables. Runs through a state machine from submission to released output.
Pre-approvalA customer-signed manifest that lets you run a specific template against a specific appliance up to N times within a validity window without per-command approval.
Templates and sources are write-once authoring artifacts. Ops commands are the per-execution objects. Pre-approvals are an optional optimization your customer can apply on top.

​
The four-step lifecycle

Every ops command moves through the same shape, regardless of which template flavor it uses or which appliance it targets:
1

Review

Your customer reads the template description, the declared data-access tags, your justification reason, and the exact command body and variable values. They pick Approve, Reject, or close.
2

Approve

On approval, the appliance prepares to execute. Pre-approved templates skip Steps 1 and 2 silently.
3

Execute

The command body runs inside the appliance’s sandboxed working directory. Output (stdout, stderr, exit code) is captured and encrypted with a per-command key the appliance holds in its vault.
4

Release

Your customer reviews the decrypted output (decrypted on the appliance, which lives in their own cloud account under their IAM), then signs an Ed25519 release manifest. Only after the signed release does the control plane forward the plaintext output to you.
The control plane never sees the plaintext output before release; you never see ciphertext. Every transition is signed, and the chain is verifiable independently with tensor9 ops command audit verify.

​
What your customer sees

When you submit an ops command, your customer is sent (via your existing notification channel) a unique /support/<token> web link to their Customer Portal. Clicking the link opens a guided approval wizard where they review the command details, approve or reject it, watch it execute, and then sign a release to share the output with you. Your customer can also review and approve pending operations from the Operations section of their Customer Portal. You never see your customer’s portal session. The only thing that crosses the boundary is the plaintext output (and only after your customer signs the release manifest).
On your side, you can track the status of ops commands in the Vendor Portal under Operate → Commands, or via the CLI with tensor9 ops command retrieve.

​
Where to go next

If you want to…Read
Author a template (file format, variables, permission tiers, data-access tags)Authoring templates
Maintain a Git repo of templates as a re-syncable source (the cmdlib pattern)Git template sources
Submit and track an ops command against your customer’s applianceRunning commands
Let your customer pre-approve a template once for repeated runsStanding pre-approvals
Understand the keys, signatures, and audit guarantees underneathSecurity model

​
A minimal end-to-end

To make the rest of the docs concrete, here is the shortest possible path from “no templates yet” to “you see released output”: 
# 1. Register a Git repo of templates as a source
tensor9 ops template source create \
  --sourceType GitHub \
  --sourceUrl https://github.com/tensor9ine/cmdlib \
  --appName my-app \
  --sourceName cmdlib

# 2. Submit one of those templates against a customer's appliance
tensor9 ops command create \
  --appName my-app \
  --customerName acme-corp \
  --template linux-disk-usage \
  --vars MOUNT_PREFIX=/var/lib/myapp \
  --commandName check-myapp-disk \
  --reason "investigating disk pressure"

# 3. Your customer follows the /support/<token> link sent to them.
#    Watch lifecycle progress while you wait:
tensor9 ops command retrieve --appName my-app --commandName check-myapp-disk
Each of those three commands is unpacked in detail on the corresponding subpage.