Teams & agencies / One project, different audiences
Keep the team connected to the work.
Connect colleagues and contractors to project tools, storage and workstations. Keep client-facing reviews separate from private team access.
Available with assisted setup. Confirm the supported devices, locations and connection scope before deployment.
01 / Follow the project
The work stays in the studio.
The team can reach it.
A designer at home, a developer using a studio workstation and a contractor joining one delivery need deliberate access to the same project. A client reviewing the result needs a different path.
The shared workspace can stay in the studio.
- TeammateSupported laptop or mobile device→WireGuard
- Fibmesh routing nodePermitted private access→WireGuard
- Studio gatewayRoute to approved resources→LAN
- NAS / workstationFiles or remote work session
People in different places can reach the same approved tools and files without moving all of them to a public service.
File locks, access rights and remote desktop software belong to the applications. Transfer speed depends on both internet connections, latency and the host.
Explore team tools →Share the work without adding the client to the network.
- ClientOpens a review URL→HTTPS
- Publish gatewayOne selected web application→WireGuard
- Project hostTunnel reaches the app
A Publish link can give a client browser access to a review app while administration stays private.
Protect confidential work with application login; a hard-to-guess URL is not access control.
Explore Publish →Keep an integration recognisable when the team moves.
- Integration workerStarts the provider request→WireGuard
- Fibmesh public sourcePublic IPs or suitable exit→HTTPS
- Client / SaaS APISource allowlist + API login
An assigned source can support external systems that expect requests from a known address.
Choose which traffic uses Fibmesh. Changing office Wi-Fi does not itself transfer allocations or keep active sessions alive; the supported connection must recover.
Plan outgoing identity →These are separate connection choices. Keep the private project resources, public review app and outgoing integration scope explicit.
02 / Give each audience a purpose
One project.
Three access decisions.
Begin with the person and the task. Reaching a private folder, using a remote workstation and opening a client review are different permissions, even when they belong to one delivery.
01
Employees
The project’s working resources
Approved colleagues use supported enrolled devices to reach the NAS, project tools or workstation they need.
Explore shared team resources →Keep existing file permissions, application accounts and remote desktop controls. A private connection does not replace them.
02
Contractors
A defined assignment
Give each collaborator a path to the resources needed for their part of the delivery.
Work across locations →Check their permissions separately from employees. Name the administrator who will remove network and application access at handover.
03
Clients
One browser-based review app
Share a selected review application through Publish without enrolling the client in the team’s private network.
Explore preview and review scenarios →Require application login for confidential work. A hard-to-guess review URL is not access control.
A separate public listener
Share the review app.
Keep administration private.
A client opens a browser-based review through Publish. That selected listener is separate from the NAS, workstation administration and other private team resources.
Explore Publish →- 01 / HTTPSClient browser
Review URL and application login
- 02 / Selected listenerPublish gateway
One selected web application
- 03 / WireGuardProject host
Tunnel reaches the review app
Application authentication still protects the work. The review URL alone does not establish who may use it.
03 / Choose the connection
Start with private
team access.
Networks connects approved devices to the project’s private resources over supported existing internet connections. Use your existing file, remote desktop and project tools.
Explore Networks →Plan access to shared storage →For browser-based client review
Publish the selected app.
Use Publish when a client needs the review application without joining the private network. Keep application login and private administration in place.
Explore Publish →For integrations with source allowlists
Assess the outgoing identity.
Public IPs or a suitable Outbound exit can serve some outgoing-identity needs. Current Outbound profiles are full tunnel, with one active organisation-wide profile; changing it affects eligible device traffic beyond one project integration.
Plan outgoing identity →Choose the connection needs first, then confirm commercial scope. Not every project needs all four products. Compare the connection options →
04 / Your first working result
One project, with the right people connected.
Connect a colleague or contractor to a project folder, tool or workstation. Evaluate a real working session before extending access across the studio.
Explore private team tools →- 01
Complete the work
Open a representative project file, run a build or use the remote workstation. Test a real session on the connections people will use, including large transfers or interactive work.
- 02
Check each person’s scope
Verify employee and contractor permissions separately, including a resource they should not reach. Test client review through the selected app and its login.
- 03
Finish the handover
Remove network membership and the relevant application accounts. Remove public mappings that are no longer needed, then verify that withdrawn access stops. Keep a local recovery path.
A completed session is the acceptance test.
Connectivity does not guarantee large-file transfer speed or interactive performance. Remote rendering and workstation use depend on the application’s licensing, software and hardware. Test before committing a deadline.
05 / A practical first deployment
Connect one project
before the whole studio.
Bring one resource, one administrator and a useful task to the first deployment. Keep the access review and handover part of the project plan.
- 01
Name the working resources
Identify the project folder, application or workstation, its administrator and the tools people will use. Confirm endpoint support or a supported gateway path to the local resource.
- 02
Separate the audiences
Record what employees, contractors and clients each need. Set the intended permissions and a review date, with a named owner for removing access.
- 03
Test the actual work
Complete a useful task before extending access across the studio. Check the application, realistic performance, reconnecting and the removal procedure.
Planning access across the wider organisation?
Explore Business IT →06 / Questions, answered
Before you connect.
Can a team work from different countries and providers?
The model is independent of the access provider, using supported existing internet connections. Check service regions, local restrictions, endpoint support and latency. It does not promise service availability in every country.
Can access end automatically on a project date?
Do not assume an automatic expiry feature. Set a review date and have an administrator remove membership, public mappings and application access when the work ends.
Can we use render machines or large media files?
Private connectivity can provide a path to supported workstations, render services and storage. The application, licensing and hardware must support remote use. Test large transfers and interactive sessions before relying on them for a deadline.
Does every project need a new product subscription?
Start with the connection needs, then confirm commercial scope. Not every project needs all four products, and Public IPs and Outbound are alternatives for some outgoing-identity requirements.