How do you host a trading strategy?

The hosting question arrives the moment a strategy survives its backtest: the rules need to keep running when your laptop is closed. A useful shorthand is the closed-laptop test — hosting is whatever lets the strategy keep trading its rules after the author shuts the laptop. The realistic options differ on two axes — who maintains the infrastructure, and what record of the strategy's behavior exists afterward.

Self-hosting (a VPS or cloud instance running freqtrade, Lumibot, or custom code) gives full control but makes you the operator: process supervision, data feeds, dependency updates, and monitoring are all yours. Exchange-linked bot platforms and webhook bridges (3Commas-style services, TradingView alerts) remove the server but tie you to exchange API keys and keep the strategy's history as a platform dashboard, not an independently checkable artifact. Quant-platform clouds (QuantConnect-style) host research and execution but center on equities and futures.

Pancake's model is different: the strategy itself — not server code — is the deployable artifact. An agent (Claude or any MCP-capable client) builds the strategy spec, validates it with a verified backtest, and calls create_paper_deployment; Pancake then runs the strategy against live Polymarket data with simulated fills, recording every event in an append-only ledger. There is no server to run and no code to deploy.

The difference that matters for trust: every Pancake strategy version lives at a permanent public URL (/<handle>/<strategy_slug>/v/<version_n>) with its result attached, and a paper deployment accrues a ledger-backed track record a third party can inspect. Live execution against real venues is a v2-roadmap capability; hosted verification and forward testing are how a strategy earns its way there.