Self-hosted service
CaviraOSS/PageLM avatar
CaviraOSS/PageLM

PageLM: a self-hosted NotebookLM alternative for turning PDFs into quizzes and audio

PageLM is a community driven version of NotebookLM & a education platform that transforms study materials into interactive resources like quizzes, flashcards, notes, and podcasts.

1,980 stars268 forksTypeScriptNOASSERTION

At a glance

What is it?
PageLM is a TypeScript monorepo that wraps several LLM providers behind a study-tool interface: chat over documents, Cornell notes, flashcards, quizzes, podcasts and transcription. The interesting part is the provider abstraction and the JSON-first storage; the unclear part is the licence and the operational weight of running it yourself.
Who is it for?
Adopt PageLM if you want the study-material pipeline running on your own hardware or against a local Ollama model, and you are willing to read the PageLM Community License before putting it in front of students. Do not adopt it if you need a published release history, a stable API contract, or a licence that a procurement office will recognise without a conversation.
Can I use it commercially?
Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
Is it still maintained?
Yes. The repository last received commits 17 days ago.
What is it written in?
Mainly TypeScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

The gap PageLM is aimed at: study material that never becomes practice

A lecture recording, a PDF reader and a folder of slides are passive artifacts. Turning them into retrieval practice means a second pass: writing questions, extracting terms, summarising into a structure you can review later. PageLM's premise is that one upload should produce all of those at once. The README describes it as a platform that converts study material into quizzes, flashcards, structured notes and podcasts, and it lists the input formats as PDF, DOCX, Markdown and TXT. The audience named in the README is students, educators and researchers. There is also a Voice Transcribe feature for lecture recordings and voice notes, which is the clearest signal that the intended workflow starts with raw classroom capture rather than with a tidy document set. The project is community-driven and the README opens with a call for volunteers across development, design, social media and content. That tells you something operational: this is not a product with a support contract behind it.

How the pipeline is wired: LangChain, LangGraph and a provider list

The stack table in the README puts Node.js, TypeScript, LangChain and LangGraph on the backend, with Vite, React and TailwindCSS on the frontend. Storage defaults to JSON, with an optional vector database for embeddings and retrieval. Generated content is written to file-based persistent storage, and outputs are Markdown. The chat, notes and podcast generation paths use WebSocket streaming, which is what allows partial text to appear while a model is still producing tokens. The model layer is deliberately plural: the README lists Google Gemini, OpenAI GPT, Anthropic Claude, xAI Grok, MiniMax, Ollama for local inference, and OpenRouter. Embeddings are a separate choice, limited to OpenAI, Gemini and Ollama. That separation matters more than it first appears. You can run chat against a local Ollama model while still needing a hosted embedding provider, or vice versa, and the README does not describe a fallback if the embedding provider is unavailable. The feature list is broad: Contextual Chat, SmartNotes (described as Cornell-style), Flashcards, Quizzes, AI Podcast, Voice Transcribe, Homework Planner, ExamLab, Debate and Study Companion. Breadth of this kind usually means uneven depth, and the README gives no detail on how ExamLab simulates an exam or how the Debate mode scores an argument.

Getting it running: the constraints the README actually states

The badges give the hard version floors: Node.js >= 21.18.0, React 18 or later, TypeScript 5.0 or later. Node 21 is not an LTS line, so anyone on Node 20 LTS will need a version manager before the install will work. The repository layout follows a client and server split typical of Vite plus Node projects, and the README's technology table names the pieces you will be configuring: an LLM provider, an embedding provider, and a storage mode. The storage choice is the first real decision, because JSON is the default and a vector database is optional. Choosing JSON means retrieval is not semantic in the way a vector index is, and the README does not document a migration path between the two modes. The second decision is the TTS engine for podcasts; the README names Edge TTS in the audio row of the stack table. Because there is no homepage and no release retrieved, the practical install path is a clone of main plus whatever the repository's own setup documentation says. Treat the README as a feature inventory, not an installation guide. It describes what the system can do and which providers it accepts, and leaves the environment variable names and service wiring to the code.

