VoxRox Mail

Desktop email client for Windows, built as a monorepo: Spring Boot backend (sidecar) + SvelteKit/Tauri desktop UI. Targets single-user, local DB, no SaaS.

Project website: voxrox.org (Czech/English) — includes the support and privacy policy pages.

Have an idea for the app? Start a discussion in Ideas rather than opening an issue — upvotes there help us prioritise. Bug reports go through Issues.

The backend runs as a local Tauri sidecar bound to 127.0.0.1 on a random port. The frontend discovers the port and an in-memory API key via a handshake file (session.json) the backend writes on startup. Single ship artifact, single user, all data on disk under %LOCALAPPDATA%\VoxRox\Mail.

Stack

• Backend: Java 25, Spring Boot 4, SQLite, IMAP/SMTP, OAuth2 (Google, Microsoft)
• Frontend: SvelteKit 3, Svelte 5, Tailwind CSS 4, Tauri 2
• Tests: JUnit + Spring Test (backend), Playwright + MSW (frontend)

Repository layout

backend/    Spring Boot mail backend (runs as a Tauri sidecar)
frontend/   SvelteKit + Tauri desktop UI
LICENSE     MIT

Quick start

Requires Node.js 26, JDK 25, Rust toolchain (for Tauri build), Windows.

1. Backend (sidecar)

cd backend
cp .env.example .env                          # fill in OAuth values; leave MAIL_CRYPTO_* empty for desktop bootstrap
./package-sidecar-dev-windows.ps1 -SkipTests  # jpackage image with the OAuth client ids from .env baked in

Without OAuth values in .env the packaging stops; pass -AllowPlaceholderOAuth to build a sidecar whose OAuth login will not work.

2. Frontend (Tauri dev)

cd frontend
npm install
npm run sidecar:sync:windows   # copies the backend artifact into src-tauri/binaries/
npm run tauri:dev

Tauri starts the sidecar itself, with the values from backend/.env; there is no backend process to launch by hand. tauri:dev refuses a sidecar packaged from other backend sources than the ones checked out, so after a backend change repeat step 1 and the sync.

In desktop mode Tauri does not forward MAIL_CRYPTO_KEY/MAIL_CRYPTO_SALT from backend/.env; the backend creates and uses a local crypto.bin instead. It lands in the data directory Tauri hands the sidecar via APP_DATA_DIR — %LOCALAPPDATA%\VoxRox\Mail\crypto.bin (dev runs: Mail.dev). The ${user.home}/.voxrox/mail path in application.properties is only the fallback for standalone runs that set no APP_DATA_DIR (mvn spring-boot:run). Use the explicit env crypto override only outside the regular desktop flow.

For a browser-only dev run (MSW mocks, no backend):

cd frontend
npm run dev -- --mode e2e

A bare npm run dev does not start in a plain browser: finding the backend goes through Tauri's file-system API.

Documentation

Every doc is one of three kinds: living (kept current; the security-relevant ones carry a version header + change log), snapshot (a dated record that is no longer updated — marked with a banner in the file), or worksheet (filled in per release candidate). Unmarked entries below are living.

Module-level entry points:

• backend/README.md — backend stack, quick start, operations TOC
• frontend/README.md — frontend stack, scripts, tests
• frontend/END_USER_README.md — release notes for end users (Czech)

Operations and release:

• docs/RELEASE_PROCESS.md — the ordered mechanics of cutting a release (version, tag, notes, draft to public, publish decision); opens with the map of what the neighbouring release docs own
• backend/OPERATIONS.md — operations runbook (data directory, logs, recovery, release channels)
• backend/RELEASE_CHECKLIST.md — release checklist + per-candidate smoke worksheet appendix (worksheet)
• backend/PERFORMANCE_BASELINE.md — dated cold-start measurements and what each was measured on
• frontend/docs/WINDOWS_SIGNING.md — Windows code signing + Tauri updater setup
• CODE_SIGNING_POLICY.md — what a signed release covers and who approves signing; not in effect until SignPath Foundation accepts the project

Contributing and security:

• CONTRIBUTING.md — contributor guide: local setup, quality gates, commit conventions
• CLAUDE.md — the same repo conventions written for a coding agent: what the gates exist to catch, and the traps that are not visible in the code
• SECURITY.md — security policy: supported versions, how to report vulnerabilities
• SECURITY_THREAT_MODEL.md — security threat model (single source for boundaries, STRIDE, accepted risks)
• docs/AUDIT_GUIDE.md — how subsystem security audits are produced; includes the map of the six per-boundary audit docs in docs/
• backend/SECURITY_RELEASE_CHECK.md — pre-release security gate: audit verdict index + cross-cutting checks (secret scan, log hygiene, dependency audits)

Engineering records:

• docs/STATIC_ANALYSIS.md — static-analysis policy, backend + frontend
• backend/docs/CONCURRENCY.md — shared-mutable-state inventory and locking rules
• backend/docs/THREADING_DESIGN.md — threading/conversations design rationale (snapshot)
• backend/docs/OPENAPI_AUDIT.md — OpenAPI surface audit, 2026-06-01 (snapshot)
• docs/COMPOSE_DRAFT_LIFECYCLE.md — compose/draft lifecycle redesign record (snapshot)

History:

• CHANGELOG.md — release-level history of the entire monorepo
• backend/CHANGELOG.md — backend technical changes and migration notes

Legal / compliance:

• PRIVACY.md / PRIVACY.en.md — privacy policy (draft; published at voxrox.org/privacy)
• backend/THIRD_PARTY_LICENSES.md — Maven third-party license inventory
• frontend/THIRD_PARTY_LICENSES.md — npm third-party license inventory
• frontend/src-tauri/THIRD_PARTY_LICENSES.md — Cargo + bundled OpenJDK license inventory

Live task tracking:

• todo.md — current open work (release gate items, audit follow-ups, manual smoke checklist)
• todo-archive.md — closed work, kept for the detail behind a one-line entry in todo.md (snapshot)

License

MIT — see LICENSE.