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 managed engine stages files atomically in a private configuration directory, then loads the staged ventstream.yaml and starts the pipeline. 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 restart, the pipeline remains stopped until the engine’s fleet client has acquired a current 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. VentStream Cloud validates and distributes configuration without becoming a credential vault or data-plane dependency. Redis sink revisions use the same boundary:
VentStream Cloud 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 engine 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:
VentStream Cloud validates the topology shape before activation. The engine resolves the references in the workload 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. VentStream Cloud 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.