Self-hosting and standalone mode

If you are evaluating Pairlens for a desk, a fund, or any team with a compliance function, this is the page that matters. Four things are usually decisive:

There is no credential custody to review. Pairlens has no server-side store of exchange keys, because keys never leave the machine that uses them. That removes an entire category from your risk register rather than mitigating it.

Nothing has to leave your perimeter. The terminal is designed to run with zero Pairlens infrastructure. Market data goes exchange to workstation; orders go workstation to exchange.

You can remove asset classes at build time. A bank with no mandate to touch memecoins can ship a build in which they do not exist and cannot be added back by a user.

The licence permits internal use of any kind. Pairlens is source-available under the Functional Source License, and every release converts to Apache 2.0 two years after it ships. You can read, audit, patch and build it yourself.

The rest of this page is how each of those works.

What never leaves your machines

Regardless of how you deploy it:

Exchange credentials are stored on each machine, in the OS keychain on desktop or the encrypted credential vault in a browser, and used only to sign requests to the venue. There is no server-side credential store to secure, audit, or breach.

Market data streams directly between each terminal and the exchange. No Pairlens relay sits in the path.

Orders go straight from the machine to the venue over the venue’s own API.

Python strategies execute in the local runtime. Your logic never leaves the machine that runs it.

Standalone mode

The optional App Server (Pairlens Cloud) provides sign-in, cross-device sync, a hosted AI proxy, and the reference feeds no venue publishes about itself: news, the economic and IPO calendars, insider filings, new listings, and the aggregated liquidation clusters the futures risk board draws. None of it is required. Build with VITE_APP_SERVER_URL explicitly empty, or set PAIRLENS_STANDALONE=1 in dev, and the terminal runs with auth off, cloud panels hidden, and all persistence local to the machine. The panes that read those feeds say the build has no server rather than reading as an empty week.

AI features still work in standalone mode: bring your own provider key (Groq, OpenAI, Anthropic, OpenRouter for inference; Tavily or Exa for search) through the AI plugins, and inference calls go directly from the terminal to your chosen provider. See AI providers.

Excluding plugin families

There are two levels of control here, and picking the right one matters.

The trader’s level is the Plugin Store. Every plugin Pairlens ships can be uninstalled from its store page and installed again later straight from the binary. Dropping an asset class is uninstalling its plugins: prediction markets are Pairlens Predictions, Kalshi and Polymarket, and with those three gone there is no prediction surface left in the terminal. Nothing needs a rebuild, and nothing is permanent. See plugins.

The deployment’s level is the build. When the decision is the organization’s rather than the user’s, exclude the family so it is not in the product at all. Not every desk wants every asset class: a bank may have no business showing memecoin surfaces, and a crypto fund has no use for an equities broker. Set VITE_PAIRLENS_DISABLED_FAMILIES at build time to a comma-separated list of family ids and those plugins are never seeded, never installed, never listed in the Plugin Store, and cannot be reinstalled by anyone using that build. A stale ledger row from an earlier build is skipped too, so flipping the switch on an existing install takes effect on the next boot.

VITE_PAIRLENS_DISABLED_FAMILIES=predictions,dex

Two limits are deliberate. Core and Intelligence cannot be excluded, and asking for them logs a warning and is ignored, because the shell does not boot without them. And exclusion applies only to the plugins we ship: a third-party plugin that happens to share a family is never uninstalled by a deployment switch, because it is the user’s, not ours. See plugins.

Your own plugin registry

The plugin registry ships in the same repo (apps/registry). Run a private instance to curate exactly which connectors, AI providers, indicators, and themes your team can install, then point terminals at it with VITE_REGISTRY_URL.

Packages are cryptographically signed and verified against keys you pin, and third-party plugins run sandboxed with an explicit list of network hosts they may reach. A private registry plus a pinned key set is how you get a fixed, reviewed plugin surface across a desk.

Build and distribute internally

Build the desktop app from source (Rust toolchain required) and distribute it through your own channels. Everything needed to audit, reproduce, and patch the build is in the public repository.

Production desktop builds must set VITE_APP_SERVER_URL in the environment of tauri build. A bare production build defaults to standalone, which is either exactly what you want or a surprise, depending on your deployment.

Shared strategies without a shared server

A desk that wants everyone running the same indicators and strategies can ship them as a plugin: export a Python script from the workbench, or package several together, sign with your own key, and serve it from your private registry. Each trader installs it, and each trader’s copy still runs locally against their own credentials.

Build-time environment

Everything that shapes a deployment is set when you build the terminal:

Where to look next

• Security model for the guarantee-by-guarantee breakdown
• How Pairlens works for where each piece of data lives
• Registry for the distribution mechanics