AutoNovel: self-hosting the light novel machine translation site

What AutoNovel actually does, and who the README is written for

AutoNovel describes itself as a light novel machine translation robot: a website that automatically generates machine translations of light novels and shares them. The README's tagline is a rebuild of the Tower of Babel, which sets the ambition level, but the deployment section is where the project tells you who it is for. A warning block states that the project is not designed for personal deployment and does not guarantee that all features work or that it stays forward compatible. That sentence should shape every adoption decision here.

The audience is therefore a group running a shared site, not an individual who wants one novel translated. The service combines crawling, translation, storage and reading in one deployment, and the repository layout reflects that: separate web, server, daemon, db, packages and scripts directories, plus a pnpm workspace at the root. If your need is a one-off translation of a file you already own, the amount of infrastructure described below is disproportionate. If your need is a site where multiple people request, translate and read novels, the pieces are already wired together.

The service topology in docker-compose.yml

The compose file defines five services on a bridge network named auto-novel. The web service publishes port 80 and mounts three data directories: files-temp, files-wenku and files-extra. The api service depends on mongo, elasticsearch and redis, and receives its connection targets through environment variables: DB_HOST_MONGO=mongo, DB_HOST_ES=elasticsearch and DB_HOST_REDIS=redis. It also passes through HTTPS_PROXY, MAILGUN_API_KEY, MAILGUN_API_URL, MAILGUN_FROM_EMAIL, ACCESS_TOKEN_SECRET, HAMELN_TOKEN and PIXIV_COOKIE_PHPSESSID. Both web and api mount the same three data directories, which is how translated output and source files stay visible to the front end.

The storage layer is opinionated. MongoDB runs as mongo:6.0.3 with MONGO_INITDB_DATABASE=main and mounts db/mongo-init into the entrypoint directory, so schema setup happens on first boot. Elasticsearch runs as 8.18.1 with security disabled, a single node, and ES_JAVA_OPTS set to -Xms2g -Xmx2g, meaning you should budget at least 2 GB of heap for search alone. Its entrypoint is a bash script that checks for the analysis-icu plugin and installs it if missing before starting. Redis is the fifth service. That is a four-process backend before any translation backend is considered.

Installing AutoNovel with docker compose

The README gives a three-step deployment. First clone the repository and enter it. Then write a .env file. The README's own heredoc includes HTTPS_PROXY and PIXIV_COOKIE_PHPSESSID, both of which it marks as optional, and a second group of fields it says personal deployments do not need to fill in: ACCESS_TOKEN_SECRET, MAILGUN_API_KEY, MAILGUN_API_URL and MAILGUN_FROM_EMAIL.

git clone https://github.com/auto-novel/auto-novel.git
cd auto-novel

Next create the environment file. Keep the heredoc exactly as the README writes it, then fill in only the values you have. The proxy variable is for web novel fetching and can be empty; the Pixiv cookie is for crawling Pixiv novels and can also be empty.

cat > .env << EOF
HTTPS_PROXY=
PIXIV_COOKIE_PHPSESSID=

ACCESS_TOKEN_SECRET=
MAILGUN_API_KEY=
MAILGUN_API_URL=https://api.eu.mailgun.net/v3/verify.fishhawk.top/messages
MAILGUN_FROM_EMAIL=postmaster@verify.fishhawk.top
EOF

Before starting, create the Elasticsearch data and plugin directories, because the compose file mounts them and the entrypoint needs a writable plugin path to install analysis-icu.

mkdir -p -m 777 ./data/es/data ./data/es/plugins
docker compose up -d

When the stack is up, the README says to visit http://localhost. The first page load is the real test: it means the web container is serving and the api container has connected to Mongo, Elasticsearch and Redis. The README does not document what a successful translation request looks like, so treat the home page as the only documented checkpoint.

Where AutoNovel breaks or is the wrong tool

The most concrete limitation is stated by the project itself: it is not designed for personal deployment and forward compatibility is not guaranteed. For a self-hoster this means an upgrade can require manual data migration, and the compose file offers no version pin to fall back to. The web and api images are both tagged latest, so a pull can change behaviour without any change on your side.

Resource requirements are the second constraint. Elasticsearch is configured with a fixed 2 GB heap and a single node, and the compose file raises memlock and nofile ulimits and adds IPC_LOCK for it. On a small VPS the search container alone can exhaust memory. Third, the translation backend is not described in the README. The API container accepts HAMELN_TOKEN and the topics list mentions ChatGPT and OpenAI, but no environment variable in the compose file points at an OpenAI endpoint. If you cannot confirm how the API authenticates to a translation service, you cannot confirm that translation will run at all.

Finally, copyright and source terms are outside the project's scope. It crawls web novels and Pixiv novels; the README says nothing about respecting publisher or author terms, and nothing in the repository enforces them. That is a decision the operator makes.

AutoNovel compared with running a translation pipeline yourself

The obvious alternative is not another self-hosted site but a scripted pipeline: fetch source text, send it to a translation API, store the output as files. That approach has no database, no search cluster and no web server, and it fits a single reader or a small archive. AutoNovel's difference is that translation, storage and reading are one product. Elasticsearch with analysis-icu is there so translated text can be searched with CJK-aware analysis, and the three mounted data directories separate temporary, library and extra files. A script gives you none of that; it gives you a folder of text.

The trade-off runs the other way too. A script is debuggable in an afternoon and upgrades when you choose. AutoNovel asks you to operate MongoDB 6.0.3, Elasticsearch 8.18.1 and Redis, to keep a proxy and a Pixiv session cookie alive, and to accept that the project does not promise compatibility between versions. If search across a shared library is not a requirement, the pipeline wins on every axis except convenience.

Maintenance, licence and upgrade cost

The repository was last pushed on 2026-09-03 and is not archived, so the codebase is receiving commits. That is not the same as a supported release: the README lists no releases, and the root package.json declares version 0.0.0. Upgrades therefore mean pulling latest images and hoping the schema in db/mongo-init still matches. There is no documented rollback procedure.

The licence is GPL-3.0. If you modify AutoNovel and distribute it, or run a modified version as a network service for others, the copyleft terms are likely to apply to your changes. That is a summary, not legal advice; read the LICENSE file and, if you plan to run this publicly, take your own counsel. The package manager is pinned to pnpm@10.33.4, which matters only if you build from source rather than using the published images.

Editorial conclusion

Adopt AutoNovel if you want a shared translation and reading site and can run MongoDB, Elasticsearch 8.18.1 and Redis alongside it, and you accept the README's own warning that it is not built for personal deployment. Do not adopt it as a drop-in CLI translator for one book, and do not expect a supported upgrade path: there are no releases, the package version is 0.0.0, and the compose file pins images to latest. Before committing, verify that the Elasticsearch container can install analysis-icu and that the API can reach a translation backend, since the README leaves both unstated.

Frequently asked questions

Official sources

1. auto-novel/auto-novel on GitHub
2. Issues
3. License: GPL-3.0
4. Project website
5. README