This blueprint covers the non-production, single-host deployment used for labs, proofs of concept (PoCs), and low-risk development or testing. In this architecture, there is no network separation between management and processing. Data is ingested, transformed, and routed by the same instance that hosts the configuration UI.

Use this layout when:

• You need a quick, disposable environment to validate features or Pipelines.
• You are running personal labs, workshops, demos, or short-lived PoCs.
• Occasional downtime and data loss are acceptable trade-offs for maximum simplicity.

Do not use this scenario for any environment that requires high availability (HA), durability, or realistic scaling validation–move to a Distributed topology for that.

CVA Baseline Topology

​

Use the Single-Instance Topology (Leader + Worker/Edge collapsed into a single process on one Node).

A single host runs:

• Leader functions (UI, API, configuration, orchestration).
• Worker/Edge Nodes (data ingestion, processing, routing, delivery).

There are no Worker Groups/Fleets, no horizontal scaling unit, and no separation of roles.

Network and Data Flow

​

• All Sources (push and pull) and all Destinations are configured on the same instance.
• Data goes directly from Source → Pipelines → Destinations within a single process.

Overlays

​

Overlays are not applicable for the single-instance toplogy. You can use this scenario as a lightweight staging point before you promote configurations into a Distributed topology where overlays may apply.

Guardrails

​

These guardrails are specific to Single-Instance Testing and are intentionally strict, to prevent this topology from being misused as a “small production” deployment.

To keep this environment functional and avoid “cascading failures” where a processing spike locks you out of the management UI, follow these limits:

• Non-production only: Never use a single-instance for production data. It lacks HA; if the instance goes down, your data flow stops completely.
• Throughput ceiling: Do not exceed 250 GB/day. Higher volumes can starve the Leader process of CPU, making the UI unresponsive.
• No high availability: This architecture has a single point of failure. Do not configure Leader HA for a single instance.
• Resource contention: If the Worker process hits 100% CPU, you may lose access to the UI. Always leave at least 2 vCPUs unassigned in the Worker settings to ensure the Leader remains accessible.