How Operations Work

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 lets you submit vetted templates against a customer’s appliance. Execution requires the customer’s approval or a verified pre-approval covering the command. The command runs inside the appliance; its result record is encrypted before control-plane storage, while the key stays in the customer’s vault. You receive plaintext after authorized output release.

Define, request and authorize

You define a template and request one command against a customer appliance; customer-signed approval or verified pre-approval precedes execution.

You define a template and request a command against one customer appliance. The customer authorizes execution through signed approval or a verified pre-approval; the appliance verifies it before dispatching an available worker. Support links belong to the support-request flow; plain CLI submission does not attach that request metadata. Arrows show the approved-case sequence; rejection and deadlines are covered in Running Commands.

Execute and release output

The customer appliance runs a command and encrypts its result with a customer-held key; output reaches you only after authorized release.

The command runs inside the customer appliance, which captures stdout, stderr and exit code. The result record is encrypted before control-plane storage, and its key stays in the customer vault. Output reaches you after authorized release: CommandsOnly pre-approval still requires output review, while a verified FullyPreApprove grant covers release. Arrows show logical sequence, not network hops or new resource permissions.

The four entities

Operations works in terms of four objects. Knowing what each one is makes the rest of the docs much shorter.

Entity	What it is
Template	A 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.
Source	A 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 command	A 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-approval	A 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

The approved path separates execution approval from output release. Running commands covers the full lifecycle, including pending decisions, rejection, cancellation and deadlines:

Review

For per-command review, your customer reads the template description, declared data-access tags, your reason, command body and variable values. They can approve, reject or leave the decision pending.

Approve

The appliance verifies approval and dispatches execution when a worker is available. A verified pre-approval covering the command can supply the decision without another per-command review.

Execute

The command runs inside the appliance and captures stdout, stderr and exit code. The normal result path signs and encrypts the result record with a per-command key held in the customer’s vault. Blob-backed output streams remain distinct from that record.

Release

For per-command release, your customer reviews the output in their environment and signs an Ed25519 release manifest. CommandsOnly pre-approval still requires this output review; verified FullyPreApprove coverage can authorize release without another per-command decision. The appliance supplies plaintext after authorized release, and your control plane forwards it to you.

Command approval and output release are authorized by signed manifests, and the normal execution path signs its result record. These signatures do not imply that every internal lifecycle update is individually signed. You can verify the audit chain with tensor9 ops command audit verify.

What your customer sees

For commands created through the support-request flow, your customer can use the /support/<token> link to their Customer Portal. The guided wizard lets them review and approve or reject the command, watch execution, and authorize output release. Plain CLI submission does not itself attach that support-request metadata. Your customer can also review and approve pending operations from the Operations section of their Customer Portal. Your customer’s portal session remains separate from yours. Your control plane can store the encrypted result record before release; plaintext becomes available to you after authorized release.

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 appliance	Running commands
Let your customer pre-approve a template once for repeated runs	Standing pre-approvals
Understand the keys, signatures, and audit guarantees underneath	Security 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. Watch lifecycle progress while you wait for approval and release.
#    Support-request commands use their support link; plain CLI submission
#    does not attach that request metadata:
tensor9 ops command retrieve --appName my-app --commandName check-myapp-disk

Each of those three commands is unpacked in detail on the corresponding subpage.

Tensor9 BYOC

Getting Started

Self-Service Onboarding

How It Works

Deploying

Your Customer's Environment

Service Adapters

Costs

Auto-Customizations

Security

Connectivity & Networking

Observability & Operations

Support

tensor9 CLI

How Operations Work

Define, request and authorize

Execute and release output

The four entities

The four-step lifecycle

What your customer sees

Where to go next

A minimal end-to-end

​Define, request and authorize

​Execute and release output

​The four entities

​The four-step lifecycle

​What your customer sees

​Where to go next

​A minimal end-to-end

Define, request and authorize

Execute and release output

The four entities

The four-step lifecycle

What your customer sees

Where to go next

A minimal end-to-end