Technical Comparison

A factual comparison of Vigo against five established configuration management systems — Puppet, CFEngine, Chef, Ansible, and SaltStack — covering capacity, architecture, performance and scale, security, configuration expressiveness, idempotency, and operational characteristics.

Where capacity and performance are compared, all tools are evaluated against the same reference hardware — the box Vigo was load-tested on: an 8 vCPU / 32 GB server (GCP, off-box load). Capacity is compared at a common check-in cadence rather than each tool's default, so the numbers are apples-to-apples — the capacity matrix below shows every tool at 1s, 5s, and 5m side by side. Vigo's ceiling is cadence-dependent — CPU-bound at a 1-second cadence, memory-bound at a relaxed one — and it is the only system here that sustains a 1-second cadence at all; the competitor figures are scaled from each vendor's documented requirements onto the same box, cited where available.

On Vigo's numbers. Vigo has no production deployment, but the server has now been load-tested end to end, off-box on GCP, on an 8 vCPU / 32 GB host. Every Vigo figure below is one of: (a) a Go microbenchmark from the codebase (go test -bench), (b) a value read directly out of the source (unsafe.Sizeof, registry counts, binary size on disk), (c) a result from that load test, or (d) a single ad-hoc observation from the developer's home-lab fleet — labelled as such. The single-host ceiling has two limits, and which binds depends on the check-in cadence: at a 1-second cadence the server is CPU-bound (~7,450 envoys on 8 vCPU — the per-check-in signature-verify and processing work), and at a relaxed 30–60-second cadence it is memory-bound (~30,000 envoys safe on a 32 GB host, ~45,000 the OOM wall) at ~623 KB of all-in live heap per envoy. The full matrix and methodology are in the sizing analysis. Read the comparison as architecture-and-cost; the capacity figures are measured, not a production guarantee.

Capacity on the test rig (8 vCPU / 32 GB server)

Sustainable node count at three check-in cadences on the same box. Vigo rises with the cadence, then plateaus on RAM — at 1s the per-check-in CPU binds (~7,450), and by 5s it has reached the held-connection memory ceiling (~30,000 on 32 GB), where it stays however much slower it then runs. Every other tool does per-node server work — catalog compile, state render, report ingest — on each check-in, so its capacity falls steeply as the cadence tightens, and at 1s the poll-compile designs are far below the cadence they were built for.

Reading the table. Vigo is the only system that sustains a 1-second cadence at all — at that cadence every poll-compile tool is hundreds to thousands of times smaller, because each recompiles a catalog (Puppet) or re-renders/re-ingests state (Chef, Salt, CFEngine) on every check-in, work those servers were built to do every 30 minutes, not every second. The 5-minute column is the closest to common ground, but even there it holds Puppet and Chef to 6× their 30-minute default — at their native 30-minute cadence on this box they do more (Puppet ~500, Chef ~10,000); the cells show the strict common-cadence figures, scaled from each vendor's documented requirements (sources in Vendor-documented requirements below). Vigo's own column rises from ~7,450 at 1s and plateaus at ~30,000 once the cadence relaxes past ~5s, because held-connection memory — not request rate — then sets the ceiling. The poll-compile competitors are CPU- or ingest-bound on this box well before RAM matters; Vigo converts RAM into node capacity and cores into cadence headroom.

The rest of this document is why: the architecture that produces that number, the per-check-in mechanics behind it, and how Vigo stacks up on the other axes that matter.

Architecture at a Glance

That capacity gap is architectural — it falls out of how each system is built. At a glance:

The pattern that drives the capacity table: Vigo keeps fleet state in process (Go, SQLite) and does almost nothing per check-in, while the pull-compile tools (Puppet, Chef, Salt) do per-node server work — catalog compilation, state rendering — on every run. The next section is that mechanism in detail.

Performance and Scalability

The capacity figures trace to one thing: what each system does on every check-in.

Check-in hot path

Vigo's check-in path is designed for zero database operations. The FleetIndex (in-memory envoy index) provides O(1) lookups. Config matching is pre-computed at load time. The only I/O on the check-in path is the gRPC round-trip itself.

Puppet's agent check-in triggers catalog compilation on the server — the Puppet master evaluates the node's manifest, resolves Hiera data, compiles a resource graph, and serializes it. This involves Ruby interpretation, PuppetDB queries, and potentially Hiera backend lookups. At scale, compile masters are needed.

Chef's check-in downloads cookbooks and converges locally — the server load is lighter (just serving cookbook files), but the client does significant work resolving recipes.

Salt's check-in is lightweight (ZeroMQ message) but state compilation happens on the master.

CFEngine's agent evaluates promises locally from cached policy — the server interaction is minimal (just policy distribution).

