Skip to main content
VentStream Cloud stores non-secret engine configuration as immutable, content-addressed revisions. A revision must pass validation before it can be selected. Selecting a valid revision makes it the activation target and queues delivery to enrolled deployments.
The agent stages files atomically in a private configuration directory and starts the engine with VS_ENGINE_CONFIG pointing at the generated ventstream.yaml. For a new pipeline, the first selection creates its initial desired state as paused; an explicit resume performs the first start. Later selections preserve the pipeline’s current run state. After a supervisor restart, the engine remains stopped until the supervisor has acquired a current Fleet control session and converged the deployment. Persisted desired state is retained, but it is not treated as fresh permission to start before admission. An engine that is already running can continue during a temporary control-plane outage, so transient management downtime does not interrupt the data path. Use apply only to deliver the selected revision again, for example after replacing a deployment:
Roll back by activating a previously valid immutable revision:

​
Secret boundary

Configuration documents contain references such as env:VS_OS_ENDPOINT, not credential values. Inject database passwords, API keys, client certificates, TLS private keys, and other secrets through Kubernetes Secrets or the customer’s secret manager. Fleet validates and distributes configuration without becoming a credential vault or data-plane dependency. Redis sink revisions use the same boundary:
Fleet stores the references, TLS file paths, and key-routing policy. The deployment provides the endpoint, credentials, and mounted trust material to the managed engine. The agent supplies VS_FLEET_DEPLOYMENT_ID, which is the default Redis writer identity; a managed revision does not need to duplicate that value in YAML. For Sentinel or Cluster, replace endpoint_ref with an explicit topology. The revision still contains references rather than endpoint values or credentials:
Fleet validates the topology shape before activation. The engine resolves the references in the agent environment, verifies the discovered primary or Cluster slot map, and blocks startup when the runtime topology does not match the revision. See the Redis sink guide for Cluster routing and Sentinel TLS requirements. Normal restarts retain the same deployment identity. During a replacement that must take ownership before the prior writer’s lease expires, stop or drain the old deployment and set writer.takeover_from_ref to a secret-provider or environment reference containing its deployment ID. Redis changes ownership only when that expected identity matches the active lease. Otherwise the new writer remains backpressured. Most replacements can omit this setting and wait for the 30-second default lease to expire. Use ownership: exclusive only when the pipeline is the sole writer for its routed targets. Fleet and the engine reject destructive Redis drain or rebootstrap operations under shared ownership. Exclusive rebuilds also require snapshot bootstrap and a finite target set; validation completes before any source cursor or Redis key is removed. Public CA certificates are trust material rather than credentials. For Amazon RDS PostgreSQL and MySQL, select the bundle already packaged with the engine:
No CA file needs to be uploaded or mounted for that provider. Use ca_file only for a private or self-managed CA. See Database TLS and trust. Validation occurs at multiple boundaries: control-plane schema and policy checks, agent bundle integrity checks, and engine-native semantic parsing before startup.