Product preview
Viastead is not production-ready. These guides include planned functionality; protocol tables describe the intended scope.
HTTP access policy enforcement is not live. TCP availability depends on your workspace and deployment.
CLI reference
This reference uses the earlier Endpoint terminology. In the console, a Relay represents that API object. Platform Relay Nodes are separate infrastructure. Start with the Relay guide for the current workflow.
Skeleton. The CLI is not released, and its command names and flags are not settled. This page is the structure the reference will fill, plus the behaviour that IS already decided — which is worth writing down now, because it is the part that constrains everything else. Nothing below should be treated as a stable interface. Where a name is not decided, this page says so rather than picking one that would then have to be broken.
What is already decided
These come from the product specification and will hold whatever the commands end up being called.
The CLI is one of two equal places to confirm an exposure
The first time you expose a new Service, you are asked to confirm once, on whichever side you are already working — CLI or console. The other side shows that it happened but does not ask again.
This matters if you are scripting: there is exactly one confirmation, and it is not a double approval. Until it happens the Endpoint stays a draft and has no public address.
The confirmation prompt names both addresses
It tells you the local address and the public URL together, so you can check you are exposing what you meant to. A prompt that only asked "are you sure?" would give you nothing to check.
--help is a first-class surface
Most people meet this tool through --help and the first screen of the console, and never read a documentation site. --help is expected to be sufficient for the common path on its own.
Exit codes distinguish "refused" from "broken"
A command that was refused for a reason you can act on — over quota, not approved, insufficient role — must not exit the same way as a crash. Scripts need to tell a policy decision from a failure, and retrying a policy decision is pointless.
The specific numbers are not assigned yet.
Structure this reference will take
Each command gets: one-line purpose, synopsis, flags with defaults, at least one worked example, the exit codes it can produce, and what it does NOT do.
Planned command groups
| Group | Covers | Names settled? |
|---|---|---|
| Authentication | Signing the CLI in against a Workspace | No |
| Connector | Install, status, version, disable, revoke | No |
| Service | Registering a local address the Connector can reach | No |
| Endpoint | Creating a public address, pausing, deleting | No |
| Access policy | Public / passcode / IP allowlist / OAuth | No |
| Diagnostics | Connectivity checks, last error, log location | No |
The groups follow the object model — Site, Connector, Service, Endpoint, Access Policy — because those are the nouns the product is built from and the ones the console uses. A CLI that invented different nouns would make the two surfaces harder to learn than either alone.
Not in the CLI, deliberately
- Approving a Connector. Approval requires checking a machine fingerprint against the machine in front of you, and it is restricted to a human session — an API key cannot do it. A CLI flag would turn a deliberate check into a scripted one.
- Anything that changes billing. Plan changes and payment methods live in the console.
Conventions the reference will follow
- Every example is copy-pasteable and complete. No
<placeholders>that are not explained on the same screen. - Every destructive command states what is lost before it asks. Deleting an Endpoint permanently retires its address after the restore window — a confirmation that does not say so is not a confirmation.
- Long output is paged, never truncated silently.
- Nothing prints a credential. Tokens are shown once at creation and never again, including in logs and error messages.