UnENVerse Find a guide: importing, command line, nodes

UnENVerse architecture

One encrypted vault, one Rust engine, three front ends. This page names the parts, shows how a request moves through them, and explains where Rust ends and TypeScript begins.

The shape of it

UnENVerse layers Three front ends, the desktop app with its TypeScript interface, the unv command line and unv-server, all call the unv-app engine, which calls vault-core, which reads and writes the SQLCipher vault file. Node agents on other machines talk to unv-server. Desktop appTauri shell + TypeScript UI unvcommand line, node agent unv-serverHTTP/TLS API, node hub unv-appevery operation, written once: refs, permissions, Access::save vault-corestorage, crypto, permissions, history, audit chain, nodes vault.db + vault.saltSQLCipher, Argon2id key
Every front end calls the same engine. There is no second copy of a rule in JavaScript.

The Rust workspace

Five crates make up the product. The workspace denies warnings for its own crates, and clippy's defect groups run in CI.

CrateRole
vault-coreStorage on SQLCipher, key derivation with Argon2id, cryptography, permissions and roles, the hash-chained audit log, config history, node protocol, importers, the update check.
unv-appThe application layer. Every operation (resolve a reference, render a config, rotate, restore) is written once here and reached by all three front ends. It holds the single write point, Access::save, which also enforces --dry-run.
unv-cliThe unv command line and the node agent. A thin layer over unv-app that adds argument parsing, JSON output and stable exit codes.
unv-serverThe optional server: HTTP and TLS API for teams, sessions and tokens, and the hub that nodes poll.
src-tauri (package unenverse)The desktop shell: Tauri 2 commands that expose unv-app to the interface over IPC.

Where Rust ends and TypeScript begins

  • Rust owns every rule. Encryption, permission checks, reference resolution, rendering and persistence are Rust. A secret value is decrypted in Rust and reaches the interface only when a command asks for it.
  • TypeScript owns the screen. The interface in src/ts is plain TypeScript with no framework: render.ts draws the cards and the sidebar, modals.ts the forms, vault.ts the start-up and event wiring, state.ts the in-memory state and settings, and tools.ts with its siblings the tool panes.
  • Markup is escaped by construction. HTML reaches the page only through an escaping template tag, because vault data is untrusted input.
  • Parity is tested. Where logic has to exist on both sides (the environment-variable name template, for example) one golden fixture is asserted from Rust and from TypeScript, so the two cannot drift.
  • The CLI can do what the app does. Capability parity is a rule, with the few exemptions written down in capabilities.json.

How a request flows

  1. A front end (the desktop window, the CLI or a server route) receives an action.
  2. unv-app resolves ${refs}, checks permissions and takes the single write point.
  3. vault-core reads and writes the SQLCipher database. The key comes from the master password through Argon2id and lives only in memory while the vault is unlocked.
  4. Output goes through a resolver chosen for the purpose: redacting for display, and materialising only for exec, render, --reveal and --out.

The data model, drawn from the source

This diagram is generated from src/ts/types.ts with TsUML2, a TypeScript to UML tool that runs offline. Regenerate it with node scripts/gen-uml.mjs. Open the diagram on its own to zoom in.

UML class diagram of the vault data model: VaultData holds entries and projects; VaultEntry, Project, SecretChunk and ChunkField describe stored secrets and configs; UserInfo, UserClass, PermissionEntry, TokenInfo and AuditRow describe access and audit.
The vault's data model as the interface sees it.

Who acts on the vault

ActorWhat it can do
OwnerEverything: read, write, manage users, back up and restore.
Named userOnly what its class and permission rules allow, on unv-server. Failed logins are rate limited.
API tokenA credential for scripts and AI agents with the same scoped permissions as its user. Output is redacted unless a materialising command is used.
Node agentWatches a config file, reports drift and writes only what its own configuration allows. Requests are signed.
Recovery destinationReceives encrypted recovery packages (a folder, a NAS or SFTP with a pinned host key).
Release pipelineBuilds, signs with Sigstore, attests and publishes release files from a tagged commit.

How it is verified

  • Rust unit, integration and end-to-end tests, with nightly coverage reported to Codecov.
  • Vitest for the interface and Playwright for layout in a real browser.
  • Fuzz targets for the importers and migrators.
  • CodeQL, cargo-deny and OSV for dependencies and code, and an OpenSSF Scorecard.

Read further