Skip to content
Edgible Docs

What is Edgible?

Edgible is a platform for publishing services to the public internet that run either on hardware you control or on Edgible-managed cloud infrastructure — without exposing your hardware to inbound traffic.

You install a small agent on each machine you want to serve from, or pick a cloud region for the platform to run your workload in (or both). You authenticate against your Edgible organization. From that point on, you describe what you want to run in YAML and Edgible takes care of:

  • Routing public traffic from the internet to the workload over an encrypted tunnel — whether the workload lives on your hardware or in an Edgible Firecracker microVM.
  • Issuing and rotating TLS certificates for every hostname you publish.
  • Starting, monitoring, and stopping your workloads (Docker Compose stacks, single containers, managed processes, virtual machines, or pre-existing services).
  • Enforcing access policy — public, organization-only, API-key, or short-code.
  • Migrating an application between devices, or from a device into the cloud, with its storage intact.
  • Suspending cloud-hosted workloads when idle and waking them on the next request.

What the platform is not: a place that takes custody of your code. Your workloads run where you tell them to run. Edgible is the control plane and the public-facing edge — a thin layer that turns “a service somewhere” into “a service on the internet.”

Who uses it

Section titled “Who uses it”
  • Builders self-hosting their own SaaS — run the API, the database, and the web app on a single box at home, expose just the web app at app.example.com, keep the database internal.
  • Teams running on-premises infrastructure — give a remote engineer access to an internal tool without standing up a VPN, opening firewalls, or routing through a public load balancer.
  • Edge and ML workloads — run a model on a GPU box that lives somewhere with consumer-grade internet, and serve inference requests from it as if it were in a data center.
  • Builders who want a cloud endpoint without operating one — deploy directly to Edgible cloud, get a public HTTPS URL, sleep when idle.
  • Hobbyists who want HTTPS without thinking about it — point a domain at it, deploy, done.

What you get out of the box

Section titled “What you get out of the box”
  • A CLI (edgible) for everything: login, install, deploy, inspect.
  • A declarative YAML format (apiVersion: v3, kind: Application) for describing workloads, where they run (your hardware or cloud), and how the public reaches them.
  • An agent that runs on each device, talks to the Edgible control plane over WebSocket, and reconciles desired state with reality.
  • A managed edge — the bit of public infrastructure your traffic enters before reaching your tunnel. You don’t run this; Edgible does.
  • Cloud hosting in supported regions — Firecracker tenant microVMs that you can target with placement.strategy: cloud, with optional sleep/wake.
  • Storage and migration — declare persistent volumes, attach them to workloads, move applications between devices or into cloud with their state intact.
  • A web app for visibility into your devices, applications, and logs, alongside the CLI.

Where to go next

Section titled “Where to go next”