See architecture.md for the source-of-truth responsibility split.
This repo has one intended product topology:
panda -> server -> proxy -> datasources
pandais a client.serverowns MCP, HTTP API, sandbox execution, sessions, and search.proxyowns datasource credentials.- sandboxed Python talks to the local server using server-issued runtime tokens.
panda: local CLI that talks toserverover HTTP.server: runs MCP transports, the CLI-facing HTTP API, sandboxes, sessions, and search.proxy: credential boundary for ClickHouse, Prometheus, Loki, and ethnode.modules: datasource integrations, docs, resources, examples, and schema discovery.
Use this for repo development and normal local use.
panda -> localhost:2480 (server container)
server -> http://ethpandaops-panda-proxy:18081
proxy -> datasources
docker compose up -drunsserverandproxy.config.yamlconfigures the server.proxy-config.yamlconfigures datasource credentials.panda initwrites the client config withserver.url.- if the proxy is hosted and auth is enabled, run
panda auth login
Use this when users should execute code locally but access your hosted credential proxy.
panda -> local server
local server -> hosted proxy
hosted proxy -> datasources
- the user runs
serverlocally - the user points
pandaat that local server - the local server points
proxy.urlat the hosted proxy - code still executes on the user’s machine
This is the recommended external-user shape when you do not want to execute code on your own servers.
pandaconfig:server.urlorserver.base_url
serverconfig:server.sandbox_url- sandbox settings
- module config
proxy.url- optional
proxy.auth
proxyconfig:- optional hosted GitHub auth config
- datasource credentials
- proxy auth/rate-limit/audit settings
- there is no client-side
proxy.mode pandadoes not embed the proxypandadoes not run sandboxes itself- if the server is not running,
pandacannot execute or query anything