Where things live

macOS

Inside rexenv’s own directory

~/Library/Application Support/dev.rexenv.rexenv/

Everything rexenv owns lives under here except your site files: the databases, every downloaded binary, the local certificate authority, the generated server configs, the logs, and the SQLite database holding the app’s own state.

Deleting this directory removes all of it. It is the right thing to remove for a clean slate and the wrong thing to remove casually — your databases are in it.

Your sites

~/rexenv/Sites/

The default Sites folder, one folder per site, visible in Finder. Settings can point it somewhere else; sites already created keep the path they were created with.

Logs, including rexenv’s own

~/Library/Application Support/dev.rexenv.rexenv/logs/

nginx, php-fpm, Caddy, the database engines and every per-site job write here — and so does the app itself, as rexenv.log, in every build rather than only in a development one. It has its own tab in the app’s log viewer, first in the list, because when a service did not start the reason is in rexenv’s log and not in that service’s empty file. It rotates at 2MB, keeping three files.

The app’s log is deliberately here rather than in ~/Library/Logs: one directory beats the platform convention when the convention splits a diagnosis across two places.

Outside it

These are the only places rexenv touches beyond its own directory, and each one is undone by Settings → Remove system changes:

Path	What	Written by
/etc/resolver/rex	Sends *.rex to rexenv’s DNS	An admin prompt on first run
/etc/resolver/<tld>	One per extra TLD you configure	An admin prompt when you add it
A LaunchDaemon	Runs the edge proxy as root on 80/443	An admin prompt on first run
A LaunchAgent	Keeps DNS answering after you quit	No prompt — user-level
Your login keychain	rexenv’s local CA, trusted	The Keychain prompt on first run

The login keychain, not the System keychain

The CA is trusted at user level. That is a deliberate limit on blast radius — the trust is yours, not the machine’s, and removing it needs no admin rights. Remove system changes deletes the CA certificate itself from the keychain, not only its trust setting — through 0.8.12 the trust was removed but an inert rexenv Local CA item stayed behind, unreachable by brew uninstall --zap --cask rexenv.

Windows

Inside rexenv’s own directory

%LOCALAPPDATA%\rexenv\rexenv\data

Everything rexenv owns lives under here except your site files: the databases, every downloaded binary, the local certificate authority, the generated server configs, the logs, and the SQLite database holding the app’s own state. config\, logs\ and bin\ sit beside data\ under the same root.

Deleting that root removes all of it. It is the right thing to remove for a clean slate and the wrong thing to remove casually — your databases are in it.

Your sites

%USERPROFILE%\rexenv\Sites

The default Sites folder, one folder per site. Settings can point it somewhere else; sites already created keep the path they were created with.

The app itself, and the CLI

Path	What
%LOCALAPPDATA%\rexenv	The installed app, about 37 MB, per user — no admin needed
%LOCALAPPDATA%\rexenv\bin	A copy of rex, added to your user Path

The rex copy is deliberate rather than a symlink: creating a symlink on Windows needs a privilege an ordinary account may not have, and a copy inside rexenv’s own folder is removable by the uninstall step without touching anything else.

Outside it

These are the only places rexenv touches beyond its own folder, and each one is undone by Settings → Remove system changes:

Where	What	Written by
An NRPT rule	Sends *.rex to 127.0.0.1	One UAC prompt on first run
One NRPT rule per TLD	Added when you configure another TLD	A UAC prompt when you add it
\rexenv\dns-agent	A logon task keeping DNS answering on 53	The same first-run prompt
Your user’s Root store	Trust for rexenv’s local CA	Windows’ own certificate dialog
Your user Path	The rex copy’s directory	No prompt — user-level

Your user's Root store, not the machine's

The CA is trusted at user level. That is a deliberate limit on blast radius — the trust is yours, not the computer’s, it needs no elevation, and it affects no other account.

rexenv never writes to your hosts file. It is shared by every tool on the machine, and rexenv’s rule is never to overwrite a file somebody else owns.

