Self-contained Docker stack and per-user managed model endpoints
manueljpconde landed the two biggest infrastructure changes in the mikeEU fork at once: a Docker Compose setup that boots the entire stack locally without hosted Supabase or R2, and a redesigned model settings flow that lets each admin configure their own Azure Foundry or local OpenAI-compatible endpoint with a per-record encrypted key.
The compose stack covers frontend, backend, Supabase-compatible auth/PostgREST/Postgres, MinIO storage with bucket init, and schema bootstrap. The stated goal was a lawyer-friendly install path that closes out issue #3 - no cloud accounts required to get running.
The managed models redesign is the more consequential change architecturally. Previously, Azure OpenAI and Foundry endpoints were shoehorned through the public OpenAI provider slot in user settings, which conflated two different things. The fix splits Settings into Public Models (Anthropic, Google, OpenAI platform keys) and Managed Models (per-user configured endpoints). Each managed model record has its own display name, provider type (foundry or local_openai_compatible), base URL, model/deployment name, optional encrypted API key, and capability flags for streaming, tools, and reasoning. The openaiCompatible.ts adapter handles routing. This closes issue #5.
The author is direct that this PR is groundwork for issue #6, not a solution to it. Connection validation, capability probing, and safer defaults for local model tool calls are all explicitly deferred. Two concrete wrinkles surfaced during testing: LM Studio running on the host is only reachable from the backend container via host.docker.internal (not localhost), and local models behave unreliably with OpenAI-style tool calls - hence the recommendation to keep supports_tools off for managed local models until you've tested a specific model with Mike's tool-calling workflows.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?