CLI & automation

CLI design reference

How the command-line workflow is intended to work.

The commands on this page are proposed syntax. They are not supported installation instructions or a released CLI contract. No download or executable quickstart is offered here. Publish is available with assisted setup; the CLI syntax remains proposed.

The intended CLI authenticates to your workspace, requests changes from the backend and shows whether those changes are actually working. The local background service handles the WireGuard connection and forwarding. Endpoint private keys stay on the endpoint.

Create

Several applications. One connector.

After selecting an enrolled connector, identify each application by its local address and port. These examples explicitly choose public access; the applications must supply any required login or API authentication.

# Proposed syntax — not executable release documentation
fibmesh publish create portal --connector studio-server \
--target http://127.0.0.1:3000 --access public
fibmesh publish create api --connector studio-server \
--target http://127.0.0.1:8080 --access public
fibmesh publish create preview --connector studio-server \
--target http://127.0.0.1:5173 --access public

portal: A name for this publication, so you can inspect or pause it later.
–connector: The enrolled machine that will reach the app. It can be different from the computer running the CLI.
–target / –access: The app’s URL from that connector, and whether requests may reach it from the public internet.

Each publication receives its own managed hostname. A successful request should return the publication ID, target, intended access policy and provisioning state. It must not report “live” before the certificate, connector and public path are verified.

Remote administration

Select the connector that can reach the service.

# Proposed syntax
fibmesh publish create inventory --connector office-edge \
--target http://192.168.1.20:8080 --access public

The target is evaluated from office-edge, not from the laptop issuing the command. The same rule applies to localhost: it always refers to the selected connector’s host environment.

The preview should show the chosen workspace, connector and target before activating exposure. An unrecognised connector, unsupported protocol or unauthorised target should stop the operation rather than select a convenient default.

Day-to-day work

Inspect first. Change one publication at a time.

# Proposed syntax
fibmesh publish list
fibmesh publish status portal
fibmesh publish pause preview
fibmesh publish resume preview
fibmesh publish delete preview

Illustrative status response — proposed output

Publication   portal
Connector     studio-server · online
Target        http://127.0.0.1:3000 · responding
Public URL    https://studio-portal.publish.fibmesh.example
HTTPS         certificate pending
Status        waiting — public link not ready

This example shows why a saved publication should not immediately be called live: the app is responding, but its public certificate is still pending.

Status should distinguish requested configuration from observed reachability. Pausing a preview preserves its reserved hostname while stopping new requests. Deleting it needs a clear explanation of hostname retention and existing-session handling.

Persistent publication

Configuration belongs to the workspace and background connector. Closing the terminal does not stop it. The host, connector and application must still remain running.

Temporary sharing · proposed extension

A temporary publication has an explicit expiry and audience. It should expire at the gateway even if the terminal or host disappears, rather than relying on a clean shutdown.

Automation design

Repeatable configuration without credentials in the file.

A declarative file could describe the intended publications while credentials remain in the authenticated client or a scoped automation secret store. This is a configuration sketch, not an accepted file format.

# Illustrative configuration — schema is not final
connector: studio-server
publications:
- name: portal
  target: http://127.0.0.1:3000
  access: public
- name: api
  target: http://127.0.0.1:8080
  access: public

For deployment pipelines, the intended workflow is to preview changes, apply them and wait for a verified result. Repeating the same configuration should not create duplicate links. Scripts need scoped credentials and a clear success or failure result. Removing an entry from a file must not silently delete a live publication.

Dashboard and CLI changes should carry the same ownership checks and audit events. Neither interface should bypass backend policy or report success from a local configuration write alone.

An address for your app, from your terminal.