DCEF turns DiscordChatExporter JSON dumps into a readable chat log

A viewer for exports, not a client for Discord

The project is a frontend for the JSON files produced by DiscordChatExporter, and it renders them in a familiar Discord-like user interface. The point is reading, not connecting. The data comes out of Discord first, as files, and the viewer serves those files locally or from a server you control, so the README states that you own the data and can use it locally or self-host it on a server. There is a public demo at dcef.slada.sk. The architecture is a SvelteKit application, and the repository carries a `Dockerfile`, a `src/` directory holding the backend and frontend code, a `release/` directory, and a `docs/` folder with the screenshot. One boundary is worth stating early, because the README states it in a single line: the exporter DiscordChatExporter is maintained by a different maintainer than this viewer.

Prerequisites that are stricter than they look

The README lists prerequisites per platform, and one of them is unusual. On Windows you need Windows 10 or newer, x64 architecture, a CPU with AVX support, and available ports `21011`, `27017` and `58000`. On Linux you need x64 or arm64, Docker or Podman installed, and again a CPU with AVX support, with the note that some VPS providers do not support it. Mac is listed as not supported, yet. The AVX requirement is the one that will bite first, because it rules out older hardware and some cheap virtual machines, and the README even calls out that it works for a Raspberry Pi 5 but not for a Raspberry Pi 4b because that board does not support AVX. The port list is the second constraint, since three ports have to be free before the container will start.

Exports only work with one specific set of flags

The export step is where most of the friction is, and the README is unusually direct about it. The GUI version of DiscordChatExporter needs the `Show threads` option set to `All` if you want threads and forum posts, a Discord token obtained through the exporter's own guide, and the export format set to `JSON` with `Format markdown` disabled, and `Download assets` plus `Reuse assets` enabled to pull images, videos and other assets. The CLI version gives the same requirement in command form:

DiscordChatExporter.Cli.exe exportguild --token DISCORD_TOKEN -g SERVER_ID --media --reuse-media --markdown false --format Json --include-threads All --output OUTPUT_FOLDER_PATH

and for direct messages:

DiscordChatExporter.Cli.exe exportdm --token DISCORD_TOKEN --media --reuse-media --markdown false --format Json --output OUTPUT_FOLDER_PATH

The README summarises it as a rule to always use `--media --reuse-media --markdown false --format Json`, and says plainly that exports without those options will not work with DCEF. That is a hard coupling worth knowing before you start, because an export you already have may need to be redone.

Running it on Linux with one container command

The Linux path is the shortest. You pull the image from Docker Hub:

docker pull slada/dcef:main

then move to the folder holding your exports:

cd /path/to/your/exports

and run the container with your current directory mounted as the exports folder inside it:

docker run --restart=always --volume "$(pwd):/dcef/exports" --volume dcef_cache:/dcef/cache --name dcef -p 127.0.0.1:21011 -it slada/dcef:main

Two details in that command are deliberate. The port mapping binds to `127.0.0.1`, so the viewer is reachable only from the machine itself unless you change it. And the second volume, `dcef_cache`, keeps the parsed index in a named volume so it survives a container rebuild, which is what makes repeated starts fast on a large export. If you use podman instead of docker, the README says to replace `docker` with `podman` in the commands, and to create a systemd service yourself if you want autostart, since docker's restart policy does not cover podman.

Windows releases and the 260 character path limit

On Windows the README lists a release you download and extract, then asks you to move your exports into an `exports/` folder. Only x64 is supported, it will not work on Windows 7, and it has been tested on Windows 10. The awkward part is a registry tweak. You have to apply `registry_tweaks/change_260_character_path_limit_to_32767.reg` and restart your computer, to raise the path limit to 32767 characters. The README then documents the known bug that follows from it: images and other assets will not load if the path to them exceeds 260 characters, even with the tweak applied, with the fix being to place your DCEF folder at a shorter path. So on Windows the layout of your files is part of the configuration, which is a constraint that does not exist in the container version.

Three services inside one image

The Dockerfile shows the whole stack, and it is a more conventional application than the single process name suggests. The frontend is built in a first stage from `node:22.6.0-alpine3.19`, where npm install and `npm run build` turn the SvelteKit application into a static bundle. The runtime image is based on `mongo:6.0.5-jammy`, which explains the `27017` port in the prerequisites, and it installs Python 3.11 with pip, nginx and wget on top. Three separate Python requirement sets are installed, for the `preprocess`, `fastapi` and `configurator` components, and the nginx configuration comes from the repository, including a copied `mime.types` file and `nginx-docker.conf`. The container exposes port `21011` and starts through `run_container.sh`, which is made executable in the build.

Running the development version on Windows

For developers there is a source path, and it has its own toolchain requirements. You need python3 and nodejs, with `node --version` at least `v18.17.1` and `py --version` at least `Python 3.11.0`, plus Windows Terminal, which is installed by default on Windows 11. nodemon is installed globally with `npm install -g nodemon` and is used to reload programs on change, and you verify it with `nodemon --version`. The exports go into a `src/exports/` folder that you create if it does not exist, and then you run the batch script `src/RUN_DEV.bat` from `cmd`:

cd src
: RUN_DEV.bat

The script installs the Python dependencies into a virtual environment stored in `src/_temp`, installs the frontend node dependencies into `src/dcef/frontend/node_modules/`, and then opens Windows Terminal with split panes for the services needed to develop the app.

GPL-3.0, and a project that moves when Discord does

The licence is GPL-3.0, which for a self-hosted tool you run on your own machine is the practical constraint to check before you deploy it anywhere shared. The release line is v2.9.0 from 2023-12-24, v3.0.0 from 2024-08-20 and v3.0.1 from 2026-05-27, and the last push was on 2026-05-27, so the project is not archived and the 3.0 line is the current one. Beta builds are produced automatically from the latest commit on the `main` branch by a GitHub Actions workflow, with a GitHub account needed to download them, which is a useful way to try new features without waiting for a tagged release. The author also maintains a related wrapper, `slatinsky/DiscordChatExporter-incrementalBackup`, which exports new messages from servers and direct messages incrementally from a config file, which is the natural companion when you want to keep an archive current rather than export once.

Editorial conclusion

Adopt DCEF when you have JSON exports from DiscordChatExporter and want them readable in a browser with search, especially when the archive is large, since the project is built for exactly that and ships a container image. Do not adopt it as a general Discord client, because it only reads exported files and never connects to Discord itself, and note that macOS is not supported. Verify first that your export used the flags the project requires, in particular `--media --reuse-media --markdown false --format Json`, since the README states that exports made any other way will not work with it.

Frequently asked questions

Official sources

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