Verdict: Vigo and CFEngine have the lightest agent-side check-in paths. Puppet's is the heaviest. On the server side, Vigo holds fleet state in process — the fixed EnvoyState struct is 416 bytes (unsafe.Sizeof, server/fleet/index.go), though the resident cost per envoy is dominated by the per-envoy trait map (Traits map[string]string — dozens to low-hundreds of keys on a typical host) and the bounded recent-run history, so the real figure is materially larger and fleet-dependent. By contrast, CFEngine Enterprise's reporting hub documents ~8 MB per node in PostgreSQL. Vigo's measured single-host ceiling is cadence-dependent — CPU-bound at a 1-second cadence (~7,450 on 8 vCPU), memory-bound at a relaxed cadence (~30,000 on a 32 GB box at ~623 KB of all-in heap per envoy); see the capacity table above.

Check-in characteristics

The check-in path is cheap — its dominant cost is the ~53 µs ED25519 verify, with everything else on the cache-hit path under a microsecond — which is what makes sub-minute intervals plausible at all, and why Vigo's "practical minimum interval" is the only sub-minute entry in the table. The sizing analysis works through the measured CPU, memory, and network at a 1-second check-in interval — the most demanding cadence — row by row; at that cadence the binding limit is CPU, and only as the cadence relaxes past ~4–6s does RAM bind first.

Vendor-documented requirements

