Ollama provider and local file storage for self-hosted deployments
rglauco adds Ollama as a first-class LLM provider and rewrites the file storage layer to support on-disk storage without Supabase Storage or R2. Together these make a fully self-hosted Mike deployment viable.
The Ollama integration is a new backend/src/lib/llm/ollama.ts (317 lines) implementing the same streaming/completion interface as the existing cloud providers. It routes via OLLAMA_BASE_URL (default http://localhost:11434/v1), which also covers llama.cpp via LLAMACPP_BASE_URL. Three default model names appear in the UI picker (local-gemma-26b, local-llama3.3, local-deepseek-r1), but any model name passes through at runtime. The user_api_keys schema gains ollama as a valid provider value, and the frontend gets an Ollama-aware model selector and an account-page form for base URL and key configuration.
The storage change is a +243 line overhaul of backend/src/lib/storage.ts. Local disk becomes the default when R2 credentials aren't set; files live under ./uploads (configurable via LOCAL_STORAGE_PATH). A new backend/src/routes/localFiles.ts serves stored files through short-lived signed tokens generated by lib/localSignedTokens.ts, keeping the existing frontend download flow working without modification. Mode selection is env-var driven: R2 credentials present takes priority over local disk.
The commit also ships binary test PDFs in tabular/ fixture directories, roughly 5 MB of blobs that have no place in a production fork. Strip those before importing. The storage mode switching is conditional logic woven through storage.ts rather than a clean interface, so the whole branching mechanism comes along for the ride.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?