Where Does Soju Store Config and History?
Where Soju keeps its config file and SQLite database on Linux, and how the message store options differ.
Last updated
Soju keeps server behavior in one small file at /etc/soju/config, with a directive per line for listeners, TLS paths, hostname, and auth. User accounts, networks, and channel state live in a SQLite database beside it, commonly under /var/lib/soju. The split keeps day-to-day admin in chat commands rather than file edits.
History retention hinges on the message-store setting pointing at the database. Systemd units from distro packages already wire the right users and directories, including the admin socket for sojuctl. Back up the config plus the database file and a bouncer restores anywhere.
Where Soju stores this, by platform
/etc/soju/config
One directive per line: listen addresses, TLS cert paths, db location, hostname, and auth mode. Reloads on HUP except for listen, db, and log. Database defaults to ./soju.db, packaged setups use /var/lib/soju. sojuctl needs the admin socket enabled here.
Frequently asked questions
how do I migrate Soju to a new server
Copy /etc/soju/config plus the SQLite database file, usually under /var/lib/soju, with the daemon stopped. Users, networks, and history travel together that way. Recreate TLS certificate paths on the target machine before starting.
where is Soju chat history stored
Set the db directive to a sqlite3 path for self-contained history, or point it at Postgres for larger setups. The message-store directive decides whether history persists at all. BouncerServ manages users and networks at runtime without config edits.
do I restart Soju after config changes
Send a HUP signal to reload config, certificates, and MOTD without dropping clients. The listen, db, and log directives cannot reload and need a restart. Package upgrades usually handle the reload automatically.
Notice an outdated path? Let us know.