Sign-in helpTalk to Fibmesh
Menu

Developers

Your stack. Wherever you build.

Reach remote build hosts and private tools. Choose a separate path for public applications and connections to external APIs.

Plan a development workflowExplore Networks →

Connection paths

From your laptop to the machine that does the work.

Follow the connectionIllustrative connection paths

Reach the machine that does the heavy work.

  1. Developer laptopHome, office or mobile internetWireGuard
  2. Fibmesh routing nodeApproved private connectionWireGuard
  3. 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.

  1. Reviewer or webhook senderPublic HTTPS requestHTTPS
  2. Publish gatewaySelect the app by hostnameWireGuard
  3. Connected hostWireGuard tunnelLocal app
  4. 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.

  1. Build workerStarts an API requestWireGuard
  2. Fibmesh delivery / exitConfigured public sourceHTTPS
  3. 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 →

Put it to work

A development environment can live beyond your laptop.

The build machine may be at home, the database in a cloud account and the reviewer in another city. Each needs a different connection. Give developers private access to their tools, choose the application a reviewer can open, and decide which source address an external API should see.

Work on remote compute

Reach an SSH host, development workstation or supported lab server over Networks. Keep code and datasets on that host, using the development tools and credentials you already trust.

Remote development →

Share a running application

Publish gives separate web apps separate public links, including apps on different localhost ports. Use a review app for the client; keep its database and administration private.

Apps and local targets →

Connect to external APIs

Incoming webhooks need a reachable HTTP endpoint. Jobs calling an IP-restricted API need a known outgoing source. Public IPs and Outbound address the latter in different ways.

Understand traffic direction →

An Outbound profile currently uses full tunnel; it is not a per-process development proxy. Use application login for reviewers, and verify the route used by other jobs on the same host. Compare the connection options →

Illustrative workspace for remote development
Illustrative photography · not a photograph of the described customer or deployment.

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.

  • Connect with your existing SSH credentials
  • Run a real build or development task
  • Check that an unrelated user cannot reach the host
Explore the development workflow →

A practical first deployment

Start with one useful development loop.

  1. Choose the host and service

    List the operating system, listener address, port and intended users. An application bound only to localhost needs a connector on that host or an intentionally reachable target.

  2. Connect and test the audience

    Check the private developer path, application login and denial for an unrelated user. For public access, verify only the intended listener is exposed.

  3. Make the workflow repeatable

    Record configuration, diagnostics and teardown. Update external allowlists before releasing an address, and remove temporary previews when the work ends.

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.

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, 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.

Bring one host, one service and the person who needs it. That is enough to design a useful first connection.

Plan your first deployment →