curl -fsSL https://install.vloud.app | bash. That’s the install.
There’s no “and then run the agent.” No “configure the operator.”
No “apply the helm chart.” The whole control panel — security
engine, system guardian, deployment runtime, monitoring, backups —
is one statically-linked binary at /usr/local/bin/vloud.
That hard rule was a deliberate decision. Here’s why.
The cost of agents
Every “host an agent + cloud control plane” model adds:
- A running daemon you have to monitor, update, secure
- A network channel to a vendor’s cloud you have to trust
- A version-mismatch surface between agent and control plane
- An attack vector for anyone who breaks the agent
- A failure mode where the agent dies and the host operates blind
Multiply by the number of services in a typical “modern” platform (scheduler, secrets manager, observability collector, security scanner, backup runner) and you have eight daemons doing what one binary could do.
What we lose
We don’t get the per-tenant isolation that comes from running pieces in separate processes. We don’t get the easy-rolling-restart you get from microservices. We don’t get the “deploy a new feature without restarting” property of modular systems.
We accept those losses in exchange for: predictable RAM footprint (one process), one log to tail, one config file, one audit trail, one signature to verify, one update path. It is dramatically easier to operate.
How it stays maintainable
Internally, Vloud’s binary is composed of independent modules with strict boundaries — they share a process but not state beyond defined APIs. Modules can be enabled or disabled at runtime via config. The Security Engine’s twelve subsystems can be turned on gradually; the deployment runtime is independent of the monitoring stack. We get most of the engineering benefits of microservices without the operational tax.
The alternative we considered
Several team members lobbied hard for an “agent + central server” architecture. The argument was that customers with fleets need a unified view. Counter-argument: customers with fleets can run their own central engine, and use Fleet Guardian’s heartbeat protocol to aggregate, without us forcing it on the single-host customers who make up 90% of installs.
We picked the simpler default. One binary. Per host. Done.