Self-hosting and standalone mode

If you are evaluating PS ONE 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. PS ONE 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 PS ONE 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.

Runs entirely on your infrastructure. PS ONE has no dependency on our servers: every part of it runs inside your own network.

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 PS ONE 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 App Server (PS ONE 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. Run it and sign-in is how the terminal opens, since the account is the door. Build with VITE_APP_SERVER_URL explicitly empty, or set PSONE_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, DeepSeek, 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 PS ONE 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 PS ONE 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_PSONE_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_PSONE_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 (Rust toolchain required) and distribute it through your own channels. Everything needed to reproduce and patch the build is available to you.

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 PS ONE works for where each piece of data lives
• Registry for the distribution mechanics