See how Fibmesh handles resource identity, policy and network changes, then examine the operating information and policies needed for a service launch.
Follow authority, execution and the traffic boundary.
01 / Architecture
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
Privileged operations stay with the supported executor.
The dashboard requests and inspects. Endpoint private keys remain local by default; runtime credentials have their own scope.
Conceptual architecture · The stages explain control and feedback, not three compulsory traffic hops. Delivery and encryption boundaries depend on the selected capability.
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.
02 / Evidence
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.
Scroll sideways to compare the service boundaries. Focus this region and use the arrow keys on a keyboard.
Service-specific trust boundaries
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.
What does a secure tunnel establish?
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
Scroll sideways to read the responsibilities. Focus this region and use the arrow keys on a keyboard.
Platform and customer responsibilities
Scope
Responsibility
Fibmesh
Fibmesh must verify the software, gateway operation and policy delivery it offers.
Customer
A customer must review who can join their workspace, which resources they publish and the application permissions behind those resources.
Application security
An approved network path does not replace an application’s authentication or security updates.
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.
Take the review forward
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.
