Pattern one: split control plane and data plane

Superblocks documents a Hybrid architecture with its control plane in the Superblocks cloud and a single-tenant data plane inside the customer’s AWS, GCP, or Azure VPC. Its page says production API and data traffic is handled in that data plane through outbound connectivity, while authentication, permissions, the frontend route, AI, and control functions use the Superblocks cloud. It also says the vendor manages data-plane upgrades, reliability, and support.

This can reduce the buyer's platform-operating burden while keeping important data access near private resources. It also means “in our cloud” does not describe every control or request path. Buyers should test control-plane outage, egress restriction, vendor access, and browser behavior rather than infer them.

Pattern two: customer-operated self-hosting

ToolJet’s deployment overview distinguishes cloud and self-hosted options. Its architecture documentation describes a server responsible for authentication, authorization, app definitions, queries, and credentials, backed by PostgreSQL. Its AMI instructions specify database requirements and identify outbound access needed for some AI features.

This pattern can place more of the stack under buyer operation. It also makes database care, updates, capacity, monitoring, recovery, and compatible configuration explicit buyer or contracted-operator work. Do not call it independent until an operator reproduces install, upgrade, restore, and exit.

Freeze the evidence request

Ask every candidate for current evidence across the same criteria:

  1. buyer account and subscription ownership;
  2. builder and control-plane location;
  3. end-user runtime and browser path;
  4. business data, files, platform metadata, and credentials;
  5. identity, roles, and privileged support access;
  6. inbound connections, outbound destinations, telemetry, and AI paths;
  7. release, update, rollback, and supported-version ownership;
  8. logs, monitoring, incident response, backup, and restore;
  9. licensing behavior during vendor or network outage; and
  10. export, deletion, and independent recovery at exit.

For each cell, use one of three labels:

  • documented: a current primary source establishes the boundary;
  • buyer reproduced: a dated test demonstrated the behavior; or
  • unresolved: the available evidence did not establish it.

“Unresolved” is a question, not a negative product score. A documentation page may omit a capability that exists, and a vendor claim may still need a test.

Run an operator acceptance test

In an approved non-production account, ask the intended operator to:

  • deploy the exact licensed edition;
  • enumerate resources and network flows;
  • connect a representative data source using a non-production credential;
  • release and roll back one small application change;
  • deny an expected outbound path and record the failure;
  • inspect identity and support access logs;
  • upgrade through a supported version;
  • restore platform state and representative data; and
  • export the application into the promised exit format.

Record vendor assistance and hidden prerequisites. Success with a vendor engineer on a call is useful evidence, but it is different from independent operation by the buyer's on-call team.

Decide by responsibility fit

A split architecture may fit a buyer that wants private data access without owning the entire platform lifecycle. A fuller self-hosted architecture may fit a buyer with strong platform operations and a need for greater component control. Either can fail when the desired boundary is undocumented or the transferred work has no capable owner.

The decision packet should say exactly where each component runs, who releases and recovers it, which vendor services remain, and what the buyer reproduced. “BYOC: yes” is not enough.