The internet is still described as a decentralized network, and at the level of its protocols that remains true. In ordinary use, though, the description is becoming harder to take seriously.

Most of the computers around us have no durable identity on the public internet. They sit behind NATs and firewalls, initiate connections to a small number of very large services, and spend nearly all of their networked lives as clients. Owning a computer gives you a good way to reach other people’s computers; it no longer gives you much of a place on the network itself.

This is the starting point for OpenTunnels. We think a computer you own should be able to publish something useful without first moving that thing into somebody else’s datacenter.

From network participant to platform tenant

The early internet is easy to mythologize. ARPANET was not built by hobbyists in spare bedrooms, the hardware was wildly expensive, and access was limited to a narrow set of institutions. None of that is a model we need to recover.

The architecture did contain an idea worth keeping. The network moved packets, while the machines at its edges decided what those packets meant. A host could offer a new service without asking the network operator to understand that service first. “Client” and “server” described what programs were doing in a particular exchange; they were not permanent classes of machine.

In practical terms, a computer with an address could listen on a port, and another computer could connect to it. That arrangement was not automatically secure or easy to operate, but it gave the edges of the network real agency. The permission to invent did not live exclusively in the middle.

The protocols still allow this, but the internet connection sold to most people is now asymmetrical: excellent for fetching things and awkward for serving them. Scarce IPv4 addresses led to NAT, inbound traffic became a security liability, residential addresses changed without warning, and the modern web added certificates and DNS to the list of things that had to be maintained. Running a public service from a private network became possible in theory and irritating in almost every detail.

How the cloud became the internet

Datacenters solved real problems. They have reliable power, good connectivity, stable addresses, and people who know how to keep machines running. Cloud platforms made that infrastructure available through an API, which was a vast improvement over buying a server and driving it to a colocation facility; we use them ourselves for many of the same reasons everyone else does.

What began as a useful option gradually became the assumed shape of the internet. If a program needs a public address, the conventional answer is to package it for a remote runtime, reproduce the data and environment it depends on, and treat the nearby machine where it already works as a staging area. “Put this on the internet” and “move this to the cloud” have become nearly interchangeable instructions.

Relocating a service is often the sensible choice, but making relocation a condition of being public has consequences. It concentrates applications, data, identity, and operational knowledge inside a handful of administrative domains, then makes continued access to your own software depend on an account, a billing relationship, and the provider’s willingness to keep offering the same abstraction. The internet remains decentralized on a protocol diagram while becoming remarkably concentrated in operation.

This arrangement also undersells the computers people already own. A small machine in a home or office can have a fast processor, several terabytes of storage, and a GPU capable of running serious models. The hardware is not a toy, yet the network treats it as a terminal. It can consume almost anything on the internet but needs an elaborate workaround to contribute something back.

Decentralization without the costume

“Decentralization” has accumulated enough ideological and marketing baggage that it can sound like a proposal for a new currency or a demand that every dependency be replaced with a federation. We mean something more ordinary: for any part of a system, ask whether it actually has to live in a shared center, and if it does not, leave it with the person or organization operating it.

A publicly reachable service does need some shared coordination. Its name must resolve, its certificate must be presented from a reachable address, and traffic from arbitrary networks needs somewhere to arrive. None of those requirements imply that the application, its runtime, and its data must live in the same place. We can centralize the minimum public boundary without centralizing the whole system behind it.

This is a less theatrical form of decentralization, but we think it is a useful one. It reduces how much infrastructure must be rented or trusted, keeps the important state under the operator’s control, and makes the shared part replaceable.

OpenTunnels

OpenTunnels is the protocol we built around that boundary. It starts from modern, standardized building blocks: QUIC for multiplexed streams, TLS 1.3 for transport security, and RFC 9266 channel binding to tie device identity to the session. A connector on the private machine establishes the connection outbound, before it registers any service. When public traffic reaches the edge, each request gets its own QUIC stream back to the connector, which forwards it to an ordinary local HTTP service. Streaming responses and WebSockets travel over the same connection.

OpenTunnels is a relay rather than a hole-punching scheme, so the edge remains in the request path. It terminates the public certificate, applies policy, and maps the hostname to an authenticated tunnel. The connector needs no inbound port, and the application does not have to know that a tunnel exists; from its perspective, it is still listening on localhost:3000.

The implementation is open source, and the wire format and security model are described in the protocol paper.

Why another tunnel?

Reverse tunnels are not new. Cloudflare Tunnel, Tailscale Funnel, and ngrok can all take a service on a private network and give it a public address without opening an inbound port. They are useful products, and their existence is good evidence that this problem is real.

We think the community should have more than a choice between managed services. A tunnel sits inside the security boundary, becomes an availability dependency, and controls the public identity of the service behind it. If the protocol and compatible edge belong to one company, changing providers means replacing the system rather than moving it. Publishing the local client is valuable, but it does not by itself create shared infrastructure that other people can audit, operate, and extend.

OpenTunnels is our contribution to that commons: an auditable, self-hostable path built on modern standard protocols. We do not expect one more tunnel project to decentralize the internet by itself. We do think the network becomes healthier whenever another critical layer is made inspectable, forkable, and operable by someone other than its original author.

The internet should feel closer to home

Here, “home” describes an administrative relationship rather than a house: the machine, data, and decisions belong to the person or team using them. It might be a laptop, a homelab, a small office, or a rack of hardware owned by a larger organization.

Personal computing put extraordinary capability into people’s hands, but the web gradually trained that capability to wait for instructions from remote services. The tension is especially obvious now that local machines can run substantial AI workloads against private data: the computation and the data may both be sitting beside you, while the standard advice for sharing the resulting application is still to upload some version of it elsewhere.

We want local hardware to be a normal deployment target again. A developer should be able to share the process running on a laptop. A private model should be able to stay next to the GPU and data it uses. A homelab service should be reachable without exposing the rest of the network, and a small team should be able to operate hardware it owns without first building a second-rate cloud ingress stack.

The contrarian bet behind OpenTunnels is that the next version of the internet does not have to pull even more computation into a few enormous centers. It can push some agency back outward, toward hardware owned by the people and organizations doing the work. Datacenters will remain useful, but they should be one kind of participant in the network rather than the place the network is assumed to live.

Taking it back, in this sense, means restoring that option and refusing to let shared infrastructure swallow every layer above the public boundary.

A computer you own should be able to serve something useful without first becoming a development terminal for a rented machine. If we can make that ordinary again—safe enough to trust, easy enough to use, and open enough to leave—the internet will be meaningfully more decentralized than it is today.

OpenTunnels is early. If this is the direction you want the internet to move, we hope you will try it, inspect it, and help us find the rough edges.

Introducing Uplink

A protocol becomes useful when there is a working implementation. Uplink is the open-source reference implementation of OpenTunnels, including the software needed to connect a private machine to a compatible public edge. You can run it yourself and keep the entire path under your control.

Uplink is also available as a managed service for people who want the benefits of OpenTunnels without operating an edge. We want the relationship to remain clear: OpenTunnels is the protocol, while Uplink is one implementation and one way to operate it. Other compatible implementations would be a sign that the protocol is doing its job. 

$ curl -fsSL https://uplink.computer/install.sh | sh