Architecture you can inspect
Follow authority, execution and the traffic boundary.
- 01
Your intent
Connect an approved person to a private resource, publish an application, assign a public address or choose an outbound identity.
An action in the workspace or a supported API request - 02
Fibmesh policy
Check the resource’s identity, permissions and entitlement. Record the authorised desired configuration for that connection.
Backend policy is the source of truth - 03
Delivery and verification
A supported endpoint or gateway validates and applies its configuration, then reports state. Compare what was requested with what was observed.
Reported state and a working application path are separate checks
The dashboard requests and inspects. Endpoint private keys remain local by default; runtime credentials have their own scope.
Review a proposed deployment
Ask for evidence at the service boundary.
- Identity
Where are keys generated and retained? Who owns the resource and can authorise its reachability?
- Traffic
Where does the selected path terminate, and which application permissions remain the customer’s responsibility?
- Data
What account, policy, gateway and diagnostic records are collected, where are they processed and how are they retained?
- Operation
Which native releases, markets, service locations, support owners and recovery procedures are verified?
Service responsibilities
Know how your service is operated.
Fibmesh is building a connectivity platform in which reachability is a deliberate decision. This reference separates the architecture from the evidence required to operate a customer service.
The security model
Endpoint identities belong to devices and workloads. Their private keys stay local by default. Backend policy decides which resources an identity may reach; a native endpoint or gateway applies the permitted state. Dashboard controls do not perform privileged network changes themselves.
Public publishing adds a separate exposure decision. Knowing a resource exists does not authorise a connection to it. Customer approval, endpoint health and observed execution all matter when evaluating a working path.
Read the security architectureEach service needs its own evidence
| Service | Boundary to evaluate | Evidence required before operation |
|---|---|---|
| Networks and private workspace DNS | Approved identities and private resources; workspace names belong to that access model. | Native release behaviour, policy enforcement, recovery and observed data handling. |
| Publish and Public IPs | Explicit publishing or an assigned address, with ingress permission and a return path. | Publishing scope, firewall rules, assignment lifecycle, revocation and gateway operation. |
| Outbound | A source identity or an approved default route; these are different traffic decisions. | Regional gateway operation, routing and failure behaviour, service classification and retention. |
| Edge hardware | A physical endpoint with model-specific ports and supported software. | Verified hardware, supply and support arrangements, applicable market approvals and update lifecycle. |
Connectivity permissions do not make a public resolver operational. An Edge development concept does not establish hardware certification or an available appliance. No certification, audit badge, guaranteed uptime or blanket global compliance is claimed here.
Follow the data, not a slogan
Account information, identity records, policy state, gateway events and diagnostic material have different purposes. The implementation must establish what it actually collects, who can access it, where it is processed and how it is deleted. Support bundles must redact tokens, keys and secrets.
A secure tunnel describes a transport property. It does not, by itself, establish application encryption, a no-logs service or a data-residency guarantee.
Responsibilities on both sides
Fibmesh must verify the software, gateway operation and policy delivery it offers. A customer must review who can join their workspace, which resources they publish and the application permissions behind those resources. An approved network path does not replace an application’s authentication or security updates.
Understand customer and platform responsibilitiesReporting and legal documents
Security reports, abuse cases, privacy requests and lawful requests need separate owners and restricted handling. The policies and reporting directory lists documents approved for publication, with their applicable service scope and contacts. Documents remain unpublished until their operating facts and review are complete.
Evaluate the proposed deployment
Begin with the resource and the intended audience. Then review the supported endpoint, traffic path, market and recovery behaviour. The availability reference explains what has and has not been verified; the support reference sets out what an operating handover needs.
Review release and market availabilityPolicies and reporting
Reporting routes and legal documents have not been published in this preview.