Skip to content
sigc
Deployment

One binary from research to production

Backtest a strategy with sigc run, then serve the exact same compiler and runtime in production as sigc daemon over nng — no rewrite, no second codebase.

The problem

The classic failure mode: research is written in one language and rewritten in another for production. The rewrite drifts, subtle differences creep in, and the live strategy no longer matches the paper trade that justified it.

How sigc approaches it

  1. 01

    Develop and backtest with sigc run against Polars/Arrow data loaded from parquet, CSV, S3, GCS, or Postgres.

  2. 02

    Promote the identical binary to production as sigc daemon — a long-running process that owns the cache and answers compile/run requests over nng REQ/REP on tcp://127.0.0.1:7240.

  3. 03

    Declare production posture in sigc.yaml: circuit breakers (max drawdown, max position, kill switch), per-minute order rate limits, Prometheus /metrics, structured JSON audit logs, and scheduled jobs.

  4. 04

    Because the runtime is content-addressed, the daemon serves warm results in microseconds and clients retry with exponential backoff when the cache lock is held.

What you get

  • No research-to-production rewrite: the same compiler and runtime execute both.
  • Production safety (circuit breakers, rate limits, kill switch) is configuration in sigc.yaml, not bespoke code.
  • A brokerless architecture — no Redis, no Kafka, no RabbitMQ — with the daemon as the single cache owner.

More use cases