AutoNovel: a self-hosted light novel machine translation site

What AutoNovel actually does

AutoNovel is a website that generates machine translations of light novels and shares them. The README describes it as 轻小说机翻网站, supporting web novels, bunko novels and local novels, and the project tagline is a call to rebuild the tower of Babel. The audience is therefore not a single reader with a folder of Japanese text files. It is a group that wants one place where translated light novels accumulate and are readable by others.

The repository layout confirms the split: a server directory, a web directory, a packages directory for shared code, a db directory holding a mongo-init script, and a daemon directory. The stack is TypeScript on the front end, with Kotlin and Vue among the topics, and the licence is GPL-3.0. If you want a private translation helper, this is the wrong shape of project; if you want to operate a small public or community reading site, the shape starts to make sense.

The five-container architecture behind the site

The docker-compose.yml defines five services on a bridge network named auto-novel. The web service uses the image ghcr.io/auto-novel/auto-novel-web:latest and publishes port 80. The api service uses ghcr.io/auto-novel/auto-novel-server:latest and declares depends_on for mongo, elasticsearch and redis. Three data stores follow: mongo:6.0.3 with MONGO_INITDB_DATABASE=main, elasticsearch:8.18.1 with security disabled and discovery.type=single-node, and a redis service.

The API receives its backing store addresses through environment variables rather than a config file: DB_HOST_MONGO=mongo, DB_HOST_ES=elasticsearch, DB_HOST_REDIS=redis. Translation-related credentials travel the same way: HTTPS_PROXY, PIXIV_COOKIE_PHPSESSID, HAMELN_TOKEN, ACCESS_TOKEN_SECRET and the three MAILGUN_ variables. Three volumes are mounted into both web and api at identical paths: /data/files-temp, /data/files-wenku and /data/files-extra. That shared mount is how generated files become downloadable through the front end.

The Elasticsearch service is the heaviest part. Its entrypoint checks whether the analysis-icu plugin is installed and installs it on first start, then launches eswrapper. ES_JAVA_OPTS is fixed at -Xms2g -Xmx2g, and the container asks for memlock and nofile ulimits plus the IPC_LOCK capability. A host with limited RAM will feel this immediately, and the compose file gives no smaller preset.

Installing AutoNovel with Docker Compose

The README gives a three-step deployment. First clone the repository and enter it:

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

Second, generate a .env file. The README's example leaves the proxy and Pixiv cookie blank and marks the remaining fields as unnecessary for personal deployment:

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
[email protected]
EOF

Third, create the Elasticsearch data and plugin directories with permissive permissions and start the stack:

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

After startup, the README says to visit http://localhost. What you should see is the web front end served on port 80 by the web container. The first run is slow: the API waits on Mongo, Elasticsearch and Redis, and Elasticsearch has to install analysis-icu before it accepts connections. If the page loads but searches or novel pages fail, the API container is the one to inspect, because it owns the database connections and the crawler credentials.

Where AutoNovel breaks down

The README carries an explicit warning: the project is not designed for personal deployment, and it does not guarantee that all features work or that it stays forward compatible. That is unusually direct, and it should be read as a design statement rather than modesty. The compose file backs it up with a fixed 2 GB Elasticsearch heap, three shared volume mounts and a mail service configuration pointing at a specific domain, verify.fishhawk.top.

There is a second failure mode in the credential model. Scraping web novels depends on HTTPS_PROXY, and scraping Pixiv novels depends on PIXIV_COOKIE_PHPSESSID. Both can be left empty, but then the corresponding sources are unavailable, and the README does not document what the UI shows when a source is unreachable. HAMELN_TOKEN appears in the api environment list without explanation, so its role has to be inferred from the code rather than the documentation.

Finally, the README does not document rollback, backup or migration. The mongo-init script is mounted read-only into the container, which means schema initialisation happens on a fresh data directory and nothing in the README covers what happens to an existing one. Treat the ./data directory as the thing you must protect yourself.

AutoNovel compared with running your own translation pipeline

The obvious alternative is not another website but a local pipeline: extract the text yourself, send it to a translation API, and keep the result as files. That approach has no Elasticsearch, no Mongo, no Redis and no port 80, and it works on a laptop. The difference in approach is that AutoNovel treats translation as a publishing activity. It indexes translated novels so they can be searched and shared, which is exactly why it needs Elasticsearch with the ICU analysis plugin: the search layer has to handle the text of the novels, not just metadata.

A second alternative is reading machine translation through a browser extension or a hosted service. Those avoid the operational cost entirely, but they do not give you a library that other people can browse, and they do not let you keep local novel files alongside crawled ones. AutoNovel's three mount points, files-temp, files-wenku and files-extra, exist precisely to mix local and fetched content in one catalogue. If you never need that catalogue, the pipeline wins on every axis that matters: memory, moving parts and upgrade risk.

Maintenance, licence and upgrade cost

The last push to the default branch was on 2026-09-03, so the repository is not archived and is being worked on. There are no retrieved releases, which means upgrades come from the latest image tags rather than versioned artefacts. The compose file pins mongo:6.0.3 and elasticsearch:8.18.1 but pulls ghcr.io/auto-novel/auto-novel-web:latest and ghcr.io/auto-novel/auto-novel-server:latest. Pulling again can therefore change application behaviour without any change to your compose file, and the README's refusal to promise forward compatibility makes that a real operational risk rather than a theoretical one.

The licence is GPL-3.0. If you modify the code and distribute the result, or run a modified version as a network service, the licence's terms apply to what you publish. This is a description of the licence identifier in the repository, not legal advice; read the LICENSE file and the CONTRIBUTING.md before planning a fork, and note that CONTRIBUTING.md is listed as required reading before writing code.

Editorial conclusion

AutoNovel suits people who want to run a shared light novel machine translation site and accept a five-container stack with Elasticsearch at 2 GB of heap. It does not suit anyone wanting a lightweight personal translator or a drop-in library app: the README states plainly that the project is not designed for personal deployment and does not guarantee that all features work or stay forward compatible. Before committing, verify that the two Pixiv and proxy variables are enough for your sources, that the data directories under ./data mount correctly for your user, and that the compose file's Elasticsearch memory settings fit the host you plan to use.

Frequently asked questions

Official sources

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