Cloud & Open Source Types

Hundreds of catalog types for cloud architecture and self-hosted open-source stacks, with containment expressing topology.

Beyond the free Domains types, the DAI Studio catalog publishes two larger collections, each a separate view in the editor’s Types overlay:

• Cloud: 200+ service types across five categories: Generic (provider-neutral), AWS, Azure, Google Cloud, and Cloudflare
• Open Source: 350+ open-source projects across 17 categories, from Debian to PostgreSQL to Kubernetes

Both are one-time, $10 add-ons per account. Until a view is unlocked, its tab shows a 🔒 and an Unlock button that opens checkout, and its types can’t be placed or picked in the type switcher. After you buy, you return to the same document with the view open. Documents that already contain cloud or open-source elements open, render, and edit normally without the add-on; only adding new ones is gated.

How they are written

Cloud and Open Source types follow the same rules as every other type:

• dai:type is a dot path such as dai.types.aws.lambda-function, dai.types.gcp.vpc-network, dai.types.cloudflare.worker, dai.types.cloud.object-storage, or dai.types.oss-database.postgresql. None of them has a dai:stepType.
• Most values are dai:fields (e.g. cidrBlock, runtime, regionCode); dai:notes is an attribute; tags is a dai:properties list.
• Any element becomes a bpmn:subProcess once it has children. Hierarchy and network types (accounts, regions, VPCs, subnets, clusters) are placed as containers by default.

Use containment to express topology: an account contains regions, a region contains networks, a network contains subnets, and a subnet contains the compute running in it.

<bpmn:subProcess id="Acct_prod" name="Production account" dai:type="dai.types.aws.account"
  dai:notes="Workload account for the production checkout stack.">
  <bpmn:extensionElements>
    <dai:fields>
      <dai:field key="accountPurpose">workload</dai:field>
      <dai:field key="environment">production</dai:field>
    </dai:fields>
  </bpmn:extensionElements>

  <bpmn:subProcess id="Region_use1" name="us-east-1" dai:type="dai.types.aws.region">
    <bpmn:extensionElements>
      <dai:fields><dai:field key="regionCode">us-east-1</dai:field></dai:fields>
    </bpmn:extensionElements>

    <bpmn:subProcess id="Vpc_main" name="checkout-vpc" dai:type="dai.types.aws.vpc">
      <bpmn:extensionElements>
        <dai:fields><dai:field key="cidrBlock">10.0.0.0/16</dai:field></dai:fields>
      </bpmn:extensionElements>

      <bpmn:task id="Fn_checkout" name="checkout-handler" dai:type="dai.types.aws.lambda-function"
        dai:trigger="API Gateway HTTP route"
        dai:notes="Validates the cart and creates the payment intent.">
        <bpmn:extensionElements>
          <dai:fields>
            <dai:field key="runtime">nodejs22.x</dai:field>
            <dai:field key="memoryMb">512</dai:field>
          </dai:fields>
        </bpmn:extensionElements>
      </bpmn:task>
    </bpmn:subProcess>
  </bpmn:subProcess>
</bpmn:subProcess>

Cloud

Every cloud category uses the same groups, and each group has the same colour across providers, so an AWS diagram and an Azure diagram read alike:

Use Generic when the provider doesn’t matter or isn’t decided yet: it covers the same concepts (Virtual Machine, Object Storage, Message Queue, Load Balancer…) without vendor naming.

Open Source

Open-source types record what you’d need to run the project: typically version (attribute) plus fields such as deployment mode, port, replicas, and endpoint.

See also

• Element Types — how typing, fields, and containers work
• Software Types — System, Service, Environment, and other technology-neutral types that pair well with cloud diagrams