Platform / From intent to evidence
From your rules to a working connection.
Fibmesh turns access decisions into policy that supported devices and gateways apply. Follow a change from the dashboard to the network, then check the result.
Explore the security model ↗01 / The shared foundation
Identity first.
Permission for each path.
Fibmesh adds a connectivity layer over the internet connections you already use. A supported device joins directly; a site or cloud network can join through a gateway. You grant the connections that are needed, whether that is private access, public reachability or an internet exit.
The fabric is the shared identity, policy and delivery behind those connections. It is not one flat LAN: joining does not give every resource access to every other resource. Your ISP still supplies internet connectivity, and your applications keep their own accounts and permissions.
02 / Follow a policy change
A decision becomes configuration.
A connection uses a route.
A supported local executor validates its configuration before changing tunnels, routes, DNS or forwarding. The dashboard requests changes and shows state; it does not directly perform privileged networking on the device.
Decide and distribute.
- Dashboard / API / CLIAuthorised request
- Backend policyOwnership, permission, entitlement
- Local executorValidate, apply, report
Carry application traffic.
- Enrolled deviceWireGuard tunnel
- Fibmesh routing nodeTunnel termination
- Enrolled serverWireGuard tunnel
The traffic path depends on the product. This private example has two tunnel legs; a site gateway adds its own final resource hop.
Delivery depends on supported software, serving locations and your agreed service. The illustration does not establish worldwide coverage.
Three separate outcomes to check.
Read the request, the runtime report and the application result separately.
The intent is saved.
A saved request can be waiting for delivery.
The runtime reports execution.
A route conflict can prevent configuration from applying.
The application actually answers.
Even an applied route cannot make a stopped application answer.
WireGuard is the available tunnel protocol. It protects the tunnel segments where it runs; the gateway and any final LAN or internet hop have their own security boundaries. Direct device-to-device P2P remains planned.
03 / Put the model into practice
Grant the path.
Verify the result.
Enrol
Give the supported device or gateway a workspace-bound identity.
Authorise
Choose the product and grant the specific destination or route.
Apply
The supported runtime validates and applies approved configuration.
Verify
Check reported state and test both permitted and denied access.
04 / Names, ownership and permission
Know the resource before granting the connection.
A workspace-bound identity.
An enrolled device has a workspace-bound device ID, public-key identity and private addressing. Its private key stays local by default. Moving the same physical machine into another workspace requires a separate enrollment and policy scope.
Access follows the grant.
An access group changes permissions, not the device’s identity. Joining a group does not create a new enrollment or private address. Equipment reached behind a gateway keeps its LAN address and is not automatically an individually enrolled Fibmesh device.
Find it. Then authorise it.
Private workspace DNS belongs within Networks. A name helps locate a resource; resolving it does not grant access, supply an application certificate or replace login. Public names for Publish and public address allocations have separate purposes.
05 / Run it day to day
Make the change.
Keep an owner.
Record who owns each resource and who can change its access. Keep the platform, serving location and local networking dependencies with the setup record so another operator can investigate a problem.
Developer and automation references →Changing, removing and automating a connection
For changes, inspect requested and observed state rather than treating a saved setting as a successful connection. For removal, withdraw the grant or disable the relevant capability and verify that access stops. Public IP pause, resume and release have a different lifecycle from enabling or disabling an Outbound profile.
Dashboard, API and CLI are ways to manage the platform, but their current coverage differs. The CLI is still a development surface; not every dashboard action has a command. Use the product-specific references for implemented operations, authentication and remaining gaps.
How do I read an apply result?
The runtime contract distinguishes success, partial_success, failed and rejected. Compare the reported generation with the intended one and investigate skipped operations. These results describe configuration execution; application reachability needs its own check.
Questions about the platform
What changes when you use Fibmesh?
Does “programmable” mean every operation is automated today?
No. It describes managing connection intent through software and policy. API and CLI coverage, provisioning and native execution must be checked for the selected product and release.
What happens if a connection or gateway fails?
Behaviour depends on the product, routing mode and deployed runtime. Check retry, expiry, route restoration and fail-closed behaviour during evaluation. The shared platform model does not promise automatic failover, uninterrupted sessions or universal kill-switch protection.