The Windows Installer

Dokime’s release distribution is configured as a Tauri 2 Windows NSIS bundle (Linux ships DEB and RPM packages). The installer contains the desktop application, its embedded frontend, branding, and the dokime CLI, installed side by side in the same directory. On Windows the installer also adds that directory to your user PATH (and removes it again on uninstall), so dokime works from any terminal after installation. Plugins are not part of the installer: install them through the plugin store, or pass a bundle path explicitly when starting a backend.

The desktop application does not contain a second copy of the runtime. When you start a local backend from the connection screen, it runs that installed dokime and closes it again when the application exits.

By default the Windows installer installs for the current user only, into your profile’s %LOCALAPPDATA% folder — no administrator privileges are required. cargo-dokime is not part of this installer; install it separately through Cargo (see Command-line tools).

Choose Where Execution Data Is Stored

Open Settings → General → Output to select the execution-data folder. The application saves this choice in your local user configuration and applies it after restart. Existing history stays in its original folder; changing the selection does not move or delete it. The folder selector is also available on the backend startup-error screen if a disk or directory becomes unavailable. See storage locations for configuration paths and environment overrides.

Command-line tools

The installer already places dokime on your PATH; no separate step installs it. Install the cargo-dokime developer extension through Cargo, from the same pinned Git revision:

cargo install --git https://gitlab.com/stokker-technologies/open-source/dokime.git --rev <release-revision> --locked cargo-dokime

Use the full revision recorded by that release in place of <release-revision>. Dokime’s family crates remain Git sourced; a crates.io publication is not required for this install. The desktop installer does not provide Rust or Cargo.

Cargo discovers the installed extension when you run cargo dokime. cargo dokime dev finds the Dokime installation this installer places on your PATH automatically; pass --dokime PATH to point it at a different host explicitly. Verify both tools with dokime --version and cargo dokime --version.

Develop a plugin

Install Rust with rustup, which provides rustc and cargo, and install Git. On Windows, use the MSVC Rust toolchain with the Visual Studio Desktop development with C++ build tools and Windows SDK. Open a new terminal after installing tools, then verify:

rustc --version
cargo --version
git --version
cargo dokime --help

You also need GitLab source access to Dokime and its Harmos dependency. The installed CLI generates a project with a full SDK Git revision associated with its build; Cargo must be able to fetch that source and its dependencies. Installing the application does not grant repository access or install an SDK source tree.

Continue with your first plugin to check source access, generate a project, run it in the browser, and build a release bundle. No Dokime repository checkout or separate template download is needed.

Check The Configuration

This validation is platform-independent:

mise run installer:check

Run the native storage, desktop configuration, and packaging regression checks on a Windows development host with:

mise run sync
mise run test

This task requires Windows. It supplements the Linux checks; a Linux run or a cross-compilation does not certify Windows filesystem or installer behavior. Also exercise first launch, changing the data folder, restart, existing history, and an unavailable destination in the installed application. Include paths with spaces and Unicode. Check publication retries and the actual target filesystem before using an external or network drive for authoritative execution storage.

Build The Installer

The task builds NSIS installers on Windows and DEB/RPM packages on Linux:

mise run installer:release

Windows artifacts are staged beneath dist/tauri/windows-x86_64; Linux packages are written to the Cargo target directory under release/bundle. Preparation, Tauri compilation, and artifact collection run sequentially so Cargo can rebuild the tooling safely on Windows. On Windows the same task also runs tauri package afterward to verify the collected release artifacts and produce Dokime’s product package.

Download A CI-Built Installer

CI builds installers on every push to main as job artifacts (there is no package registry). Download the latest artifacts directly:

https://gitlab.com/stokker-technologies/open-source/dokime/-/jobs/artifacts/main/download?job=installer%3A%20%5Bwindows%5D
https://gitlab.com/stokker-technologies/open-source/dokime/-/jobs/artifacts/main/download?job=installer%3A%20%5Blinux%5D

installer is now a single job that runs as an OS matrix, so GitLab names its instances installer: [windows] and installer: [linux]; the job= query parameter above is that name, URL-encoded (%3A is :, %20 is a space, %5B/%5D are [/]).

Fast Local Builds

Use mise run installer:dev instead of installer:release when only the installer packaging itself needs testing — staged resources, the sidecar layout, NSIS hooks, DEB/RPM file lists — and the minutes an optimized release build costs would slow iteration. It runs the same prepare/collect flow with Tauri’s --debug flag, compiling with Cargo’s built-in dev profile (and building the companion dokime CLI with the matching dev profile, so the installer stays internally consistent); Linux output lands under target/debug/bundle/{deb,rpm} and the Windows NSIS installer stays under target/debug/bundle/nsis, separate from — and never overwriting — the release-profile artifact under target/release/bundle, with a sibling BUILD-PROFILE file marking it as a dev build. Dev builds are always unsigned, with updater artifacts disabled. Alternating between installer:dev and installer:release restages the dokime CLI binary for the matching profile each time (changed bytes trigger a dokime-gui relink), so stick to one profile within a single iteration loop for the fastest repeated builds.

Signing Behavior

If TAURI_SIGNING_PRIVATE_KEY (or its configured file path) and the matching password are present, the release task enables signed updater artifacts. If they are absent, it builds an unsigned installer and disables updater artifact generation. This fallback supports local packaging; it is not equivalent to a signed production release.

The configured updater targets the project’s private GitLab release channel. Installing a local unsigned build does not make that update channel public.