Management options
An API contract exists. Dedicated CLI commands are still to be built.
Public IPs can be managed programmatically through an authorised service integration. The documented API covers assignment requests and their lifecycle. Public access, authentication, supported environments and entitlements must be confirmed before using that integration.
CLI status: the checked Fibmesh CLI has device, gateway, ingress and egress commands, but no dedicated Public IP command group. Public IP list, request, pause, resume and release commands are a proposed addition. There is no runnable Public IP CLI quickstart on this page.
Existing ingress commands manage selected service rules; they do not allocate a Public IP. Existing egress commands do not establish a complete Public IP management workflow either. The API contract and a working command-line release are separate milestones.
Documented API operations
One assignment record for the requested address.
| Operation | Contract endpoint | Meaning |
|---|---|---|
| List | GET /v1/public-ip/assignments |
Inspect the organisation’s assignments and delivery state. |
| Request | POST /v1/public-ip/assignments |
Record a request for an eligible device or gateway. |
| Pause | POST /v1/public-ip/assignments/{id}/pause |
Stop delivery while retaining the reservation. |
| Resume | POST /v1/public-ip/assignments/{id}/resume |
Request delivery using the same reservation. |
| Release | POST /v1/public-ip/assignments/{id}/release |
Remove delivery and relinquish the assignment after cleanup. |
A request identifies the target device or gateway, address family, requested region, traffic mode and firewall rules. Managed inbound rules start closed. Requests for fully open exposure require explicit confirmation.
The create operation uses an Idempotency-Key: retrying the same logical request with the same key and payload returns the original assignment. Reusing that key for a different payload is a conflict. This helps automation recover from interrupted requests without accidentally asking for duplicate allocations.
Understand the result
“Request accepted” does not mean “traffic delivered.”
- RequestedThe service has received the intended configuration.
- ProvisioningAllocation and delivery changes are being applied.
- ObservedInfrastructure and endpoint reports show what actually took effect.
- VerifiedYour application test confirms the path you intend to use.
These are workflow stages, not a replacement for the API’s exact status values. Check status, delivery_health, desired_generation and observed_generation. An older observation does not confirm the latest requested change.
Creation returns a record; pause, resume and release accept a change for processing. Inspect the returned state and subsequent observations rather than treating an HTTP success response as an immediate route change. Development fixtures use documentation addresses, which are not internet-routable allocations.
The actual serving location is reported separately from your preference. assigned_region and serving_pop identify the established allocation; changing the requested region does not move the same address automatically.
CLI and automation direction
Useful automation needs a complete lifecycle.
- Preview the change
- Show the workspace, target, traffic mode and exposure before applying a request. Use an authorised identity with only the access it needs.
- Wait for delivery
- Retry safely, check observed state, report a clear failure and stop after a defined timeout. Keep application checks separate from control-plane success.
- Handle removal
- Distinguish pause from release. Update DNS and allowlists before giving up an address, and check how full-tunnel access will recover.
The proposed CLI should expose these operations with readable output and structured results for scripts. Its command names, authentication flow and supported release still need implementation and verification; no command syntax here should be treated as available.
Keep endpoint private keys on the endpoint. Automation credentials belong in an approved secret store, not command examples, public configuration or support logs.
Scope boundaries
A routed block has its own provisioning requirements.
Routed Subnets is a separate invitation-led managed service, outside the app MVP. The current single-target Public IP assignment contract does not define a complete subnet allocation or floating-prefix API. Do not use a device assignment as a substitute for requesting a block.
The traffic-mode contract also does not define a complete selected-destination editor or a gateway multi-port mapping workflow. These depend on the supported delivery configuration. Service availability does not imply that every operation is exposed in a public API or CLI.
Review subnet delivery and requirements →Prepare a supported deployment →