jackson hirst

Edgible — ThincSeed 2024, University of Adelaide ThincLab

Private AI on your own hardware, without the self-hosting pain.

Edgible is self-hosting as a service. Deploy AI agents and web apps to any machine — cloud, on-prem, or the box under your desk — and get encrypted tunnels, automatic HTTPS, and a live public URL in four commands. Your data never leaves hardware you control.

Try Edgible ↗Under the hood ↓
The Edgible site — 'Your apps. Your AI. Your hardware.' over a dark starfield

The problem

Cloud AI wants your data

Using hosted AI means shipping your IP and customer data to someone else's servers — and renting GPUs at prices that punish you for experimenting. Private AI shouldn't require a private data centre.

Self-hosting is hostile

SSL certificates, port forwarding, dynamic DNS, VPNs, tunnels — the old way to run your own infrastructure is a part-time job. Most people give up and hand their data back to the cloud.

Lock-in by default

Every managed platform is a one-way door. Edgible runs on any cloud, on-prem hardware, or the machine under your desk — so the exit is always open.

Zero to hosted

A working site, four commands later.

$ npm install -g @edgible-team/cliInstall the CLI
$ edgible auth loginAuthenticate your account
$ edgible deployDeploy the stack declared in edgible.yml
$ # → live at your edgible.com URLTLS and a public URL, provisioned automatically

No port forwarding, no certificate renewals, no domain wrangling — Edgible provisions TLS and routing automatically for anything declared in your stack file.

Under the hood

One engineer, production-grade decisions.

Everything below the marketing line: how Edgible is actually built, and why. Written for the engineers reading this as a case study.

Architecture

A Node.js CLI authenticates devices and orchestrates deployments declared in edgible.yml stack files. Workloads run as Docker containers or managed processes on the user's own hardware; an Edgible gateway reaches them exclusively through encrypted WireGuard tunnels, terminating TLS and serving each app at a public edgible.com URL — so devices behind NAT need no open ports and no public IP.

++++
Architecture diagram — image to come

Trade-offs

WireGuard tunnels over open ports

Every connection between gateway and service runs through an encrypted WireGuard tunnel, so devices behind NAT or a home router are reachable with zero inbound exposure — no port forwarding, no attack surface parked on the public internet.

Declarative edgible.yml stack files

The whole deployment is one reviewable file, so deploys are reproducible and the CLI stays a thin orchestrator instead of an interactive wizard hiding state.

Docker containers or managed processes

Workloads run the way they already exist — containerised apps or bare processes — which keeps local GPU assets usable for AI/ML jobs without forcing a rewrite.

Security & scale

Security-first by architecture rather than policy: every connection is WireGuard-encrypted end to end, customer data and models stay in-situ on customer hardware, and HTTPS is provisioned automatically for custom domains. The platform never holds the data it protects.

Want the product — or the engineer?