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.

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.

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 IPs change 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.

A protocol becomes useful when there is a working implementation. Uplink is the open-source reference implementation of OpenTunnels, including the connector and the compatible public edge. You can run the whole system yourself, or use the managed edge without changing the protocol underneath it.

Uplink also takes responsibility for the parts around the tunnel that determine whether a service is safe to publish: public HTTPS, stable and custom domains, access policy, firewall rules, rate limits, and managed bot challenges. The goal is a coherent ingress boundary, not only a way to move bytes through NAT.

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.

Our concern is not that these services are commercial. It is that a tunnel occupies an unusually important position: it sits inside the security boundary, becomes an availability dependency, and often controls the public name and identity of the service behind it. When the client, protocol, compatible edge, and account system all belong to one company, leaving that company means replacing the system rather than moving it. Publishing a client is useful, but it does not make the infrastructure inspectable or give its users somewhere else to go.

There is also a serious open-source lineage. frp and rathole are examples of capable self-hosted reverse proxies for carrying traffic across NAT.

The remaining problem is that freedom to run the software is not the same as ease of use. Operating a complete public edge can still mean designing the network topology and assembling DNS, certificates, a reverse proxy, identity, firewall rules, and monitoring yourself. That may be perfectly reasonable when networking is already your job. It is a high price for a developer who only wants to publish the service already running on a nearby machine.

The ambition for Uplink is to be to reverse tunnels what Docker Compose is to containers: not a claim to have invented the underlying machinery, but a coherent, declarative way to assemble it into something an application developer can operate. Describe the local service, its public address, who may reach it, and what should be blocked at the edge in one place. OpenTunnels supplies the authenticated transport and trust boundary underneath; Uplink adds HTTPS termination, access controls, and firewall policy against identity, source network, method, path, and headers before a request reaches the private machine.

That is the case for another entrant. The managed options should not be the only options, and the open-source options should not require their users to become network operators. We want the transport to be auditable and replaceable, and the system around it to be complete enough that self-hosting does not mean assembling five separate products.

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 viable 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 needing to build a hand-rolled cloud ingress stack.

The contrarian thesis behind OpenTunnels is that, in an era of unprecidented datacenter investment and construction, it is all the more important to have ways to leverage local computation without relying on these centralized hubs of cloud resources.

If we can push some agency back outward, toward hardware owned by the people and organizations doing the work, that might be a good thing.

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.

Try it

Uplink is the easiest way to try OpenTunnels today. Run the reference implementation yourself and keep the entire path under your control, or use the managed edge without operating one. Other compatible implementations would be a sign that the protocol is doing its job.

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