Skip to content
Edgible Docs

What is Edgible?

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

You install a small agent on each machine you want to serve from. 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.
  • 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 you own, with its storage intact.

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.
  • 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, 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.
  • Storage and migration — declare persistent volumes, attach them to workloads, move applications between devices with their state intact.
  • A web app for visibility into your devices, applications, and logs, alongside the CLI.

Coming later: Edgible-managed cloud hosting — running workloads on Edgible-operated infrastructure instead of your own hardware — is planned for a future release. It is not part of the current beta; everything above runs on hardware you own.

Where to go next

Section titled “Where to go next”