Networking & Tunnels

Your apps just work

LinqProtocol combines Cloudflare tunnels, deployment-scoped routes, custom domains, and Kubernetes service discovery. Providers do not need to open inbound ports.

Deploy Now
The Challenge

Networking is the hardest part of self-hosting

Ask any developer who's tried to self-host: getting traffic to your app is painful.

  • Port forwarding through routers and firewalls
  • Dynamic IPs that change without warning
  • TLS certificates that expire at 3am
  • Load balancing across multiple instances

LinqProtocol solves all of this with a networking stack that handles complexity behind the scenes.

The Stack

Public routes without provider-side port forwarding

Cloudflare Tunnels

Provider clusters make outbound tunnel connections so applications can be reached without opening inbound ports on the provider network.

  • No port forwarding required
  • Works behind firewalls and NAT
  • Supports providers with dynamic public IPs
  • Routes public traffic through Cloudflare

Platform Routes

Create a LinqProtocol hostname for a specific HTTP, TCP, or UDP port, then update or remove it from the deployment networking page.

  • Hostname and port mapping
  • HTTP, TCP, and UDP route support
  • Routes stay attached to the deployment
  • Explicit create, update, and delete controls

Custom Domains

Attach a domain you control to an existing platform route, verify DNS or ownership, and activate it from the dashboard.

  • Subdomain and apex-domain workflows
  • DNS guidance during setup
  • Verification before activation
  • Route stays visible alongside its platform hostname

Kubernetes Service Networking

Services inside a deployment use Kubernetes DNS and namespace-scoped names to communicate without exposing every port publicly.

  • Service discovery by name
  • Internal DNS resolution
  • Public exposure only when a route is created
  • Deployment resources grouped in their own namespace
Tunnels

Reachable from anywhere

1
User makes request to your-app.linqprotocol.com
2
Request hits the edge network
3
Traffic routes through a Cloudflare Tunnel to the provider
4
Istio Gateway routes to the correct container
5
Response returns through the same path

Network tunnels eliminate the traditional networking challenges of decentralized infrastructure:

Provider can be anywhere

Home server, data center, edge location - doesn't matter

No static IP required

Works with dynamic IPs

No firewall changes

Only outbound connections needed

Managed reconnection

Tunnel clients reconnect when connectivity returns

Endpoints

Every deployment gets endpoints

When you deploy on LinqProtocol, you automatically receive:

Application Endpoint

Public URL for your main application (e.g., your-app.linqprotocol.com)

API Endpoint

If your deployment exposes an API (configurable port mapping)

Console Endpoint

For Aura Code sandboxes, access to your development environment

Endpoints are provisioned within minutes of deployment and remain stable for the lifetime of your deployment.

Custom domains are supported

Attach a subdomain or apex domain to an existing platform route, follow the DNS records shown in the dashboard, then verify and activate it.

Internal

Service-to-service communication

For deployments with multiple services, Kubernetes provides internal naming and service discovery:

Service Discovery - Containers can find each other by name
Internal DNS - Resolve service names within your namespace
Namespace Scope - Deployment resources are grouped together
Explicit Exposure - Only create public routes for ports users need

This lets a frontend, backend, and database communicate through internal service names while public access remains an explicit route configuration.

Security

Defense in depth

Cloudflare Edge

  • Public traffic enters through Cloudflare
  • Provider clusters use outbound tunnels
  • No provider-side inbound port forwarding

Route Boundary

  • Each route names a protocol and port
  • Hostnames map to a specific deployment
  • Custom domains require verification before activation

Deployment Boundary

  • Workloads are grouped in a deployment namespace
  • Internal services use Kubernetes discovery
  • Public routes are separate from internal service names

User Control

  • Create and remove platform routes
  • Verify and activate custom domains
  • Review every exposed hostname and port in one place

Networking handled. Start building.