MuMuAINovel: A Self-Hosted AI Novel Writing Assistant in Python

What MuMuAINovel actually solves for long-form fiction writers

Writing a novel is not one task. It is an outline, a cast, a world with rules, and then hundreds of scenes that must stay consistent with all three. MuMuAINovel targets that middle layer: the bookkeeping between chapters. The README lists the feature set as an intelligent wizard that generates outlines, characters and worldbuilding, character relationship and organisation charts, chapter creation with regeneration and polishing, and a foreshadowing manager that tracks planted plot threads and flags ones that have not been paid off. There is also a prompt workshop for importing community templates and a book-deconstruction feature.

The intended user is a self-hoster, not a casual writer. The project ships a docker-compose.yml with a PostgreSQL service, a Dockerfile, and an install-termux.sh script, and the README documents hardware tiers from a 2-core, 2 GB personal setup up to an 8-core, 16 GB configuration for 80 to 150 users. Multi-user data isolation is listed as a PostgreSQL feature, and login is either LinuxDO OAuth or a local account. That combination points at a small group: a writing circle, a class, or one person running it on a VPS for friends.

The README is in Chinese and the product surfaces are Chinese-first. Nothing in the repository description suggests an English localisation, so an English-speaking writer should treat the interface language as a real adoption cost rather than a detail.

How the AI pipeline is wired: FastAPI, PostgreSQL and a remote model

The stack is a FastAPI backend on Python 3.12 and a React 18 frontend built with Vite. The Dockerfile is multi-stage: stage one runs node:22-alpine, installs frontend dependencies, patches vite.config.ts so the build output goes to a local dist directory instead of ../backend/static, and runs the frontend build. Stage two is python:3.12-slim, installs gcc, curl, postgresql-client and netcat-traditional, then installs backend/requirements.txt.

One detail matters more than the rest. The Dockerfile installs an ONNX runtime dependency set explicitly described as excluding PyTorch and Transformers, and downloads a converted ONNX embedding model, paraphrase-multilingual-MiniLM-L12-v2, from ModelScope into /app/embedding/onnx. The README puts that model at roughly 400 MB on disk, loaded into memory at runtime. So retrieval and similarity work happens locally, while generation is delegated: the README states the project mainly depends on external AI APIs and does not need a local GPU.

That split is the architecture. PostgreSQL stores projects, characters, organisations and chapter text, with per-user isolation. The local ONNX model handles embedding-shaped work. Every outline, chapter or rewrite is an outbound HTTPS call to OpenAI, Gemini or Claude. If that call fails, the feature fails, and no amount of local hardware helps.

Installing MuMuAINovel with Docker Compose and generating a first outline

The README gives Docker Compose as the recommended path and lists Docker, Docker Compose and at least one AI API key as prerequisites. Clone the repository, then copy the environment template. The README is explicit that this step is required and that the file must be edited with the API key and database password before anything starts.

git clone https://github.com/xiamuceer-j/MuMuAINovel.git
cd MuMuAINovel
cp backend/.env.example .env

After editing .env, the README warns that two files must exist before the stack starts: .env itself, which docker-compose.yml mounts into the container, and backend/scripts/init_postgres.sql, the database initialisation script mounted into /docker-entrypoint-initdb.d. Bring the stack up with the command below.

docker-compose up -d

The Compose file defines a postgres:18-alpine service with a healthcheck and a mumuainovel service that waits for it with depends_on condition: service_healthy, so the application container starts only after PostgreSQL reports ready. When both are up, the README says to open http://localhost:8000 in a browser; the port is mapped from ${APP_PORT:-8000} on the host. Log in, create a project, and the wizard generates an outline, characters and worldbuilding from your prompt. If you would rather not build from source, the README points at the prebuilt image, which it says already contains the model files.

docker pull mumujie/mumuainovel:latest

Where MuMuAINovel breaks, and who should not run it

