The Problem
Organizations need Notebook LM-style AI research workflows—chat over documents, podcast generation, source-grounded Q&A—but cannot send proprietary data to Google's cloud. open-notebook addresses this with a self-hosted alternative that keeps data local and lets teams choose their own AI providers.
What This Does
open-notebook is a full-stack application with a Django REST API (api/main.py) and React/Next.js frontend (frontend/src/app/). The backend exposes routers for core features: notebooks, sources, chat, transformations, and podcasts under api/routers/. Service layers (api/chatservice.py, api/sourcesservice.py, api/podcastservice.py) handle business logic, with api/embeddingservice.py managing vector search.
The frontend is organized by feature area: notebooks/, sources/, transformations/, podcasts/, and settings/. A command palette (frontend/src/components/common/CommandPalette.tsx) provides keyboard-driven navigation. The system supports 18+ AI providers, multi-speaker podcast generation, and full-text plus vector search.
How To Use It
Setup: Docker is the primary path. Use docker-compose.yml with the Dockerfile (full build) or Dockerfile.single (single container). The Makefile provides common targets. For source installs, api/ uses Python and frontend/ uses npm (frontend/package.json).
Configuration: Copy .env.example to .env and set API keys. AI provider configuration lives in docs/5-CONFIGURATION/ai-providers.md; Ollama and OpenAI-compatible endpoints are covered in dedicated docs. Database setup is in docs/5-CONFIGURATION/database.md.
Running it: With Docker Compose:
docker-compose up -d
For development, examples/docker-compose-dev.yml mounts source code with hot reload. The API entry point is api/main.py; the frontend runs as a standard Next.js dev server (npm run dev in frontend/).
Real-World Use
A legal research team needs to analyze case files without external data exposure. They deploy open-notebook on internal infrastructure with Ollama for embeddings and a local LLM. Users upload PDFs via the sources interface, ask questions in chat with source citations, and generate internal briefing podcasts with custom speaker profiles (api/routers/speakerprofiles.py). The REST API allows automation—e.g., a script that ingests new court rulings into a notebook and triggers a transformation.
Code Health & Issues
Med - Test coverage is thin: Only 4 test files exist (ChatColumn.test.tsx, ConfirmDialog.test.tsx, plus API tests). Core services like chatservice.py and podcastservice.py lack direct tests. Med - CI is limited: GitHub Actions runs a test.yml workflow, but build-and-release.yml and build-dev.yml focus on container builds, not comprehensive validation. Low - API surface is large: 20+ routers in api/routers/ with overlapping concerns (e.g., chat.py vs sourcechat.py). This may create maintenance burden as the project grows. Low - Frontend structure is clean: Route groups and component separation follow Next.js conventions. No obvious code smells in the file layout. Positive signals: MIT license present, .env.example keeps secrets out of the repo, documentation is extensive (63 files), and CHANGELOG.md tracks releases.
The Bottom Line
open-notebook is a capable self-hosted alternative to Notebook LM with strong provider flexibility and a clean architecture. The thin test suite and broad API surface are the main risks for long-term maintenance. Best suited for teams that need data sovereignty and are willing to invest in their own testing and operational hardening.