Skip to main content
Self-hosted PMXT runs the open-source pmxt-core server on your machine. The SDK detects the absence of a pmxt_api_key and routes through http://localhost:3847 instead of trade.pmxt.dev. Venue credentials stay on your machine; you talk to venue APIs directly.

When self-hosted is the right call

Pick self-hosted if any of these apply:
  • Sub-100ms latency — local submission removes a network hop. Matters for latency-sensitive arb / market-making.
  • Raw venue credentials — Polymarket L2 API keys, Kalshi RSA, Smarkets session cookies. Hosted mode doesn’t accept these.
  • Regulatory custody — you must be the direct counterparty with no intermediary in the custody path.
  • Venues hosted mode can’t write to yet — hosted writes are Polymarket, Opinion, and Limitless. Self-hosted can use venue-native credentials where the venue exposes writes (Kalshi, Smarkets, Probable, Myriad, Metaculus, etc.); check Feature Support & Compliance for per-venue support.
  • OSS contribution — you’re hacking on pmxt-core itself.

When hosted is still the better choice

Everyone else. Hosted is simpler to deploy (no local process), gives you on-chain custody you control via the timelock, and PMXT’s server never sees a private key. If you’re building a consumer app, a research notebook, or any non-latency-critical service against Polymarket, Opinion, or Limitless, stop here and use hosted.

1. Install pmxt-core

The SDK installs and supervises pmxt-core for you. You don’t run a separate binary; the SDK spawns it as a child process on first use.
That’s it — pmxt-core is bundled.

2. Construct without an API key

Drop the pmxt_api_key argument. The SDK detects the absence and starts the local server.
The first call blocks briefly while the local server warms up; subsequent calls reuse the process.

3. Manage the local server

For lifecycle control (start, stop, restart, status, logs), use the server namespace. See Server Management for the full reference.
Most users never call these — creating an exchange instance auto-starts the server.

4. Per-venue raw credentials

Self-hosted unlocks the full venue-credential surface. Pass credentials directly to the exchange constructor.

Polymarket — EVM private key

Kalshi — RSA key pair

Limitless / Probable / Opinion (self-hosted) — EVM private key

Smarkets — email + password

Baozi — Solana keypair

See Supported Venues for the full credential matrix.
For venues that use a fund-controlling private key (Polymarket, Limitless, Probable, Opinion, Baozi), a practical habit is to keep only the float you’re actively trading in this wallet.

5. Environment overrides

See API Reference / Configuration for the full env-var matrix.

6. Running multiple exchanges

A single pmxt-core process can serve every venue. Construct multiple exchange clients against the same server — they all share the local process.

7. Production deployment

For production self-hosted, the SDK + bundled server is sufficient — there’s no separate daemon to manage. If you want to run pmxt-core as a long-lived process with systemd or similar, see the pmxt-core README for standalone server commands.

What you give up vs hosted

  • Cross-venue search via Router — still works, but requires the hosted pmxt_api_key for the catalog. If you want Router without trading-hosted, construct a separate Router client with the API key alongside your local trading clients. See Hosted trading.
  • Hosted error tree — you’ll get the parent classes (InvalidOrder, InsufficientFunds) but not the hosted leaves. Catching parents keeps your code portable.
  • PreFundedEscrow custody — irrelevant in self-hosted; you custody at the venue.

Next