P2 — define container model/cache/plugin policy and maintained Docker/Podman/Compose deployment examples #182

New issue

Open

opened 2026-08-22 21:58:09 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

2026-08-22 21:58:09 +00:00

(Migrated from github.com)

Parent epic: #153
Depends on: #181
Integrates with: #150 capability-location architecture before claiming complete multi-device deployment.

Goal

Define how large/model/runtime assets and optional plugins are supplied to zara-server, then provide minimal maintained deployment examples that preserve Zara's security/device boundaries.

Model/cache research

For STT/TTS/embedding/local-model assets, decide per asset whether it is image-bundled, separately profiled, mounted cache, or runtime-downloaded. Require pinned/versioned/hashable assets where bundled, explicit writable cache paths, image-size/startup tradeoff documentation, and an offline/cold-start policy. Do not silently download mutable code/models on every boot.

Plugin/tool policy

plugin/module mounts are explicit trusted inputs with owner/permission checks;
plugin child processes remain bounded by existing runtime policy;
server tools may run in container; Linux/Android device actions do not;
no privileged container, Docker socket, host root, desktop session, mic/speaker or broad device mounts in default examples;
provider/API secrets enter only through supported secret/config mounts/environment policy and are never shown in example values/logs.

Examples

Maintain minimal tested examples for Docker and/or Podman, plus Compose only if it materially clarifies persistent volumes/network/key enrollment. Cover local-LAN authenticated CURVE use and optional external Ollama/provider endpoint configuration. Clearly explain client mic/playback stays on client devices.

Tests

Parse/lint example config; start examples with synthetic local fixtures where practical; empty/model-cache/offline cases; plugin mount permission/failure; external provider unavailable; verify no desktop executable assumption and no example secret/privileged flags.

Acceptance

A user has one small documented deployment recipe with predictable model/cache/plugin behavior that matches the tested image instead of an unmaintained kitchen-sink compose stack.

Parent epic: #153 Depends on: #181 Integrates with: #150 capability-location architecture before claiming complete multi-device deployment. ## Goal Define how large/model/runtime assets and optional plugins are supplied to `zara-server`, then provide minimal maintained deployment examples that preserve Zara's security/device boundaries. ## Model/cache research For STT/TTS/embedding/local-model assets, decide per asset whether it is image-bundled, separately profiled, mounted cache, or runtime-downloaded. Require pinned/versioned/hashable assets where bundled, explicit writable cache paths, image-size/startup tradeoff documentation, and an offline/cold-start policy. Do not silently download mutable code/models on every boot. ## Plugin/tool policy - plugin/module mounts are explicit trusted inputs with owner/permission checks; - plugin child processes remain bounded by existing runtime policy; - server tools may run in container; Linux/Android device actions do not; - no privileged container, Docker socket, host root, desktop session, mic/speaker or broad device mounts in default examples; - provider/API secrets enter only through supported secret/config mounts/environment policy and are never shown in example values/logs. ## Examples Maintain minimal tested examples for Docker and/or Podman, plus Compose only if it materially clarifies persistent volumes/network/key enrollment. Cover local-LAN authenticated CURVE use and optional external Ollama/provider endpoint configuration. Clearly explain client mic/playback stays on client devices. ## Tests Parse/lint example config; start examples with synthetic local fixtures where practical; empty/model-cache/offline cases; plugin mount permission/failure; external provider unavailable; verify no desktop executable assumption and no example secret/privileged flags. ## Acceptance A user has one small documented deployment recipe with predictable model/cache/plugin behavior that matches the tested image instead of an unmaintained kitchen-sink compose stack.