These are the figures the capacity matrix is scaled from. Note that the poll-compile competitors (Puppet, Salt, and CFEngine's Enterprise hub) are CPU- or report-ingest-bound on this box well before RAM matters, so their extra RAM goes unused — the opposite of Vigo, which converts RAM directly into node capacity and cores into cadence headroom.

Server memory per node

Agent resource consumption

¹ Single observed sample from a long-running home-lab envoy (agent_self.rss_bytes); not yet characterized across operating systems, uptimes, or policy weights — treat as indicative, not a spec. The static binary is ~8 MiB on disk.

Vigo is close to CFEngine for resource consumption and well under the Ruby/Python-based tools (Puppet, Chef, Salt). This matters for edge computing, IoT, containers, and cost-conscious cloud deployments.

Offline operation

Vigo's offline convergence is the most complete — signed policy bundles with TTL, local trait evaluation, results queuing, and automatic drain on reconnect. CFEngine's autonomous operation is philosophically similar but lacks the results queue.

Scaling architecture

Past a single host's safe ceiling, Vigo federates with spanner — peer-equal bolts, each holding its own slice of the fleet — rather than the compile-master / replication tiers the pull-compile tools reach for.

Transport and Security

Authentication model

Vigo uses three-layer authentication: mTLS for the transport, ED25519 signature verification on every agent payload (timestamp + body signed with agent's private key, verified against stored public key), and one-time bcrypt-hashed enrollment tokens. This means even if TLS is somehow compromised, an attacker can't forge agent requests without the private key.

Puppet uses HTTPS with client certificates — solid but single-layer. No per-request payload signing. Chef uses HTTPS with API tokens (RSA-signed requests) — similar to Vigo but with RSA instead of ED25519. Salt uses AES-encrypted ZeroMQ with a shared master key — any agent that has the master key can impersonate any other agent. Ansible uses SSH — strong authentication but requires key distribution.

CFEngine uses its own TLS implementation with host key verification. Similar trust model to Puppet but without a standard PKI.

Verdict: Vigo and Chef have the strongest per-request authentication. Salt's shared-key model is the weakest for multi-tenant environments.

Secrets management

Vigo's approach is the cleanest architecturally — secrets are never stored alongside config, never touch the database, and the resolution is a first-class server-side operation rather than an encryption layer bolted onto the config format.

Configuration Expressiveness

Config language comparison

Vigo intentionally keeps content:/attribute templates interpolation-only — no control flow in a config file's body — to prevent the "templates in filenames and commands, {{ if }} in every config" anti-pattern that plagues Ansible and Salt deployments. Per-instance shaping is a when:-gated companion resource or a narrower fleet: query. This is a readability trade-off — less flexible, but configs are auditable without evaluating expressions and modlint can statically validate a whole stockpile.

Composition model

Vigo's six-layer composition — directory inheritance (common.vgo) → glob matching → roles with includes: → modules (with ordering, and module-level foreach:) → resource tools (foreach:/case:/conditional_block:/when:/fleet:) → templates — covers most real-world cases without a programming language. See Composition Patterns for detailed examples.

Puppet's class/defined-type system is still more expressive for deep abstraction — unlimited class composition vs. Vigo's single-level role includes:, typed parameters vs. Vigo's untyped vars:/.Each items, and arbitrary logic inside a defined-type body vs. Vigo's {{ .Each.x }} interpolation + when:-gated resources. But the core "instantiate a parameterized resource group N times" pattern that Puppet defined types and Chef custom resources are built on is now a Vigo primitive too: a module referenced with foreach: ({name: vhost, foreach: vhosts, key: server_name} → vhost[www.example.com], …). Vigo's module system is simpler; the remaining gap is depth, not the abstraction itself.

Ansible's role system is the closest analog to Vigo's roles, but Ansible roles can include tasks, handlers, files, templates, defaults, vars, and meta — a more complex structure. Vigo's roles are just named module lists.

Verdict: Puppet and Chef win on raw expressiveness. Vigo and Ansible/Salt win on accessibility. CFEngine's promise DSL is powerful but has the steepest learning curve.

Idempotency and Resource Model

All six tools enforce idempotency — check current state, act only if drift is detected. The differences are in depth and frequency.

Vigo's idempotency is enforced continuously, not just applied once at deploy time. Every resource executor follows a strict check → act → verify cycle on every convergence pass, and the agent runs a full pass every check-in interval. At 15-second intervals, this means drift from manual changes, package upgrades, cron jobs, or external automation is detected and corrected within seconds — not minutes or hours. This is what makes Vigo a continuous enforcement engine rather than a configuration deployment tool.

Resource type coverage

Vigo registers 68 built-in resource types (agent/src/runner/mod.rs::build_executors, excluding the test-only mock) plus a user-supplied custom executor for 69 total, counting platform variants (reboot vs reboot_windows, etc.) once each as the operator writes them. Puppet has the deepest built-in resource coverage. Ansible has the widest (cloud, network, containers) through its module ecosystem. Vigo's custom executor JSON protocol allows extending coverage without modifying the agent binary.

Package management depth

Puppet's package resource is a benchmark — it supports 20+ providers (apt, yum, dnf, brew, chocolatey, pip, gem, npm, etc.), version pinning, holding, purging, install options, and source packages. Vigo's package executor handles 14 package managers — apt, dnf, yum, zypper, pacman, apk, brew, pkg, pkg_add, pkgin, IPS, Chocolatey, winget, and Scoop — with install/remove, exact version pinning, and allow_downgrade for safe version changes. Setting version: "1.4.9-1" ensures that exact version is installed on every convergence — if the package drifts (manual upgrade, apt upgrade), the agent corrects it within the next check-in interval. This is functionally equivalent to apt-mark hold for CM-managed systems, since the agent continuously enforces the desired version. The remaining gaps are source package installs and the long tail of provider-specific flags (e.g., --enablerepo, install_options).

Operational Characteristics

Bootstrap and enrollment

Vigo and CFEngine have the fastest bootstrap. Puppet's certificate signing workflow is the most involved.

Observability

The open-source versions of Puppet, Chef, Salt, and CFEngine have limited or no web UI — their dashboards are part of the commercial/enterprise products. Vigo's web UI, compliance tracking, and admin section are included in the base product.

When to Choose Vigo

• Free for up to 100 nodes — all features, no time limit, no credit card
• When you value simplicity — YAML configs anyone can read, one server, one binary, one publish command. No DSL to learn — not true of Puppet manifests, Chef recipes, or CFEngine promises
• When you value security — mTLS everywhere, ED25519 per-request signing on every payload (uncommon among CM tools — Chef signs requests with RSA; Puppet and the others rely on transport-level certificates only), and a first-class secret: resolver that never lets secrets touch config files, databases, logs, or wire payloads
• When you value ease of operation — single process, embedded SQLite, bootstrap in 30 seconds with a single curl command. No package manager, no runtime dependencies, no external database
• When you value performance — the per-check-in path's dominant cost is a ~53 µs ED25519 verify (benchmarked); everything else on the cache-hit path totals under a microsecond; zero database queries on the hot path (the state write is batched and asynchronous). The server was load-tested end to end on an 8 vCPU / 32 GB host; the single-host ceiling depends on cadence — CPU-bound at a 1-second cadence (~7,450 on 8 vCPU), memory-bound at a relaxed one (~30,000 on a 32 GB host, ~623 KB all-in per envoy) — see the sizing analysis
• When you need continuous enforcement — every resource is idempotent and re-evaluated every check-in. At 15-second intervals, drift is corrected before anyone notices it happened. This enables provable continuous compliance, self-healing infrastructure, and sub-minute incident response — capabilities that require 5-30 minute intervals with any other tool
• When you need scalability — no compile masters, no database clusters, no worker pools; the spanner hub-spoke topology adds horizontal scale on top. (Single-host ceiling measured on an 8 vCPU / 32 GB host: ~7,450 envoys at a 1-second cadence (CPU-bound), ~30,000 at a relaxed 30–60s cadence (memory-bound); scales ~linearly with cores and RAM.)
• When agent footprint matters — ~8 MiB static musl binary (x86_64; ~6 MiB on arm64) vs 50–200 MB for Ruby/Python-based agents. Deploys anywhere — edge, IoT, containers, resource-constrained hosts
• When you need offline resilience — signed policy bundles with local convergence and results queuing for air-gapped, shipboard, or unreliable network environments. Most complete offline story of any agent-based CM tool