About
Self-hosting shouldn't require a second job.
We build Edgible because services and data belong on hardware their owners control. What stops most people is not running the software. It is everything between the software and the public internet.
Getting a service you run at home or in your office safely onto the public internet has traditionally meant a static IP or dynamic DNS, router port forwarding, a reverse proxy, certificate renewal, and a permanent low-grade worry about what you have exposed. None of that is the thing you set out to build, and each step is a reason people give up and rent someone else's server instead.
Edgible does that work instead. A gateway we operate takes the public traffic. An encrypted WireGuard tunnel, established outbound by your device, carries it to your machine, where TLS terminates and your service answers. Deployments are declarative YAML, certificates are managed, and your hardware never accepts an inbound connection.
You keep the hardware, the data, and the workload. We run the public edge and the control plane that puts it on the internet.
01 — Workloads run on your hardware
Workloads run on machines you own. The gateway relays encrypted traffic; it doesn't host your application or read your TLS sessions.
02 — The architecture does the securing
No inbound ports, WireGuard on every tunnel, TLS terminating on your device. There is no less-safe configuration available to switch to.
03 — Say what it does
Our docs and this site describe the platform as it is — including its current constraints. If we haven't built it, we don't market it.