Simprint: a local-first desktop workspace for browser profiles and proxies

A workspace, not a script: what the desktop application actually holds

Simprint describes itself as a local-first desktop workspace for browser-driven operations, designed to organize browser profiles, proxy resources, automation flows and local runtime capabilities in one place. That phrase carries the design.

The unit is not a script and not a browser instance. It is an environment: a persistent browser profile with its own state and its own operational boundary, kept alive across sessions along with its account context and workspace state. The project says this is for individuals and teams that maintain multiple browser work environments over time, and it names the scenarios: cross-border operations, account management, automated task execution and shared resource coordination.

The stack is stated in the badges and repeated in the tree. The desktop shell is Tauri 2, the interface is React 19, and the runtime is Rust 2024. The primary language recorded for the repository is TypeScript, which covers the front end, and the Rust half lives in src-tauri/. So the shape is a web interface inside a native shell, with the native side owning the browser process and the system-level services.

Two supporting artifacts in the tree explain the architecture further. There is a syncer.html at the root next to index.html, which is the page for the syncer feature, and there is a slotkit.config.ts plus a plugins/ directory and a src/ directory, which is a workspace layout where features can live outside the main app source. The build scripts all begin with slotkit generate-imports, so the tool generates the module wiring before anything is compiled.

The feature list separates the environment from the things attached to it

The features are worth reading as a set of separable pieces rather than a list of features, because that is how the product is organised.

Isolated browser environments run multiple workspaces with separated state and operational boundaries. Persistent browser profiles keep long-lived profiles, account context and workspace state organised over time, which is the feature that distinguishes this from a fresh browser launch per task.

Proxy orchestration connects, assigns and manages proxy resources across environments and workflow scenarios. So a proxy is a first-class resource that can be attached to an environment, not a setting buried in a profile.

Fingerprint configuration controls environment-level browser characteristics, and the wording is careful: the project says it continues refining fingerprint-related behaviour, which is an honest admission that this is a research area rather than a solved one.

Then the local automation runtime, for building repeatable browser workflows for daily operations, and the Chromium-based desktop runtime that runs the workspace through a local Chromium-oriented Tauri and Rust stack with integrated frontend and system-level services.

The last three entries are the ones that make it a platform rather than a profile manager. The syncer coordinates multiple running environments, chooses a master session and mirrors interaction flows across selected windows. The RPC bridge is the built-in Tauri command bridge between the React front end and the Rust services. The local API exposes workspace resources such as environments, proxies, tags, groups and browser kernels through a local runtime API. And the MCP service runs a local Model Context Protocol service so external AI clients can connect to Simprint-managed tools and workspace resources.

That MCP entry is the one to notice. It means the resource model is meant to be driven by something other than the desktop UI, which is the difference between a workspace you click through and a workspace you can script.

Running it needs four prerequisites and no services of your own

The prerequisites are listed as Node.js 20, pnpm 9, a Rust toolchain and the Tauri system prerequisites for your platform. That is a normal Tauri development stack and nothing exotic.

The local run is two commands:

pnpm install --frozen-lockfile
cargo tauri dev

The first installs the JavaScript side from the committed pnpm-lock.yaml, and the second starts the desktop application in development mode. The frozen lockfile flag matters in a project with a committed lockfile, since it makes the install fail rather than silently updating the lock.

The sentence that follows is the local-first claim stated in its strongest form: starting the desktop application does not require any separately configured or running services. There is no server to stand up, no account to create, no database to provision before you can see the application. That is the concrete difference from a cloud-hosted product in the same category, and it is what makes the project usable for local research on browser environments.

The package scripts show the rest of the development loop. The front end is built by Vite in three modes, with the slotkit generate-imports step running first in each:

    "dev": "slotkit generate-imports && slotkit dev",
    "build:development": "slotkit generate-imports && vite build --mode development",
    "build:production": "slotkit generate-imports && vite build --mode production",
    "build:test": "slotkit generate-imports && vite build --mode test",
    "lint": "eslint .",
    "lint:fix": "eslint . --fix",
    "rust:fmt": "cd src-tauri && cargo fmt",
    "rust:clippy": "cd src-tauri && cargo clippy",
    "rust:check": "cd src-tauri && cargo check"

The Rust side has its own set of checks, all run from src-tauri, with rust:fmt, rust:clippy and rust:check in the same manifest.

The deployment scripts are also in the package manifest, with node deploy/prepare-version.mjs for version preparation and node deploy/build.mjs for the build, plus two bundle targets that produce an embed bootstrapper and a fixed runtime. Those two bundle names are a good clue to the shape of the release: the application is not a single binary but a set of pieces, including a runtime that gets carried around.

Local-first storage, and the network calls that remain

