Apps
Apps are your own long-running programs, installed to run directly on your EOT-1: watching the live stream, controlling continuous recording, and reporting back what they find, without a separate computer in the loop.
What an app is
An app is a Docker container that your EOT-1 builds and runs for you, started with --network host so it can reach the capture server on localhost and expose its own port directly on the EOT-1’s address. There is no per-app networking sandbox to configure: your app just talks to http://127.0.0.1 the same way any script on the EOT-1 would.
This is the difference between an app and one of the client-side example projects: an example project runs on a separate computer and polls your EOT-1’s API from outside. An app runs on the EOT-1 itself, so it can read every frame of the live stream at full speed with no network hop, and keep working even if your laptop is off or you are away from home.
The contract
Every app agrees to a small, fixed contract so your EOT-1 can manage it safely:
| Requirement | Details |
|---|---|
| Must expose | GET /status: a liveness check plus whatever JSON your app wants to report. Your EOT-1 never interprets it, just relays it to the Apps page. |
| May expose | POST /start / POST /stop for a soft pause and resume (e.g. keep in-memory state). Your EOT-1 tries these first and falls back to a hard Docker start/stop if your app does not implement them, or has hung. |
| Dynamic controls | Any FastAPI app gets buttons and forms in the EOT-1’s UI for free: just tag an operation "Controls" in your own OpenAPI spec and it shows up, re-checked on every call so it can never be used as an open proxy into your app. |
| Resources | Every app runs with a fixed 256 MB memory cap, not configurable, so a runaway app can never starve the capture server. |
| Storage | An app can declare named volumes in its manifest; your EOT-1 owns a directory per volume that survives uninstall/reinstall, mounted at a fixed /data/<name> path in the container. |
Install, manage, and monitor
Installing an app is a source upload, not a registry pull: you send a small JSON manifest plus a build-context tarball (a Dockerfile and whatever source it needs), and your EOT-1 docker builds it natively on its own architecture. Do all of this from the on-device Apps page (http://eyeofthetiger.local/apps-page) or straight over the API:
| Method | Path | Description |
|---|---|---|
| POST | /v1/apps | Install a new app from a manifest + build-context tarball |
| GET | /v1/apps | List installed apps with live status |
| GET | /v1/apps/{name} | One app’s status plus its dynamic controls |
| POST | /v1/apps/{name}/start | Start an app (soft, falling back to Docker-level) |
| POST | /v1/apps/{name}/stop | Stop an app (soft, falling back to Docker-level) |
| GET | /v1/apps/{name}/logs | Stream the app’s container logs |
| DELETE | /v1/apps/{name} | Uninstall an app (its volume data is kept) |
The manifest is {"name", "port", "command", "env", "volumes"}. See the full field-by-field reference at http://eyeofthetiger.local/docs once your EOT-1 is on the network.
Events: telemetry your app reports
Alongside the apps platform, your EOT-1 runs a small local events store for structured telemetry (“driver was drowsy from T1 to T2, here are the metrics”) that your app reports and your EOT-1 durably queues for upload. An event is opaque JSON as far as your EOT-1 is concerned: it never validates type or payloadbeyond a size limit.
What your EOT-1 does do is match every event, at the moment it is recorded, to whichever continuous-recording segment covers its timestamp, so a human reviewing events later can click straight through to that moment in the footage.
| Method | Path | Description |
|---|---|---|
| POST | /v1/events | Report an event: type, started_at, ended_at, payload |
| GET | /v1/events | List events, filterable by type and date |
Browse events on your EOT-1 itself at http://eyeofthetiger.local/events-log.
Try it: a minimal example
test-app is the smallest possible app: no camera or computer-vision work at all, just timed calls into your EOT-1’s own local API. Every 60 seconds it starts continuous recording, waits 10 seconds, stops it, and declares one event timestamped to the segment it just recorded. It exists purely to exercise the apps platform, continuous recording, and the events API end to end, and it is a good starting skeleton for a real app of your own.
tar -czf test-app-context.tar.gz -C test-app service.py requirements.txt Dockerfile .dockerignore
curl -X POST http://eyeofthetiger.local/v1/apps \
-F 'manifest={"name":"test-app","port":8101,"command":["python","service.py","--capture-url","http://127.0.0.1:80","--port","8101"]}' \
-F '[email protected]'
curl http://eyeofthetiger.local:8101/statusThe full source (service.py, Dockerfile, and its own README) is in the documentation repo:
This same platform also runs real computer-vision apps behind the scenes, for example a driver-drowsiness detector that reads the live stream continuously and reports drowsiness events the same way test-app reports its ticks.
Ideas for apps to build
Because an app runs on your EOT-1 itself, it fits best when you want continuous, low-latency processing of the live stream with no separate computer required.
Looking for client-side project ideas that run off your EOT-1 instead? See Examples. For the full HTTP API, see the API Reference.