Local-first is great until something outside the machine needs to talk to it.
A webhook needs a public URL. A messaging provider needs a callback. An external service needs to reach the running workspace without the user rebuilding networking every time.
Tunnel solves that gap.
It gives Fractal a stable public entry point while keeping the setup inside the product instead of pushing the complexity onto the user.
Why this matters
This feature is not about infrastructure for its own sake.
It is about making real workflows possible.
If Fractal can receive external events, then the workspace can do more than respond to local clicks. It can participate in live business systems:
- a routine can be triggered from a webhook;
- a support flow can receive external callbacks;
- a messaging integration can reach the app;
- a remote service can notify the workspace when something changes.
That is what turns local software into something operationally connected.
What tunnel does for the user
Tunnel keeps the user from becoming the networking layer.
The user should not need to memorize setup steps every time they want the app to be reachable. They should be able to configure the public endpoint once and trust the product to manage the rest.
That means Fractal can stay focused on the workflow:
- start the tunnel when the workspace needs to be reachable;
- stop it when the user wants to close it down;
- show the current status clearly;
- preserve the public URL;
- keep the configuration aligned with the actual running process.
The control stays inside Fractal, which is exactly where it belongs.
Where this becomes valuable
Tunnel is especially useful when Fractal is part of a broader business flow.
For example:
- a founder wants a public endpoint for an agent workflow without deploying extra infrastructure;
- a marketing team wants a webhook to trigger content review or publishing;
- an agency wants a client-facing workflow to hit the workspace directly;
- a support flow wants to receive events from a messaging or ticketing system;
- a product team wants local execution to still participate in external automation.
The feature is small on purpose.
Its impact is big because it removes the barrier between the local workspace and the outside world.
Why it belongs in the product
If Fractal wants to be a real operating environment, it needs controlled reachability.
Tunnel is part of that story. It makes the workspace available to the world when needed, without turning the user into the person responsible for ports, proxies, or temporary hacks.
That is the right abstraction.
Not "learn networking." Not "spin up a separate service." Just "make the workspace reachable."
The bigger picture
Tunnel is one of those features that feels invisible when it works and painful when it does not.
That is exactly why it matters.
It gives Fractal the ability to participate in workflows that do not start and end inside the app. And once the workspace can be reached from the outside, a lot more becomes possible:
- external triggers can activate routines;
- agents can respond to external systems;
- integrations can connect without extra glue;
- Fractal can behave like a living service instead of a closed desktop shell.
That is the real value of tunnel.
It makes continuity possible beyond the app boundary.