The data use section is short and specific. Simprint stores its core business data on the user's device by default, and the introduction repeats it: core business data is stored on the local machine by default, and normal desktop use and development can be completed locally.

Then the caveat, and it is the right one to notice. Features that require network access, and the list is given, still connect to the relevant third-party services: browser-kernel downloads, application updates, proxies and external websites.

That sentence does a lot of work. A browser workspace that downloads its own browser kernels is reaching out at first run even though your data never leaves. Proxies are inherently network resources. The websites you open are, of course, network resources. So the local-first property is about where your business data lives and where the workflows are defined, not about whether the machine ever talks to anything.

For the audience the project describes, that is the right boundary. The expensive and sensitive thing in a browser workspace is the set of accounts and their state, and that stays on disk. A kernel download is not sensitive.

The other part of the local-first claim is the roadmap entry, local-first hardening, which lists improving local data migration, backup and restore, and offline behaviour. That is worth reading as an admission: local-first is a direction, and the migration, backup and restore paths are still work in progress rather than finished features.

From a hosted product to an open-source desktop application

The status section explains why the project looks the way it does. Simprint was originally developed as a hosted commercial product and has since moved to a local-first open-source desktop architecture. The open-source edition is intended to provide all core functionality without feature gating.

That last clause is the one to hold on to, because it is a promise about the future rather than a description of the present. The very next sentence qualifies it: some billing-related UI, upgrade prompts or commercial entry points remain from the earlier architecture and will continue to be cleaned up over time.

So the codebase still contains the shape of the commercial product it was, minus the feature gating. A user may encounter an upgrade prompt or a billing entry point in an application that is otherwise free and local. That is a transitional state rather than a defect, and the project is explicit that the cleanup is ongoing.

The other half of the status is a call for help. The project is in an active open-source transition and is looking for early contributors and future maintainers, with CONTRIBUTING.md covering development setup, contribution workflow and pull request expectations. The named high-value areas are bug reports with reproducible steps and environment details, build, packaging and CI improvements, documentation, onboarding and local development experience, front end UX polish and workflow consistency, and tests, regression coverage and release verification. A request to open an issue and introduce yourself for longer term contribution is the explicit path for anyone interested in maintaining it.

For an adopter, that phrasing is a signal about the project's stage. It is looking for maintainers, which means the bus factor is currently small and the author is signalling that.

Where Simprint is the wrong tool, and what the AGPL means

The first limit is that it is a desktop workspace rather than a library. If what you want is a scriptable browser, there are libraries for that, and a Tauri application with its own environment model is a heavier thing to drive from a CI job. The automation runtime inside Simprint is aimed at workflows run from the desktop application, and the MCP service is the intended route for external control rather than the local API.

The second limit is that the fingerprint work is unfinished by the project's own description. It says fingerprint configuration is continued and refined, and the roadmap has fingerprint research as its own line covering environment controls, compatibility and research depth. So the behaviour of the environment characteristics is a moving target, and anything you measure against one build may not hold on the next.

The third is the transition state described above. Billing-related UI and upgrade prompts from the earlier architecture are still present, so the interface is not yet clean, and the roadmap entry for local-first hardening tells you that data migration, backup and restore and offline behaviour are still being worked on. A team with existing browser environments that must be preserved across versions should read that roadmap line carefully before migrating data in.

The licence is the fourth and the sharpest. The project is under the GNU Affero General Public License v3.0. For a tool you run locally on your own machine, AGPL obligations are largely not engaged, because the network clause applies to conveying the software to remote users over a network. But the readme itself flags the point that matters for organisations: if you want to use Simprint in a way that does not comply with the AGPLv3 obligations, including distributing modified versions or providing a service based on it, you need to look elsewhere. That sentence in the project documentation is the place to start, and it is a licence review question for your legal team rather than something this article can answer.

The fifth is the platform commitment. The application is a Tauri 2 desktop app for macOS, Windows and Linux through the Tauri system prerequisites, and the browser runtime is Chromium-based. A team that needs a headless, server-side browser fleet has picked the wrong shape of tool.

Editorial conclusion

Simprint is worth evaluating for a team that has outgrown a folder of browser profiles and a shell script of proxy settings, because it puts environments, proxies, tags and groups behind one desktop entry point with a local runtime, and because the MCP service lets an AI client drive workspace resources without going through the UI. It is the wrong tool if you need a single scriptable browser, since it is a desktop workspace rather than a library, and the wrong tool if you cannot accept AGPL-3.0. Before you build on it, check the three things the project states: that starting the desktop application does not require any separately configured or running services, which is the local-first claim in its strongest form; that core business data is stored on the local machine by default while browser-kernel downloads, application updates, proxies and external websites still reach third-party services; and that some billing-related UI, upgrade prompts and commercial entry points from the earlier hosted architecture remain and are still being cleaned up.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. Simprint/simprint on GitHub