Developers / One workflow, deliberate paths
Your stack. Wherever you build.
Reach remote build hosts and private tools. Choose a separate path for public applications and connections to external APIs.
Available with assisted setup. Confirm the supported devices, locations and connection scope before deployment.
01 / Start with the work
Your laptop is the way in.
The build host does the work.
Reach an SSH host, development workstation or supported lab server privately. A reviewer opening your app and a build job calling an external API need separate connection decisions.
Reach the machine that does the heavy work.
- Developer laptopHome, office or mobile internet→WireGuard
- Fibmesh routing nodeApproved private connection→WireGuard
- Build hostSSH, tools and private services
Work on a remote host while the repository, database and build environment stay on that machine.
This shows the current node-routed model. Application credentials still apply; direct peer-to-peer connectivity is planned.
Explore remote development →Give each application its own public web address.
- Reviewer or webhook senderPublic HTTPS request→HTTPS
- Publish gatewaySelect the app by hostname→WireGuard
- Connected hostWireGuard tunnel→Local app
- Selected applicationLocal listener, such as port 3000
Publish maps separate hostnames to separate web apps on one connected machine. The visitor does not need to join your private network.
Keep application authentication and webhook signature validation. If a connector runs elsewhere, localhost refers to that connector, not another LAN machine.
Explore Publish →Give the integration an address its provider can recognise.
- Build workerStarts an API request→WireGuard
- Fibmesh delivery / exitConfigured public source→HTTPS
- External APIChecks source and credentials
Public IPs can provide an assigned public source under the selected routing mode. Outbound is an alternative when the requirement is an internet exit.
The external service must confirm the source it actually sees. An IP allowlist does not replace API authentication; verify IPv4 and IPv6 separately.
Compare the two approaches →Follow the direction of the request: private development, incoming review or outgoing API access. These illustrations describe separate choices, rather than a requirement to configure every product.
02 / Keep the environment in place
One host.
A useful development loop.
The build machine may be at home, in the office or in a cloud account. Networks gives approved developers a private path to the resources they need, while the repository and datasets stay on that machine.
Explore remote development →- The machine
- One supported build host
Record its operating system, administrator and a local recovery path.
- The work
- Repository, data and tools
Keep the working environment on that host. Use your existing editor, SSH tools and credentials.
- The audience
- Approved developers
Permit the people who need the host; test an unrelated user as well.
Incoming / Reviewer or webhook sender → your app
Share a selected listener.
A client can open a running review app through Publish without joining your private network. Separate hostnames can select separate applications, including different localhost ports on one connected host.
Keep reviewer application login and webhook signature validation. Keep databases, administration and other listeners private; a reachable URL does not establish who may use the app.
Check apps and local targets →Explore Publish →Outgoing / Your build worker → external API
Confirm the source it sees.
A job calling an IP-restricted API needs an outgoing source its provider accepts. Public IPs can provide an assigned source under the selected routing mode; Outbound is an alternative when the requirement is an internet exit.
The provider must confirm the address it actually observes. An allowlist supplements API credentials; it does not replace them. An incoming webhook endpoint is a different requirement.
Plan outgoing API access →Check traffic direction →03 / Choose the routing scope
Account for the rest
of the host.
Start with Networks for private development. Add a public application path or outgoing identity only when the workflow needs it.
Compare the connection options →A public source needs a routing decision.
Public IPs and Outbound serve different address and internet-exit requirements. Verify the selected mode, the reply path and the source observed by each external provider.
Full tunnel reaches beyond one process.
Current Outbound profiles use full tunnel, with one active organisation-wide profile. This is not a per-process development proxy. Check the routes used by other jobs on the host before making the change, and keep a recovery path.
04 / Your first working result
A build completed on the right machine.
Choose a private build host and reach it from an approved laptop. Use your existing development tools; keep the repository and working data on the host.
Explore the development workflow →- 01
Open the real session
Connect from an approved laptop with your existing SSH credentials. Reach the intended host and private service, rather than stopping at a connected status.
- 02
Complete the build
Run a real build or development task with the repository and working data on the chosen machine. Check the tools and permissions your workflow actually needs.
- 03
Check the boundary
Confirm an unrelated user cannot reach the host. If you add a public preview, test its application login and verify that database and administration remain private.
05 / A practical first deployment
Host. Listener. Audience.
A way to tear it down.
Begin with one useful development loop. Record what is connected, who can use it and what must be removed when the work ends.
- 01
Choose the host and listener
List the operating system, listener address, port and intended users. An app bound only to localhost needs a connector on that host, or a deliberately reachable target. Localhost always refers to the connector’s own machine.
- 02
Test each intended audience
Check the private developer path, application login and denial for an unrelated user. For public access, verify only the intended listener is exposed. For outgoing API calls, confirm the source observed by the provider, including IPv4 and IPv6 where relevant.
- 03
Document the workflow and teardown
Keep configuration, diagnostics and a named teardown owner. Remove temporary previews and access when the work ends. Update external allowlists before releasing an address, and verify other jobs after a routing change.
Need the platform model or integration references?
Follow the platform path →Explore developer resources →06 / Questions, answered
Before you connect.
Can I use a CLI or API?
Development CLI tools and API contracts exist, but they do not amount to a finished public automation workflow. Networks CLI & API, Public IPs CLI & API and Outbound CLI & API separate implemented operations from planned work. Publish CLI describes a proposed workflow.
Can several apps use the same connected host?
Yes: each public hostname maps to a selected application target. Keep listeners, credentials and intended audiences separate. A connector’s localhost refers to its own host, so verify the selected target before sharing a link.
Does a tunnel secure the app itself?
It protects a transport path, not the application’s permissions or code. Keep HTTPS or SSH where appropriate, authenticate requests, validate webhook signatures and prevent development tools from exposing secrets.
Can I join a hosted CI runner?
Only if its runtime, privileges and lifetime support the required networking software. Ephemeral hosted runners may restrict tunnels or privileged changes. A supported self-hosted runner is a separate deployment to evaluate.