Plan your data planes

Most Hybrid customers run two data planes: one serving the dev data tag for Edit and Preview, one serving production for Production. Decide whether that fits you before you deploy anything.

​

Environments and data tags

Every Superblocks application moves through three built-in environments: Environments are fixed. Data tags control which data each one can reach. A data tag names a segment of your data; admins create tags on the Environments page and choose which environments each tag is allowed in. Your account starts with Development (key dev) and Production (key production). A data tag is attached to two things:

1. Integration configurations. Each integration can have several configurations (different hosts, credentials, or databases), each linked to one or more data tags.
2. Data planes. Each data plane advertises the data tags it serves through its agent tags setting.

When an app runs an API, its environment determines the active data tag. That tag selects both the integration configuration that supplies the credentials and the data plane that executes the code.

​

How data planes match data tags

The agent tags setting is a comma-separated list of profile:<key> entries:

• profile:production serves one data tag.
• profile:dev,profile:staging serves two.
• profile:* serves every data tag. It is the default and fine for a first test deployment, but it gives you none of the separation described below and stops working when you enable Superblocks Database.

Two rules follow:

• Every data tag you use must be served by a data plane. Hybrid requests never fall back to Superblocks Cloud. If no active data plane serves the active tag, the API fails with Unable to connect to on-premise agent(s).
• Replicas are not separate data planes. Three instances behind one load balancer are one data plane with one set of agent tags; that is how you scale. Add a data plane only when you need a different network, account, or set of data tags.

​

The recommended setup

This puts a hard boundary between the data builders and Clark touch while building and the data your published apps touch. For each integration, then decide:

• The data source has a pre-production instance (a staging database, a sandbox tenant of an internal API): create one configuration for dev that points at it and one for production.
• The data source has no pre-production instance (most SaaS tools, data warehouses): one configuration linked to both tags is enough.

​

Sharing a third-party configuration between dev and production

Integration configurations are stored in the control plane, not on a data plane, so a configuration linked to both dev and production is delivered to whichever data plane runs the request. Both data planes reach Salesforce, Jira, or any other SaaS over outbound HTTPS; nothing crosses the account boundary. A shared configuration is the deliberate exception to “test data never reaches production,” so the decision is what builders and Clark can do to that system from Edit and Preview. Three options, from simplest to most isolated: The data plane split is the same in every case. Only the credentials attached to each tag differ.

​

Next steps