Install

What ends up where

/opt/diwall/               programs, Python environment, Chromium (both channels)
├── shot.py rpa.py watch.py
├── lib/ scenarios/ docs/
├── venv/                  isolated Python environment, built at installation
└── .cache/ms-playwright/  Chromium, downloaded by Playwright at installation
/usr/bin/diwall-*          the six commands (package channel)
/etc/diwall/diwall.conf    configuration (package channel)
/opt/diwall/diwall.conf    configuration (Git clone channel)
/var/log/diwall/           operations log (operations.jsonl) and proof archives
/tmp/diwall/               the captures of each run, cleared at reboot
~/Vaults/Diwall/           your encrypted credential directory (gocryptfs), mounted by you

Each diwall-* command runs the matching program with /opt/diwall/venv/bin/python3; all it adds is where to find the configuration. diwall.conf is never created for you, and it can move the operations log (journal.chemin) and the credential directory (secrets_dir) elsewhere.

Two channels, one per machine

Take the package unless you intend to modify Diwall’s own code. The two channels are mutually exclusive on a single machine, for two reasons:

• both install into the same /opt/diwall/, and the package manager does not know about the files install.sh puts there — neither an upgrade nor a removal accounts for them;
• they read their configuration from two different places, so on a machine with both, which configuration applies depends on whether you typed diwall-shot or ran shot.py.

install.sh, deploy.sh and uninstall.sh refuse to run on a machine where a package is installed, and print the command that removes it. The package does not detect a Git clone installation: in that direction, keeping to one is up to you.

What it needs

Measured on 25 September 2026, on Debian 13.7 with Diwall 1.24.0 — these figures will move, and the date is what keeps them honest.

Package — the simple path

Download the file for your system from the latest release or the Downloads page, then:

sudo apt install ./diwall_1.24.4-1_all.deb   # Debian 13, Ubuntu 24.04, Ubuntu 26.04
sudo dnf install ./diwall-1.24.4-1.fc44.noarch.rpm   # Fedora 44
sudo zypper install --allow-unsigned-rpm ./diwall-1.24.4-1.leap160.noarch.rpm   # openSUSE Leap 16.0
sudo pacman -U ./diwall-1.24.4-1-any.pkg.tar.zst   # Arch Linux

That is all. It creates the diwall system user, the virtual environment and /opt/diwall/, puts the six diwall-* commands in your PATH, and ships the manual page:

man diwall
diwall-shot --version

Configuration lives in /etc/diwall/diwall.conf, with a commented sample installed beside it.

Upgrading is the same command with a newer file; your configuration is kept.

Removal depends on the family. On Debian and Ubuntu, sudo apt remove diwall keeps the configuration, the journal and the reference captures with the diwall account that protects them; sudo apt purge diwall removes them all. On Fedora, openSUSE and Arch there is a single command (sudo dnf remove diwall, sudo zypper remove diwall, sudo pacman -R diwall): it deletes what can be rebuilt — virtual environment, Chromium — keeps what you produced with the diwall account, and prints the command that erases it. If you produced nothing, nothing is left.

From source — to modify Diwall itself

git clone https://github.com/RonanDavalan/diwall.git
cd diwall
bash scripts/install.sh

This channel exists so the whole environment can be rebuilt from the Git repository alone. If a single step were missing from the documentation, the rebuild would fail — which is why that rebuild is tested rather than assumed.

Then, before anything else

Diwall refuses to run until whoever drives it has read the guide and can quote its version number. This is not a formality: an agent that has not read it improvises, and improvisation around credentials and a browser is exactly what the lock exists to prevent.

grep notice-version /opt/diwall/docs/GUIDE_LLM.md

The number it prints is what you pass as --guide-version.

Your first run →