PocketRisu: RisuAI moved onto a server you control

One SQLite file is the whole data story

Characters, chats, settings and inlay images all live in a single SQLite database on your server. There is no external cloud dependency, which is the point of a self-hosted roleplay client: the archive of your conversations is a file you can back up, move and delete.

Backup is handled by the server itself rather than by a script you write, and the local .bin export and import path exists as well. The dashboard reports disk usage per character and per module, how much of it is reclaimable snapshot space, and offers SQLite optimisation, which is the kind of screen that only makes sense when one file grows large enough to matter.

The cost is a native dependency. better-sqlite3 is compiled rather than shipped as a wheel, and the Dockerfile installs python3, make and g++ in the build stage for exactly that reason on Node 24.

Generation runs on the server, so a locked screen is harmless

The feature that separates this from a browser client is that the model call is issued by your server. Generation continues if your screen locks or the connection drops, and reconnecting restores the completed response automatically instead of losing it.

That design is what makes the rest of the feature list possible. Providers are pluggable across OpenAI, Claude, Gemini, DeepInfra, OpenRouter and Ollama among others, and reaching the same server from a tablet or a phone means your character, your lorebook and your history are all where they were.

Remote access is handled two ways: a Quick Tunnel that produces a URL and a QR code, or Tailscale for a private network. Both are set up outside the app, which is the correct place for them, since a roleplay server holding a full chat history is not something to expose to the public internet by default.

The fork keeps the old container names on purpose

PocketRisu is derived from RisuAI and refined for self-hosted use, and the compatibility story is the reason to pick this fork over starting fresh. Existing RisuAI data can be migrated wholesale, character downloads from RisuRealm still work, and the asset formats carry over: cards in .charx, .risum and .risup form, plus modules, lorebooks and presets. Backup files in .bin format are described as two-way compatible.

The compose file shows how seriously the project takes existing installs. It is still named risuai-nodeonly, the service is risuai and the container is risuai-nodeonly, with a comment explaining that the historical names are kept so v1.5.x users transition without port or container collisions. The volume is named explicitly as risuai-nodeonly_risuai-save, because without that the new project name would prefix it and create an empty save folder for everyone who already had data.

So expect a container called risuai running an app called PocketRisu. It looks like an oversight and is in fact the compatibility layer.

Context work stands in for a bigger model

The features that decide answer quality in a roleplay client are about context, and they are named. A lorebook, also called world info or a memory book, plus HypaMemoryV3 and other context retention features, decide what the model is told before it answers.

Automatic translation covers input and output for cross-language roleplay, and the dependency list shows where that runs: a Bergamot translator package, the engine built for in-browser translation, is a direct dependency rather than a hosted API call.

Then there is the extension layer. Regex scripts and plugins modify model output, character cards are parsed with a RisuAI card library, audio is encoded with lamejs, edits happen in CodeMirror, and rendered output is passed through DOMPurify, which is the right instinct when generated text becomes HTML. Local inference is present too, with a web LLM runtime and a tokenizer package for token counting. Text to speech and embedded images, audio and video in chat are the finishing layer.

The runtime image carries 40 MB of dependencies, not 1 GB

The Dockerfile is where the deployment engineering shows. It is a multi-stage build on node:24-slim with pnpm pinned to 10.34.1 through corepack. The builder stage produces dist/, and the runtime stage then installs only the server's dependency closure, described as about 40 MB against a full production node_modules of roughly 1 GB.

The interesting part is how that list stays honest. The dependency list and its lockfile are committed under scripts/portable/server-deps/, and the build regenerates the list and compares it with the committed one, failing if the two differ. The runtime install is frozen, so transitive versions stay reproducible.

That check is the whole point. A hand-maintained dependency list without a comparison would drift silently, and the image would start missing a module only at run time.

ESM front end, CommonJS server, Svelte under the label

The manifest declares type module and the runserver script executes node server/node/server.cjs, so the server is CommonJS while the client is ES modules. That mixture is deliberate rather than accidental, and it is the kind of detail worth knowing before you patch either side.

The framework is not named in the metadata. The check script runs svelte-check against tsconfig.json and the icon set is the Svelte package, so the UI is Svelte even though the repository's primary language is recorded as TypeScript. The build and dev scripts are Vite, and there are three Vitest configurations, the default, a server one and a compat one, with vitest.setup.ts beside them. A separate check:help script validates help keys.

Node 22.12.0 or newer is required and pnpm is the declared package manager. The root is busy with entry points: install.sh, update.sh, server.sh, server.bat, plus util/, test/, assets/, i18n/ and a stray t.py in an otherwise TypeScript tree.

GPL-3.0, monthly minors, and support that buys nothing

The licence is GPL-3.0. Releases move often enough to be worth pinning if you deploy: v1.11.2 on 2026-09-01, v1.12.0 on 2026-09-06 and v1.13.0 on 2026-09-27, with the last push to main on that same date and the manifest version matching the newest tag. Portable distributions update from the web UI, with automatic version detection, so an unattended instance will pull a new minor on its own unless you intervene.

The funding note is unusually clear. Support through Patreon is entirely optional, supporters can have their name listed in the app, and there are explicitly no extra features and no perks attached to paying. That is a healthier arrangement than the usual paid tier, and it means the paid and free paths are the same build.

Documentation is seven languages in i18n/ beside the English guides in docs/en, and bugs go to GitHub Issues with an email contact at the domain.

Editorial conclusion

PocketRisu fits someone who wants the RisuAI character ecosystem on hardware they own, with a portable container and a server that survives a dropped connection. It does not fit a user who needs their chats anywhere but one machine, because the design is a single SQLite file with no cloud sync. Before migrating, read docs/en/migration.md, and keep the volume name the compose file pins, since renaming it is exactly what strands an existing save folder.

Frequently asked questions

Official sources

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