Command-line access
There are working CLI tools. Full network management is not yet a CLI workflow.
The development CLI includes local status and diagnostics, device registration, gateway inspection and policy retrieval. The API contract separately defines private-network creation, membership and subnet routes.
Current scope: a dedicated Networks command group is not implemented in the checked CLI. Its login command is also a pending implementation. Do not treat the examples here as a production installation or authenticated signup guide.
Networks should support both interactive administration and automation. A complete CLI release needs a verified authentication flow and clear commands for the network lifecycle, with readable output for people and structured results for scripts.
Implemented command scope
Start by inspecting the device you are on.
fibmesh status
fibmesh diagnosticsThese commands read local identity and policy-cache state. An enrollment record or cached policy does not prove that a live tunnel works, that the newest policy was applied, or that an application is reachable.
| Command or command family | What exists in the development CLI | What it does not establish |
|---|---|---|
fibmesh status |
Reads local enrollment and cached policy details. | A live end-to-end connection test. |
fibmesh diagnostics |
Summarises local device, policy and configuration state. | Production health or application availability. |
fibmesh device register |
Submits a device registration with a public key. | Complete signed-in enrollment and traffic delivery. |
fibmesh policy fetch |
Retrieves endpoint policy; optional local caching. | That the native service applied it successfully. |
fibmesh gateway list |
Requests gateway records. | Automatic gateway installation or site routing. |
fibmesh device apply-results and fibmesh gateway apply-results |
Inspect reported execution results. | That a separate application test has passed. |
API-calling commands need an authorised environment. The checked development CLI defaults to a local API and does not provide a finished production login flow. Keep endpoint private keys local; never paste a private key into an API request or support ticket.
Documented API operations
A network, its members and its approved routes.
| Operation | Contract endpoint | Purpose |
|---|---|---|
| List networks | GET /v1/private-networks |
Inspect networks within the authorised organisation. |
| Create a network | POST /v1/private-networks |
Create the named private-network record. |
| Inspect a network | GET /v1/private-networks/{id} |
Retrieve a network record. |
| Add a member | POST /v1/private-networks/{id}/members |
Submit an identity or device membership. |
| Add a subnet route | POST /v1/private-networks/{id}/routes |
Record a destination range and its advertising device. |
The contract identifies these as authenticated user operations. It does not establish a service-account or machine-token workflow for unattended automation. Confirm the public endpoint, authentication method, permissions and supported deployment before integrating.
The dashboard currently calls private-network groupings “Access groups”. The API retains private-networks; “Networks” is the public product name. These are related concepts, not instructions to rename the API.
A successful response confirms the requested administrative operation, not a complete connection. Member addition returns membership_accepted. Route records include approval_status; policy execution and a real resource test still need verification.
Automation that can be operated
Make the outcome visible to the person running the script.
- Check the scope
- Identify the organisation, network, member and destination before submitting a change. Validate address ranges and existing routes.
- Inspect the result
- Read returned records and the relevant endpoint or gateway reports. Check timestamps and policy versions so an old result is not mistaken for the new change.
- Test the resource
- Verify the intended application with an approved device and a denied control. Application authentication and data permissions remain separate.
Do not blindly retry a creation request after a timeout: first reconcile whether it succeeded. The listed network operations do not establish an idempotency-key contract. Handle duplicate intent deliberately and stop after a defined timeout.
For servers and cloud deployments, a future dedicated network CLI should make create, inspect, join, leave, route changes and removal explicit. Those are proposed lifecycle capabilities, not runnable command names or promised release dates.
Before depending on automation
Creation needs an equally clear way to undo it.
The checked network API does not expose a complete edit, member-removal, route-removal or network-deletion lifecycle. Do not invent delete endpoints or assume that the presence of an archived field makes an archive operation available.
For an assisted deployment, agree the supported operator procedure for withdrawing access, retiring devices and removing routes. Verify the applied state and application sessions after removal. This is a release requirement for a production automation workflow.
General CLI diagnostics, an API contract and a released network-management CLI are distinct deliverables. The website will describe the verified scope of each; it will not present proposed commands as a working quickstart.
Prepare a first deployment and verification plan →