Linux

Inside rexenv’s own directory

~/.local/share/rexenv/

$XDG_DATA_HOME/rexenv if you set XDG_DATA_HOME. Everything rexenv owns lives under here except your site files: the databases, every downloaded binary, the local certificate authority, the generated server configs, the logs, the SQLite database holding the app’s own state — and lib-compat/, the private symlinks that let MySQL and PostgreSQL find a library Ubuntu renamed (libaio.so.1 on 24.04 and later, libxml2.so.2 on 26.04). Only the engines rexenv starts see them; nothing system-wide changes.

Deleting this directory removes all of it. It is the right thing to remove for a clean slate and the wrong thing to remove casually — your databases are in it.

Your sites

~/rexenv/Sites/

The default Sites folder, one folder per site. Settings can point it somewhere else; sites already created keep the path they were created with.

The app itself

Path	What
/usr/bin/rexenv, /usr/bin/rex	The app and the CLI, from the .deb
/usr/share/polkit-1/actions/dev.rexenv.rexenv.policy	The actions that make password dialogs name rexenv
/usr/libexec/rexenv/privileged-update	What the in-app update’s dialog runs — dpkg -i, only
wherever you put it	The AppImage — one file, replaced in place on updating

Outside it

These are the only places rexenv touches beyond its own directory and the package, and each one is undone by Settings → Remove system changes:

Path	What	Written by
/etc/rexenv/dns.d/rex	Marks .rex as routed to rexenv	A password dialog on first run
/etc/rexenv/dns.d/<tld>	One per extra TLD you configure	A password dialog when you add it
/usr/local/lib/rexenv/dns-route.sh, rexenv-dns-route.service	The rexenv0 link that only .rex names go to	The same first-run dialog
/etc/systemd/system/rexenv-edge.service, /usr/local/lib/rexenv/	The edge proxy, run as root on 80/443	A password dialog when the stack starts
/usr/local/share/ca-certificates/rexenv-local-ca.crt	Trust for rexenv’s CA in the system store	The same first-run dialog
~/.pki/nssdb, the snap Chromium’s database, each Firefox profile’s	Trust for rexenv’s CA in your browsers	No prompt — user-level
~/.config/systemd/user/rexenv-dns.service	Keeps DNS answering on 15353 after you quit	No prompt — user-level
~/.config/autostart/rexenv.desktop	Start rexenv at login, when you turn it on	No prompt — user-level
/usr/local/bin/rex	A link to the CLI, only if you click Install for it	One password dialog

The system store is machine-wide

macOS and Windows trust rexenv’s CA at user level. Linux has no per-user store that curl and PHP read, so the system-store half of the trust is the machine’s — the browser half stays in your own databases.

rexenv never writes to /etc/hosts, nor to a global resolver configuration: .rex is routed by rexenv’s own link, removable without touching anything anybody else wrote.

One pair of files is written by the install script, not by the app, and is therefore not undone by Remove system changes: the apt repository’s source line and its key, /etc/apt/sources.list.d/rexenv.list and /etc/apt/keyrings/rexenv.gpg. Uninstall has the line that removes them.

Linked and cloned sites

A linked site is the exception to all of the above: rexenv serves the folder where it already is, never copies it into its own directory, and never deletes it. Removing the site removes rexenv’s record of it and nothing else.

The same applies to plugins and themes added with repo link — deleting one unlinks it.

Downloads

rex db export and wp dist-archive write to your Downloads folder and print the path.

Nothing else

rexenv does not write to the hosts file on any platform and does not modify your shell profile. On macOS it touches /usr/local only for the rex link you ask for in Settings, and no Homebrew prefix (the cask links rex there, which Homebrew removes on uninstall). On Windows it writes nothing under Program Files and needs no administrator approval to install. On Linux it writes system-wide only what the table above lists, beyond the package’s own files — and Remove system changes takes back every one of them.