When to use Edgible
Edgible is opinionated about what it solves. Knowing when it’s the right tool — and when it isn’t — saves time.
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 just 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 stays put; the device can roam.
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 and CloudFront-class horizontal scaling at the edge are not the right shape. The platform optimizes for correctness, security, and operational simplicity at small-to-medium scale on hardware you own — not for absorbing a Reddit hug-of-death on a globally distributed CDN.
If you already have an Application Load Balancer, a Kubernetes ingress, and a global CDN, Edgible adds nothing for you. It exists for the case where you don’t have those, and don’t want to.
Mental model
Section titled “Mental model”A useful way to position Edgible:
A managed control plane and public edge for services that you, specifically, want to keep running on your own hardware.
If “your own hardware” is a hard requirement and “I have to operate the public-facing infrastructure myself” is the part you’d rather skip, Edgible is the platform.