The dependency on remote APIs is the sharpest limitation. The README's hardware tables describe CPU, RAM, storage and network, and then state that the project mainly relies on external AI APIs and needs no local GPU. There is no documented path to a local model. If your reason for self-hosting is data locality, this design defeats it: your manuscript text leaves the machine on every generation call. The README does not document a redaction step, a proxy mode, or a local-model backend.

Second, the database is not optional. docker-compose.yml defines a postgres:18-alpine service with a healthcheck, and the application service uses depends_on with condition: service_healthy. There is no SQLite fallback in the repository layout. Running this on a shared host with no container runtime is not a supported configuration.

Third, the initialisation script is a hard prerequisite. The Compose file mounts ./backend/scripts/init_postgres.sql into /docker-entrypoint-initdb.d/init.sql read-only, and the README warns to make sure that file exists. If it is missing, PostgreSQL starts with an empty entrypoint directory and the application will meet a schema it did not create. The README does not document rollback or a repair procedure for that state.

Finally, the licence. GPL-3.0 is a copyleft licence. If you fork MuMuAINovel and distribute a modified version, the obligations attach to your distribution. Whether that matters for your situation is a question for a lawyer, not for this article.

Who should not use it: writers who want an offline tool, teams who cannot send unpublished manuscripts to a third-party API, and anyone unwilling to maintain a PostgreSQL instance for a personal writing project.

MuMuAINovel against AI_NovelGenerator and general-purpose chat clients

The closest comparison in the related searches is AI_NovelGenerator, which people search for alongside this project. The difference in approach is where the structure lives. MuMuAINovel puts it in a relational schema: characters, organisations, foreshadowing threads and chapter relationships are rows in PostgreSQL, exposed through a React interface with visual relationship graphs and a foreshadowing timeline. A chat client keeps the same information in a conversation window and relies on the model's context to remember it.

That is the real trade-off. MuMuAINovel's schema survives a context reset, a new session, or a different model, because the consistency data is not in the prompt. The cost is that you must maintain the schema: a character added outside the interface does not exist to the system, and a plot thread the tool never recorded cannot be flagged. A chat client is more forgiving and less structured.

The other difference is deployment. A chat client is a URL. MuMuAINovel is a Compose stack with a database, a 400 MB embedding model and an initialisation script. If you write one short story a month, the stack is more work than the writing.

Maintenance, releases and the upgrade cost you are signing up for

The release cadence is visible in the tags: v1.5.4 on 2026-07-28, v1.5.5 on 2026-08-31, v1.5.6 on 2026-09-16. The last push to the default branch was 2026-09-18. That is a project moving at roughly monthly minor releases, and the README's TODO list marks a long set of features as completed, including the prompt workshop, foreshadowing management and the book-deconstruction feature.

Upgrading is not a git pull. The recommended path is the mumujie/mumuainovel:latest image on Docker Hub, which the README says already includes the model files. The Dockerfile also pins an embedding model revision through the EMBEDDING_MODEL_REVISION build argument, defaulting to a specific commit hash, which means a source build is reproducible but a latest-tag pull is not. The README does not document a database migration step between versions, and it does not document rollback. That is the gap to plan around: with PostgreSQL holding your projects, a version bump is a schema risk you cannot currently verify from the documentation.

The licence is GPL-3.0, and the repository contains a LICENSE file at the top level. For self-hosted personal use the practical effect is minimal. For anyone embedding this in a product, the copyleft terms are the thing to read before writing code against it.

Editorial conclusion

Adopt MuMuAINovel if you write long fiction in Chinese, already pay for an OpenAI, Gemini or Claude key, and can run Docker Compose with PostgreSQL on a 2-core, 2 GB host. Skip it if you want a local model, a permissive licence, or a tool that works without an external API. Before committing, check that backend/scripts/init_postgres.sql is present, that your .env is mounted read-only into the container, and that your chosen provider's model name is accepted by the configured endpoint, because none of these failures produce a useful error message on first boot.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. xiamuceer-j/MuMuAINovel on GitHub