FAQ
Do my serving devices need a public IP?
Section titled “Do my serving devices need a public IP?”No. Serving devices initiate outbound connections only — to the Edgible control plane (TCP/443) and to a gateway over WireGuard. They never accept inbound connections from the public internet. A device behind a home router, a corporate NAT, or a CGNAT works fine.
Do I need to open ports on my firewall?
Section titled “Do I need to open ports on my firewall?”Outbound TCP/443 to the Edgible control plane and outbound UDP to the gateway’s WireGuard endpoint. No inbound ports.
Does Edgible see the traffic flowing to my workloads?
Section titled “Does Edgible see the traffic flowing to my workloads?”The managed gateway terminates the public TCP connection and forwards the encrypted bytes to your serving device’s Caddy. For https access, TLS terminates on your serving device — the gateway sees the SNI hostname (it has to, to route) and the encrypted byte stream, but not the plaintext payloads. Your serving device, running your hardware, sees the decrypted requests.
Can I run Edgible entirely on my own infrastructure?
Section titled “Can I run Edgible entirely on my own infrastructure?”Today, the control plane (the API, the auth system, the management UI) is operated by Edgible. The data plane — your workloads, the gateway if you bring your own — can run wherever you like. A fully self-hosted control plane is not currently a supported deployment.
What happens when my serving device goes offline?
Section titled “What happens when my serving device goes offline?”Public requests for that device’s hostnames will fail at the gateway with a 503 until the device reconnects. The agent reconnects automatically when the device’s network comes back; reconciliation resumes from the last known state. Workloads start back up if their containers were configured to.
Can I move a serving device to a new network?
Section titled “Can I move a serving device to a new network?”Yes. The device’s WireGuard public key and Edgible identity travel with the machine, not the IP address. Move the box, plug it into a different network, and once the agent re-establishes its WebSocket and WireGuard tunnel (typically a few seconds), public traffic resumes routing to it.
What’s a “device pool”?
Section titled “What’s a “device pool”?”A per-organization WireGuard subnet that joins all of your organization’s devices in a private encrypted mesh. Every device gets a stable IP in this pool, and every device can reach every other device over the pool. See Device pools and WireGuard.
What protocols are supported for public access?
Section titled “What protocols are supported for public access?”https, http, tcp, and udp. For https the platform handles TLS automatically. For raw tcp/udp the gateway is a dumb pipe — your workload owns whatever encryption the protocol needs.
Can I use my own domain?
Section titled “Can I use my own domain?”Yes. Create an access entry with hostname: { custom: api.example.com }, point a CNAME (or A record) at the gateway target shown in edgible stack status, and the platform will issue a certificate. See Use a custom domain.
Can multiple workloads in one application talk to each other?
Section titled “Can multiple workloads in one application talk to each other?”Yes — they’re co-located on the same serving device, on the loopback interface. The pattern is the same as Docker Compose: one workload connects to another via 127.0.0.1:<port> or, for compose-typed workloads, via the Compose network’s service names.
Can workloads on different serving devices talk to each other?
Section titled “Can workloads on different serving devices talk to each other?”Yes — over the device pool. Every serving device has a stable IP in the pool’s subnet, and packets between them are encrypted via WireGuard. Higher-level service discovery (a name → device IP lookup) is on the roadmap; for now you address peers by their pool IPs.
Does Edgible support GPUs?
Section titled “Does Edgible support GPUs?”The platform doesn’t manage GPU allocation, but workloads that need a GPU run fine — managed-process workloads have full host access, and Compose workloads can declare GPU requirements via Docker Compose’s standard deploy.resources.reservations syntax. The serving device just needs the relevant drivers installed.
What does it cost?
Section titled “What does it cost?”Pricing isn’t documented here yet — check the marketing site or contact your Edgible representative.
Is there a SaaS-style API I can call without the CLI?
Section titled “Is there a SaaS-style API I can call without the CLI?”Yes — the CLI is a client of a REST + WebSocket API. The API isn’t currently published as a public surface; if you have a use case for direct API access, get in touch.
What does Edgible not do?
Section titled “What does Edgible not do?”- Run your code (your workloads run on your hardware).
- Provide a global CDN with edge caching.
- Replace a Web Application Firewall.
- Manage your DNS provider.
- Provide horizontal autoscaling across machines.
It does the public edge — tunneling, TLS, auth — and gets out of the way.