Scaling & availability

Short version: VectorStep runs as a single instance today. This page says plainly what that does and doesn’t mean, rather than leaving it for you to discover in a Kubernetes manifest.

Why single-instance, today

The scheduler (APScheduler, in-process cron) and the dedup/event state that prevents a flapping alert from firing the same pipeline twice both live in memory. A second replica of VectorStep would have its own copy of both — meaning scheduled pipelines fire twice and dedup stops working, not a graceful degradation. This is why the Kubernetes manifests pin replicas: 1 with strategy: Recreate, and it holds regardless of database backend — PostgreSQL doesn’t change it; it only removes SQLite’s additional single-writer constraint on top.

The Gateway is architecturally closer to statelessness — it doesn’t schedule anything — but isn’t validated as multi-replica today either (session/identity handling assumes one instance); treat it the same way for now.

What this doesn’t mean

A crash isn’t the same as data loss. Durability & resume covers what happens when the same instance restarts — a deploy, a crash, an OOM kill: in-flight runs marked durable: true pick back up from the last completed step rather than vanishing. That’s crash-recovery on one instance, not failover to a second one — worth being precise about the difference, since it’s easy to read “durable runs” as “highly available” and they’re answering different questions.

This isn’t a throughput ceiling on what VectorStep can trigger. The orchestrator itself is lightweight — CPU-light, I/O-bound waiting on LLM calls and executor round-trips rather than doing compute-heavy work of its own. For the workload this is built for (webhook- and cron-triggered pipeline runs, not a high-QPS request path), a single instance goes a long way before it’s the bottleneck; the LLM provider’s own rate limits are far more likely to be the actual ceiling.

What we can’t tell you yet

There’s no published throughput number, because there isn’t a trustworthy one yet — no representative load test has been run and publishing a made-up figure would be worse than saying nothing. If capacity planning for a real workload matters to you before that exists, get in touch directly — early conversations here directly shape what gets prioritized.

Roadmap

Horizontal scaling and real HA (moving the scheduler and dedup/event state out of process, so a second replica is additive rather than actively harmful) are on the roadmap, not implemented. No committed date — see Status & support for how VectorStep handles versioning and support commitments generally. If this is a blocker for evaluating VectorStep seriously, say so — it’s useful signal for sequencing.