A GPU on our network is usually a machine in someone's flat. It sits behind a home router, on an address the ISP reassigns whenever it feels like it, with no ports forwarded and no expectation that any of that will change. The person who owns it agreed to share a graphics card, not to configure NAT traversal.
A renter clicks Rent and, about a minute and a half later, opens https://r-f453ac8e.paraloncloud.com and gets a Jupyter session. No VPN, no SSH tunnel, no client software.
This is how that works, and why it looks the way it does rather than the simpler ways it could have.
The rule that shapes everything
Nothing inbound. Not one connection is ever opened towards a provider's machine — not by us, not by the renter, not by anyone. The moment a design requires an inbound port, it is dead, because most of our providers cannot deliver one and the rest should not have to.
So every connection starts from inside the provider's network and reaches out. The container that runs a rental brings up cloudflared, which dials out to Cloudflare and holds the connection open. Traffic for the hostname arrives at Cloudflare's edge and travels back down that already-open pipe. From the router's point of view nothing unusual happened: a process made an outbound HTTPS connection, like a browser would.
One tunnel per rental, not per machine
The obvious design is a permanent tunnel per node. Register a machine, give it an address, keep it forever. It is simpler and we deliberately did not do it.
Cloudflare accounts have budgets — 1,000 tunnels, and 1,000 DNS routes shared with everything else the zone does. Per-node, those budgets scale with how many machines have ever joined. We have 201 registered nodes and the number climbs every week. Peak concurrent rentals is 11.
A per-node scheme would spend roughly 180 routes to serve 11 sessions. Per-rental spends 11. The budget then scales with how many people are renting right now, which is the quantity that actually matters and the one that grows slowly.
The second reason matters more. A permanent tunnel means a permanent credential sitting on a machine we do not own, granting a path into our zone, whether or not anyone is paying for that machine. A per-rental tunnel puts that credential there when the session starts and takes it away when it ends. The blast radius of a compromised provider box is one live rental, not a standing door.
Why the hostname is r-<id>.paraloncloud.com
The natural scheme is <id>.rent.paraloncloud.com — tidy, namespaced, obviously a rental.
It also does not work. Cloudflare's Universal SSL certificate covers the apex and first-level subdomains only. rent.paraloncloud.com is covered; f453ac8e.rent.paraloncloud.com is one level too deep. DNS would resolve, the connection would be attempted, and TLS would fail — unless the zone pays for Advanced Certificate Manager.
So hostnames are one label deep. r- prefixes them so they are still identifiable, and the tidiness is traded for a certificate that already exists.
This is the sort of constraint you only find by hitting it, and it is worth writing down: the namespace you want and the namespace your certificate covers are not the same namespace.
Nothing survives the session
A rental start does three things in order: create a named tunnel, create the DNS record pointing at it, then hand the tunnel token to the container as an environment variable. The container's entrypoint sees the token, runs cloudflared against it, and writes its access URL straight out — no waiting to discover what address it was given, because we chose the address before it started.
A rental stop reverses it. Delete the DNS record, delete the tunnel. Both are gone within seconds and the hostname stops resolving.
Except when the tunnel refuses to die. Cloudflare answers a delete with error 1022 while cloudflared still has live connections — which is exactly the state a tunnel is in the instant you stop the container, because the process has not noticed yet. This is not a failure; it is a race, and it resolves itself in a minute or two.
So teardown does not treat 1022 as an error. It is left for the reaper, which sweeps for orphaned ingress and retries. Watching it in production, the DNS record disappears immediately and the tunnel is reclaimed on the next sweep.
Everything here is best-effort on purpose
Ingress is a convenience. A rental is a GPU, and losing the pretty hostname must never cost someone the machine they are paying for.
So provisioning failure is not fatal. If Cloudflare is unreachable or the account is out of budget, the rental starts anyway and the container falls back to its own quick tunnel — a random trycloudflare.com address, which is what every rental used before this existed. Worse, still working.
Teardown failure is not fatal either, for the same reason in reverse: a stop that cannot reach Cloudflare still stops the container and still stops the billing. The stranded tunnel is somebody's problem later, and that somebody is the sweep.
The rule is worth stating plainly, because it is easy to violate by accident: the code that makes a thing nicer must not be able to break the thing.
What the renter sees
A stable HTTPS address on our domain, valid certificate, live the moment the container is, gone when they stop it. No port forwarding on the provider's side, no client on theirs, no inbound connection anywhere in the path.
What the provider sees is a process that made an outbound connection and closed it when the session ended.
That asymmetry — a public address for a machine that cannot accept one — is most of what makes renting someone's spare GPU feel like renting a server.
