Device-backed trust
Authentication starts from the physical dongle, not just the app session. That keeps secret material out of the mobile client and lets the backend trust a verified hardware flow.
Edge meets cloud
One product line. Two runtimes. One clear trust model.
Gopilo ties together hardware-backed device identity, a mobile operator flow, and a cloud backend that keeps AI credentials and session policy on the server where they belong.
BLE dongle-assisted auth flow
HTTPS public API through api.gopilo.tech
RPi + Cloud edge runtime with separate remote backend
What this website is for
This public site gives the project a clean front door. It stays separate from the product UI and from the mobile runtime so each surface can evolve at its own speed without dragging the others into the same deployment or code path.
Built for field movement
The product is designed around real installation and diagnostic work: mobile-first operation, low-friction pairing, and a backend that stays out of the way when the connection needs to be fast.
A clean split of responsibilities
The local EdgeProbe runtime stays focused on hardware and transport, while the cloud backend handles sessions, AI orchestration, quotas, and remote control points.
Current public architecture
The public web presence and the mobile backend can live on the same Raspberry Pi without sharing the same application runtime. Caddy terminates HTTPS and routes traffic by domain name.
Traffic flow
External traffic lands on the same public ports for both domains. Caddy uses the hostname to decide whether the request should be served as the project site or proxied to the backend.
Internet -> gopilo.tech or api.gopilo.tech -> Caddy :80/:443
Routing split
- gopilo.tech serves the static SvelteKit site build
- api.gopilo.tech reverse proxies to the cloud backend
- 127.0.0.1:8081 stays private to the host