When to use Edgible
Edgible is opinionated about what it solves. This page describes the cases it fits and the case it does not.
A good fit
Section titled “A good fit”Self-hosting a small SaaS
Section titled “Self-hosting a small SaaS”You’ve built a product. The hardware sits under your desk or in a colocation rack, not in a public cloud. You want app.your-product.com to resolve to it, you want HTTPS without renewing certificates by hand, and you want a clean way to deploy updates. You don’t want to install Kubernetes, configure cert-manager, set up an ingress controller, or open ports on a router that is also responsible for your home Wi-Fi.
Edgible handles the public edge so you can keep the rest simple. docker compose up is still a perfectly good way to run your code; Edgible makes that container reachable.
Internal tools on private infrastructure
Section titled “Internal tools on private infrastructure”Your team has a couple of internal services — a status dashboard, a build artifact server, a Grafana — that need to be reachable by remote staff but should not be on the public internet. The classic solution is a VPN; the cost is that every employee has to install and troubleshoot a VPN client.
With Edgible, the same services can be exposed at private hostnames protected by organization-mode authentication — only members of your Edgible organization can reach them, no separate VPN required. The auth check happens at the serving device’s Caddy layer before any request hits the workload.
Edge and ML workloads
Section titled “Edge and ML workloads”You have specialized hardware — a GPU box, a camera, a sensor hub — running somewhere with consumer-grade internet (a home, a workshop, a remote site). You want to expose an inference endpoint or a control API. The serving location may not have a static IP, may sit behind CGNAT, may move between networks.
Edgible’s tunnel model treats the serving device’s location as ephemeral. The public hostname does not change when the device moves to a different network.
A poor fit
Section titled “A poor fit”High-traffic public web at scale
Section titled “High-traffic public web at scale”If your service handles millions of requests per second, Edgible’s single-tunnel-per-device model is the wrong shape: there is no horizontal scaling across edge nodes and no CDN caching layer. The platform optimizes for correctness, security, and operational simplicity at small-to-medium scale on hardware you own.
If you already have an Application Load Balancer, a Kubernetes ingress, and a global CDN, Edgible adds nothing for you.
In short
Section titled “In short”Edgible is a managed control plane and public edge for services you want to keep running on your own hardware. It fits when “my own hardware” is a requirement and operating the public-facing infrastructure yourself is the part you would rather not do.