Self-hosting is great. You keep control of the machine, the data, and the software. Then, eventually, you want to make one of those services available outside your LAN or Tailscale network.
The traditional route is familiar: ask the ISP for a usable public address, configure port forwarding, set up dynamic DNS, and maintain the router rules. This ranges from straightforward to impossible, especially behind CGNAT.
Even when it works, there is another cost: every visitor connects to your residential IP. Someone reading your blog does not need a network-level clue about where you live. In the other direction, a site you visit can see the same address and potentially correlate it with services hosted from your connection.
The easy answer
Cloudflare Tunnel solves most of the operational pain. Your server opens an outbound connection to Cloudflare, so there is no inbound port forwarding, no DDNS client, and often no ISP conversation. Visitors get HTTPS, and Cloudflare adds a large edge network, DDoS mitigation, and a convenient control plane. The basic service is free.
That is a compelling package. So what is the tradeoff?
For an ordinary HTTP Tunnel, Cloudflare becomes the TLS endpoint.
The visitor establishes HTTPS with Cloudflare. Cloudflare decrypts the request, applies its HTTP features, and forwards the request to cloudflared through another encrypted connection. The browser-to-edge leg is encrypted, and the edge-to-origin leg is encrypted, but this is not one end-to-end TLS session between the visitor and your server.
Cloudflare can therefore see both sides of the connection: the visitor's source IP, your server's outbound IP, and the HTTP plaintext, including URLs, headers, cookies, and request or response bodies.
Cloudflare is not secretly breaking TLS here. Edge termination is how products such as caching, WAF rules, bot filtering, access policy, and application-layer DDoS protection work. They need to inspect HTTP. The issue is that many self-hosters hear "the tunnel is encrypted" and assume the intermediary cannot read their application traffic.
Encryption is not only about whether keys exist. It is about who holds them.
The usual privacy-preserving alternative
You can rent a VPS, point DNS at it, and create your own reverse tunnel home. Projects such as Pangolin can help operate this model.
The important detail is where TLS terminates. If the VPS reverse proxy owns the certificate, plaintext is available on the VPS. If the VPS only forwards the TLS stream using SNI or a dedicated port, the certificate and plaintext can remain at home. The VPS still sees connection metadata, and you still pay for and maintain the whole machine.
That is a good setup for many people, but it is more infrastructure than one blog or personal service should need.
A smaller trust boundary
Blindport packages that SNI-forwarding model as a service for self-hosters.
The blindportd agent opens an authenticated outbound tunnel from your Linux host. With Blindport Relay, the edge reads the visible TLS Server Name Indication only to decide which customer tunnel should receive the connection. It does not terminate the visitor's TLS session. The certificate private key and TLS plaintext stay on your machine.
For the simple case, blindportd automatically obtains and renews a Let's Encrypt certificate, terminates TLS locally, and forwards plaintext to an app on 127.0.0.1:8080 or another local target. If you already run Caddy, Traefik, or another TLS server, passthrough mode lets it keep owning the certificate.
Could Cloudflare route by SNI too? Technically, yes. But an opaque TLS stream prevents most HTTP-level edge features. Blindport deliberately chooses the smaller feature set and the smaller trust boundary.
Blindport still sees metadata needed to forward the connection: SNI, active network addresses, timing, and traffic volume. It is not an anonymity network. The point is not that the relay learns nothing. The point is that it does not receive the HTTP plaintext or your certificate keys.
What you can lease
Shared ingress capacity makes this cheaper than renting and maintaining a whole VPS for one or two services. Blindport currently offers three types of public endpoint:
- Relay: an exact hostname from 3,000 sats per 30 days, or a customer-owned wildcard base, on shared port 443. An included Blindport-managed hostname avoids DNS setup.
- Port: one public TCP or UDP socket mapped to a local service, from 1,500 sats per 30 days.
- IP: one routed dedicated public IPv4
/32delivered over WireGuard for workloads that need arbitrary ports, native UDP or ICMP, or outbound use of the same address.
Relay and Port connect through ingress at two providers to improve resilience for new connections. This is a best-effort beta, so it is not currently sold with an uptime or high-availability guarantee. A routed dedicated IP belongs to one provider.
There is no email, name, or identity profile required. Your account is a bearer token that you must back up. Payments use Bitcoin over Lightning. Nostr Wallet Connect can handle payment and automatic renewal without handing Blindport wallet custody. The agent can also use a Tor SOCKS5 proxy when you do not want Blindport to see your normal origin IP.
The client, relay, and control plane are MIT licensed. You can inspect the implementation or self-host the complete stack.
Website: https://blindport.com
Source: https://github.com/blindport/blindport
We would especially value feedback on the threat model, onboarding flow, and which self-hosted services people want to publish first.
TL;DR: Blindport gives a self-hosted web service a durable public HTTPS address without exposing your home IP, letting the gateway decrypt your traffic, or maintaining a VPS.
Relay costs 3,000 sats for 30 days and includes a Blindport subdomain. Choose a name, pay over Lightning, and run the generated agent command beside your service. No port forwarding, DDNS, or ISP negotiation.
Already use Caddy or another reverse proxy? Blindport does not replace it. Your certificates, routes, authentication, and other directives stay on your machine. If you do not use one, the agent can handle HTTPS for you.
It is an MIT-licensed, best-effort beta, not an anonymity network or an uptime guarantee.
https://blindport.com
Price update: we lowered the hosted catalog by one third for new subscriptions.
The main use case is unchanged: give a home-hosted service a public HTTPS address through CGNAT, keep the certificate keys and HTTP plaintext on your machine, and avoid maintaining a VPS.
Current catalog: https://blindport.com/#order
This is probably a dumb question, but does Blindport give one the ability to host a public node from their home in a more private manner?
It could help, yes.
For the best privacy, you could have Tor only outgoing and incoming connections in you Bitcoin node.
Since it's easier to do an isolation attack to Tor only nodes (see https://arxiv.org/pdf/1410.6079), you might want to have also some "clearnet" connections as well.
For outgoing connections with privacy, you could use a VPN.
For incoming connections, you could use Blindport Port service to have a pair of public IPs and a port do advertise for incoming connections that would get routed to your node. Without the world knowing your residential IP.
Another option is to use Blindport IP where you would have a public IP just for you that you can use for incoming and outgoing traffic.
The next time I spin up a new server for a specific use case that I thought I'd want to expose to someone beyond myself, say friends/family, or maybe beyond that, my plan was to try StartTunnel.
My takeaway is that StartTunnel is probably more expensive (ultimately the cost of the VPS, ~$5–10/mo), and there may be more upkeep, even if StartTunnel makes that pretty easy. Blindport looks like a potentially simpler, cheaper path if it’s just one service. The trade-off appears to be trusting the Blindport relay instead of the VPS provider you would pick to run StartTunnel?
I’m wondering how this scales if you want to expose multiple services from the same home server, each with its own domain so that the people you share with don’t see the other services or know they’re coming from the same place.
A table of my current understanding of the comparison (correct me if I'm wrong):
If anyone else stumbles across this post weighing these two use cases, what’s your read on the tradeoffs? Does Blindport’s “customer-owned wildcard base” option change the math for multiple services, or would you still be paying per hostname? And for StartTunnel, is running your own reverse proxy on the Pi the preferred way to keep services isolated behind separate domains?
StartTunnel is a very good comparison. You can think of Blindport as a hosted StartTunnel.
For multiple services, you can get a wildcard for 2.5x the price of a single domain/subdomain. So for subdomains of the same base it becomes a flat fee. Or you can get a full IP and have a managed "StartTunnel" for slightly less than the cost of a VPS.
To separate public domains, Blindport is actually cheaper than the VPS. All users of Blindport become some kind of anonymity set. On your VPS, anyone doing a reverse DNS query would easily link together the different domains pointing at it. So for equivalent anonymity you would need a new VPS each time. In Blindport you could get a separate account or just add a different subscriptions and external observers wouldn't be able to tell if two services routed through Blindport actually belong to the same entity.
The trust boundary is the same for Blindport and StartTunnel. At the end of the day, the traffic passes encrypted through a VPS in both cases (SNI, timining, volume, ...).
Since the trust is similar, it boils down to price. Blindport is cheaper and has ingress redundancy. You can expect higher uptime, faster setup, and no maintenance effort from your side. A VPS on the other hand gives you more flexibility and "recycling" opportunities, since you could use it for other stuff since you already have it.
Thanks for the thorough response. Bookmarking for use in the not so distant future the next time I need to make a service publicly available.
I think the main comparison for me is actually a tiny no-KYC VPS.
You could probably do this cheaper with a very small VPS acting as a gateway, especially if all you need is SNI passthrough or a reverse tunnel back home.
But then you own the whole stack: initial setup, WireGuard/tunnel config, reverse proxying, firewall rules, updates, monitoring, and eventually fixing it when something breaks.
So Blindport makes sense to me less as “cheaper than a VPS” and more as “pay a small premium to avoid running another server while keeping the TLS endpoint at home.”
That trade-off is actually pretty interesting.
I’d still personally want to compare the monthly cost against a minimal no-KYC VPS, but operationally this is definitely cleaner.
Exactly. With some additional advantages as described at #1558838
Nice product for a specific use case. An anonymous VPS+WG is not much more expensive, but can do extra stuff, like routing to FIPS, be a TOR exit node or working as a VPN for family and friends.
Well, it's also about the simplicity of not having to maintain it, and uptime; by having ingresses in different VPS providers. VPS instances from a privacy friendly providers usually don't have great uptime.
With enough users we should be able to lower prices even more.
could you elaborate please? you use more than one provider?
Say you want to publish yourwebsite.com from your house. You would point yourwebsite.com to ingress.blindport.com with a DNS CNAME or ALIAS record.
ingress.blindport.com points to provider A and provider B VPS IPs instead of just one.
From your house, the
blindportddaemon opens tunnels to each of those servers. So if someone tries to access yourwebsite.com and provider A is down, your website still loads through the provider B.The fair comparison would be getting *two* VPS instances from different providers and configuring WireGuard and DNS to have the fallback behavior. Which is what Blindport does, and you can self host. Another catch is that VPS with unmetered traffic are more expensive.
Who are the providers currently?
https://mynymbox.io/ and https://servers.guru/
Both on different ASNs. You can verify this with:
dig ingress.blindport.com +short:78.17.212.128
89.125.35.70
https://ipinfo.io/78.17.212.128
https://ipinfo.io/89.125.35.70
We can easily add more or switch providers as needed.
eyes glazed over before I got too far, post and website needs distilled down to the essence.
There's 2 types of potential users for this
For 2, why would I look deeper into this rather than just run caddy locally for letsencrypt ssl termination and use ssh -R or wireguard for the reverse tunnel? Is it cheaper than a VPS or VPN? Does it replace Caddy? What about all my Caddy directives? Do I port those or is this another middleware infront of an existing reverse proxy?