Connectivity

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.

A Tensor9 deployment has four distinct network links with configurable paths. Each one carries a different kind of traffic, has different defaults, and exposes different options. This page covers them in one place so you can reason about them together. The first three are normal day-to-day links. The last is reserved for exceptional situations.

​

Application ingress

Once your application is deployed into a customer appliance, your users reach it over whichever ingress path your origin stack defines: a public load balancer, a private path, a Tailscale-attached endpoint, or anything else expressible in your IaC. By default, Tensor9 does not modify this link. The shape of customer-facing ingress is determined primarily by your application’s IaC and the customer’s environment. However, your customer may prefer a narrower scope of access. The customer-facing options Tensor9 surfaces are summarized on the Private ingress page.

​

Operator to control plane

When you run tensor9 commands, or when an origin-stack deploy executes its plan and apply against an appliance, your CLI talks to your vendor control plane. The control plane’s network surface exposes a small set of mutually-authenticated listeners for this traffic.

​

Default: public load balancer with mTLS

By default, the control plane’s listeners are reachable over the public internet via a network load balancer. Every connection is mutually-TLS authenticated using operator certificates that Tensor9 issues during enrollment. No public access is granted; the listener accepts only certificate-presenting clients on the operator allowlist.

​

Optional: route operator traffic over Tailscale

If you operate a Tailscale tailnet for your engineering team, you can have your vendor control plane join that tailnet and expose the same operator listeners over it. Once joined, your operators can reach the control plane at its tailnet hostname without leaving Tailscale. A step-by-step guide to onboarding is provided in Common Workflows.

​

Optional: remove the public path

After your operator tooling is reliably reaching the control plane over Tailscale, you can remove the public-internet path for the operator-side listeners: CLI, Terraform, and Appliance services. Each service is gated individually so you can roll out the change in stages. See our step-by-step guide to onboarding in Common Workflows for more details on this process.

​

Appliance to control plane

Every customer appliance establishes an outbound, mutually-authenticated connection from its on-prem controller back to your vendor control plane. This connection is the channel for telemetry, deploy instructions, and operations commands. It is always initiated from the customer side; the customer’s environment never accepts inbound connections from yours. See the customer security model for the underlying handshake. The connection itself is the same regardless of the network path. The available network paths today are: You select which paths a form factor permits when you author it; the customer (or you, when generating an appliance-setup link) then picks one of the permitted paths for each appliance. See the AWS form factor page for how the choice is exposed for AWS.

​

Vendor-provided Tailscale (TailscaleVendor)

The vendor operates a tailnet. Both the vendor’s control plane and each enrolled customer appliance join it. The appliance-to-control-plane handshake then travels the tailnet instead of the public internet or PrivateLink. This is particularly useful for:

• Test appliances and other vendor-operated environments where you want all appliance-to-control-plane traffic on a single private network you control.
• Customer environments that allow outbound Tailscale but prefer not to expose direct internet egress to the vendor control plane’s public listener.

Enrollment is operator-supplied: when you create an appliance-setup link with a TailscaleVendor-permitted form factor, you provide the buyer’s pre-auth key, and the customer’s appliance uses it at boot to join your tailnet.

​

Customer-provided tailnets

A symmetric variant where the appliance joins the customer’s tailnet via tsnet and the vendor control plane reaches into it is not yet available. Contact us if this would unblock a deployment; we’d be interested to talk through specifics.

​

Break-glass emergency access

In rare situations a vendor operator needs to reach further into the customer environment than the standing operations channel allows: a live incident, an application failure, or a customer-requested deep-debug session. Tensor9 supports time-limited, audited break-glass access for these cases. Today operators may use Twingate or Tailscale to request time-bound access to the application VPC. The operator requests elevated access, the customer approves, a connector grants the operator a scoped, expiring network path into the customer environment, and every action is logged. Border0 break-glass option is planned but not yet available. Break-glass is intentionally separate from all other connectivity links defined: it is reserved for situations that the standing channels are not designed to cover, and it carries stricter approval and audit requirements. See operations security for the request, approval, and audit model that applies to elevated access.