Architecture
Every OpenEng app follows the same shape: a thin web UI, served from the cloud, that talks to an engine running on your own machine over a sealed, loopback-only channel. The heavy work — model inference, shell execution, database queries, Kubernetes calls — happens locally. This is what makes the whole ecosystem private by default.
Thin UI, local engine
The web app (for example chat.openeng.app) is static and stateless. It renders your data but never processes it. All state and computation live in the engine, a single native binary bound to 127.0.0.1:
| App | Engine | Loopback port | Web app |
|---|---|---|---|
| Chat | openeng-chat | 50056 | chat.openeng.app |
| Kubernetes | openeng-kubernetes | 50054 | k8s.openeng.app |
| Git | openeng-git | 50053 | git.openeng.app |
| Terminal | openeng-terminal | 50052 | terminal.openeng.app |
| Data | openeng-data | 50057 | data.openeng.app |
| Board | openeng-board | 50055 | board.openeng.app |
A sealed transport
The browser reaches the local engine over HTTPS with a browser-trusted certificate, so there is no manual trust step. On top of TLS, every request and response frame is sealed — encrypted end-to-end between the web app and the engine using per-session keys established at a handshake, with a short-lived 0600 local token authorising the caller. Only software running as you, on your machine, can drive the engine.
Local-first & private
- Models are downloaded to and run from your disk (GGUF, ONNX, or your Ollama library). Prompts and model files never cross the wire.
- Credentials — kubeconfigs, database passwords, SSH keys, cloud keys — are resolved locally by the engine and never sent to any OpenEng service.
- Your data — code, query results, logs, boards — is read and written locally.
Cross-app integration
Because every engine speaks the same sealed protocol on a known loopback port, one engine can act as a client of another. The Chat agent uses this to reach your other apps: given a chat group that has a Kubernetes cluster and some Git repos attached, the Chat engine calls the Kubernetes and Git engines directly over internal gRPC to inspect pods, read logs and cross-reference code — all on your machine, scoped to exactly the connections you configured.
Connectors for the cloud
When a resource lives in the cloud (a managed Kubernetes cluster, a cloud database), the engine can't reach it directly without holding your cloud credentials. Connectors solve this: you deploy a small, source-only function into your own cloud account, and the engine calls it over HTTPS. Your credentials and data stay in your account; the OpenEng app never holds the secret.