The licence is the first thing to resolve, not the last

The repository does not carry a recognised SPDX identifier. GitHub reports NOASSERTION, and the README badge points to a PageLM Community License rather than MIT, Apache-2.0 or AGPL. That is a material difference for anyone embedding this in a school or a commercial tutoring product. A community licence can restrict redistribution, hosted-service use, or commercial deployment in ways that a permissive licence does not, and the only way to know which of those applies here is to read the LICENSE file in the repository. I cannot tell you its terms from the material available. What I can say is that a project with no releases, no homepage and a custom licence is a project where the licence text is part of the technical evaluation, not a formality to check after the pilot. If your organisation has a policy against non-SPDX licences, that policy resolves the question before any of the technical trade-offs below matter.

Where it will disappoint: JSON storage, provider sprawl and no release history

The default JSON storage is the limitation I would probe first. File-based persistence is simple to inspect and easy to back up, and it is also the thing that stops scaling gracefully once a user has hundreds of documents and the retrieval layer has to scan them. The README offers an optional vector database but does not say which one, how the switch is made, or whether existing JSON-stored embeddings can be carried over. The provider matrix is the second friction point. Seven chat providers and three embedding providers is flexibility that turns into configuration surface: each combination is a separate path through the code, and the README gives no compatibility matrix. Third, the absence of releases and the absence of a homepage mean there is no versioned artifact to pin to and no changelog to read before upgrading. You are tracking main. For a personal study tool that is acceptable. For a department deploying to students, it is a maintenance commitment with no upstream contract. Finally, the feature list promises a lot of distinct modes, and the README describes none of their evaluation criteria, so quality of generated quizzes and exam simulations is something you have to judge yourself on your own material.

How it differs from running NotebookLM or a plain RAG script

NotebookLM is a hosted Google product: you upload sources, it grounds answers in them, and you get audio overviews. You do not choose the model, you do not control where the documents live, and you cannot run it against a local Ollama instance. PageLM's difference is exactly that control. The README's provider list includes Ollama for local inference, which means the document and the generation can both stay on hardware you own, and the storage layer is file-based rather than a managed service. The trade is that you inherit operations: Node version management, provider keys, embedding configuration, and the JSON versus vector decision. A hand-rolled RAG script built on LangChain is the other comparison, and here PageLM's advantage is the assembled surface rather than the retrieval itself. The quizzes, flashcards, Cornell notes, podcast generation, transcription and exam simulation are already wired to the same document store. Rebuilding that from scratch is a few weeks of work, not an afternoon. PageLM is what you pick when you want the study-tool layer built and you are willing to accept the project's own choices about storage and providers.

Maintenance cost and who should actually install this

There are no retrieved releases, so upgrades mean pulling main and reading commits. With a custom licence, an optional vector database, seven chat providers and three embedding providers, the configuration surface is the maintenance surface. A self-hoster on Ollama with a small document set has a low ongoing burden: one Node version to keep current, one local model to update. A team running hosted providers across many users has a heavier one, because each provider integration is a separate failure domain and the README documents no retry behaviour or fallback. If you are an individual student or a developer who wants a local study pipeline and can read the licence, PageLM is a reasonable starting point. If you are buying for an institution, the missing release history and the non-SPDX licence are the two items to resolve before a pilot, not after. Start by reading the LICENSE file and by testing the JSON storage path against a realistic document count; those two answers will tell you more than the feature list does.

Editorial conclusion

Adopt PageLM if you want the study-material pipeline running on your own hardware or against a local Ollama model, and you are willing to read the PageLM Community License before putting it in front of students. Do not adopt it if you need a published release history, a stable API contract, or a licence that a procurement office will recognise without a conversation. Verify three things first: the exact terms in the LICENSE file, whether the JSON storage default survives your document volume, and which embedding provider you will pair with your chosen LLM, because the README lists OpenAI, Gemini and Ollama as separate choices from the chat models.

Official sources

  1. CaviraOSS/PageLM on GitHub
  2. Issues
  3. README
Community notes

Community notes