A tunnel is how Tines 3B reaches systems inside your private network, the databases, internal APIs, and services that live behind your firewall and were never meant to be exposed to the internet. It's a specific kind of network, built around a piece you run in your own environment.

Most of what a workflow talks to is on the public internet, and needs no special setup. But plenty of important systems aren't reachable that way on purpose. A tunnel is the answer for those: it gives your workflows a path to internal destinations without you having to open them up to the world. From a step's point of view, it just makes a normal request; the tunnel is what quietly carries that request the last mile into your network.

The heart of a tunnel is an exit node: a small container you run on a host inside your private network. Rather than Tines 3B connecting inward to you, the exit node connects outward to Tines 3B's tunnel gateway and holds that connection open.

Traffic bound for your internal destinations flows out through the gateway, down the connection the exit node opened, and finally out from the exit node itself, which sits inside your network and can reach the private systems.

This outbound-only design is the whole point. Because the exit node dials out, you don't have to open any inbound holes in your firewall. Nothing on the internet can reach into your network; your network simply reaches out to Tines 3B. That's what makes a tunnel safe to run against sensitive internal systems.

A tunnel is mutually authenticated, so both sides prove who they are. When you create a tunnel, Tines 3B mints a client certificate for it and remembers that certificate's fingerprint. The exit node presents that certificate when it dials in, and the gateway only accepts the connection if it matches.

Tines 3B hands you a one-time token that packages the certificate for the exit node, shown just once, so it's yours to keep somewhere safe. The upshot is that only your exit node, holding your credential, can carry your tunnel's traffic.

A tunnel carries traffic only to the destinations you define for it, written as IP ranges or hostname patterns for the private systems it should reach. Those destinations are what tell Tines 3B which requests belong on the tunnel: a step making a request to a matching address is routed through it automatically, and everything else takes its normal path. So a tunnel is scoped to exactly the internal systems you intend, not a blanket door into your network.

Because a tunnel is a kind of network, everything true of networks applies to it. Routing is ambient, so steps don't reference the tunnel directly; matching a destination is what puts traffic on it.

Access is governed the same way, so a space can route through a tunnel only when its members are allowed to use it, and if they aren't, the traffic is blocked rather than sent out some other way. A tunnel inherits the whole network model and adds the private-network bridge on top.

Setting up a tunnel comes down to running its exit node. After the tunnel is created and its certificate is minted, Tines 3B gives you the command to run the exit-node container on a host inside your private network, using the token you saved. Once it's running, its logs confirm the connection to the gateway succeeded, and from then on your workflows can reach the destinations you configured.