Celerity
ApplicationsResources

Celerity VPC

Celerity resource type for VPCs

celerity/vpc

Spec Version: v2026-02-27-draft
Ecosystem Compatibility: v0 (Current) / v1 (Preview)

blueprint transform: celerity-2026-02-27-draft

Ecosystem Compatibility

  • v0 (Current): AWS only, supporting Amazon VPCs.
  • v1 (Preview): Multi-cloud, supporting Amazon VPCs, Google Cloud VPCs and Azure VNets.

Read more about Celerity versions here.

The celerity/vpc resource type defines a virtual private cloud in which Celerity applications, databases and caches can be placed.

Specification

The specification is the structure of the resource definition that comes under the spec field of the resource in a blueprint. The rest of this section lists fields that are available to configure the celerity/vpc resource followed by examples of different configurations for the resource and how the VPC behaves in target environments along with additional documentation.

Feature Availability

  • Available in v0 - Features currently supported
  • 🔄 Planned for v0 - Features coming in future v0 evolution
  • 🚀 Planned for v1 - Features coming in v1 release

name (required)

A unique name for the VPC that will be used to identify the VPC in the target environment. This will be used as a resource tag in target environments that support resource tagging for networking resources.

The name is also the key used to share a VPC across applications: a celerity/vpc declared in referenced mode locates the existing Celerity-managed VPC by matching this name, so the referencing resource must use the same name as the managed VPC it points at.

type

string

preset

The preset of the VPC that determines the configuration of the VPC resources in the target environment.

This can be one of the following values:

  • standard: A multi-AZ VPC with a public and private subnet in 3 availability zones (6 subnets in total).
  • public: A multi-AZ VPC with a public subnet in 3 availability zones.
  • isolated: A multi-AZ VPC with a private subnet in 3 availability zones.
  • light: A VPC with a public and private subnet in a single availability zone.
  • light-public: A VPC with a public subnet in a single availability zone.

For target environments that supports Dual-stack VPCs for Ipv4 and Ipv6 traffic, all presets will be configured to support both Ipv4 and Ipv6 traffic.

Available in v0

allowed values

standard | public | isolated | light | light-public

default value

standard

type

string

mode

Determines whether Celerity provisions the VPC or references an existing Celerity-managed VPC.

This can be one of the following values:

  • managed: Celerity provisions the VPC and its associated networking resources from the preset, and owns their lifecycle.
  • referenced: The resource is a reference to an existing Celerity-managed VPC that has the same name. Celerity does not provision or modify any networking resources; it resolves the existing VPC along with its subnets, routing and access controls, this allows applications, databases and caches defined in this blueprint to be placed into it.

referenced mode allows a VPC to be shared across multiple applications (blueprints) without native cross-blueprint links. One application declares the VPC in managed mode (the owner), and any number of other applications declare a celerity/vpc with the same name in referenced mode. Each application places its own resources into the shared VPC through its own local links; the VPC itself is matched by name in the target environment, so no link crosses a blueprint boundary.

When mode is referenced:

  • preset is ignored — the topology already exists and is not re-derived.
  • Target-environment networking options in the app deploy configuration (for example aws.vpc.cidrBlock) are ignored, for the same reason.
  • The referenced VPC must be one that Celerity created in managed mode, identified by the Celerity VPC name. Referencing a VPC provisioned outside of Celerity is not supported by this field.

Available in v0

allowed values

managed | referenced

default value

managed

type

string

Annotations

There are no annotations required for linking other resources to a celerity/vpc resource or modifying the behaviour of a VPC resource.

linkSelector.byLabel can be used to target VPCs from other resource types.

Outputs

Outputs are computed values that are accessible via the {resourceName}.spec.* field accessor in a blueprint substitution. For example, if the resource name is myVpc, the output would be accessible via ${myVpc.spec.id}.

id

The ID of the created VPC in the target environment.

type

string

examples

vpc-1234567890 (AWS VPC)

projects/my-project/global/networks/my-vpc (Google Cloud VPC)

my-vnet (Azure VNet)

Linked From

VPC resources can not be linked to from other resources.

celerity/api

When a VPC resource links to a celerity/api resource, the VPC will be used to place the API in the target environment when the API is deployed as a containerised application.

🚀 Planned for v1 - A VPC resource will be able to link to celerity/api resources when containerised deployments are supported, this will likely be available in a future v0 evolution.

Read more about Celerity APIs

celerity/handler

When a VPC resource links to a celerity/handler resource, the VPC will be used to place the handler in the target environment when the handler is deployed as a part of a FaaS application. A link between a VPC and handler will have no effect on handlers in a containerised application.

Available in v0

Subnet placement in serverless environments

The handler's celerity.handler.vpc.subnetType annotation selects which subnet a VPC-attached serverless function is placed in. It accepts public or private and defaults to private.

It is only considered by serverless targets that support placing functions in specific subnets of a customer-managed VPC, which is currently limited to AWS Lambda. It has no effect on other serverless targets: Google Cloud (Cloud Functions / Cloud Run) attaches functions to a VPC through a Serverless VPC Access connector and egress settings, and Azure Functions use VNet integration — neither offers a public/private subnet choice for the function.

On AWS, a VPC-attached Lambda never receives a public IP address, which makes subnet choice behave differently than it does for a typical instance:

  • private (default): the function can reach private resources in the VPC (such as a linked celerity/sqlDatabase or celerity/cache) and, where the VPC provides a NAT gateway, the public internet. This default requires the VPC to provide a private subnet; on the public and light-public presets, which provision none, set subnetType to public explicitly.
  • public: the function can reach private resources in the VPC but has no outbound internet access. A VPC-attached function has no public IP, so it cannot use the public subnet's internet gateway. This is the appropriate choice for cost-optimised VPCs that are provisioned without a NAT gateway, such as the public and light-public presets: the function reaches other in-VPC resources, for example a database or cache secured by security groups without incurring NAT gateway charges. In a VPC that already provisions a NAT gateway (such as the standard preset), public offers no advantage over private.

A handler that is not linked to a VPC is not VPC-attached and retains full outbound internet access by default.

Read more about Celerity handlers

celerity/consumer

When a VPC resource links to a celerity/consumer resource, the VPC will be used to place the consumer in the target environment when the consumer is deployed as a containerised application.

🚀 Planned for v1 - A VPC resource will be able to link to celerity/consumer resources when containerised deployments are supported, this will likely be available in a future v0 evolution.

Read more about Celerity consumers

celerity/schedule

When a VPC resource links to a celerity/schedule resource, the VPC will be used to place the schedule application component in the target environment when the schedule is deployed as a containerised application.

🚀 Planned for v1 - A VPC resource will be able to link to celerity/schedule resources when containerised deployments are supported, this will likely be available in a future v0 evolution.

Read more about Celerity schedules

celerity/workflow

When a VPC resource links to a celerity/workflow resource, the VPC will be used to place the workflow application component in the target environment when the workflow is deployed as a containerised application.

🚀 Planned for v1 - A VPC resource will be able to link to celerity/workflow resources when containerised deployments and workflows are supported.

Read more about Celerity workflows

celerity/cache

When a VPC resource links to a celerity/cache resource, the VPC will be used to place the cache instance or cluster in the target environment.

Available in v0

Read more about Celerity caches

celerity/sqlDatabase

When a VPC resource links to a celerity/sqlDatabase resource, the VPC will be used to place the SQL database instance or cluster in the target environment.

Available in v0

Read more about Celerity SQL databases

Examples

Create a Standard VPC

Blueprint Language

version "2025-11-02"
transform "celerity-2026-02-27-draft"

resource myVpc: celerity/vpc {
    spec {
        name = "my-vpc"
        preset = "standard"
    }
}

YAML

version: 2025-11-02
transform: celerity-2026-02-27-draft
resources:
    myVpc:
        type: "celerity/vpc"
        spec:
            name: "my-vpc"
            preset: "standard"

Share a VPC across applications

One application owns the VPC in managed mode (the default). This is the blueprint that provisions the networking resources:

Blueprint Language

version "2025-11-02"
transform "celerity-2026-02-27-draft"

resource sharedVpc: celerity/vpc {
    spec {
        name = "platform-shared-vpc"
        preset = "standard"
    }
}

Any other application references the same VPC by name in referenced mode. It provisions no networking resources of its own, but its handlers, caches and databases are placed into the shared VPC:

Blueprint Language

version "2025-11-02"
transform "celerity-2026-02-27-draft"

resource sharedVpc: celerity/vpc {
    spec {
        name = "platform-shared-vpc"
        mode = "referenced"
    }
}

YAML

version: 2025-11-02
transform: celerity-2026-02-27-draft
resources:
    sharedVpc:
        type: "celerity/vpc"
        spec:
            name: "platform-shared-vpc"
            mode: "referenced"

Target Environments

Local Development

VPCs are not provisioned in the local development environment.

AWS

Available in v0

Celerity VPCs are provisioned in AWS using the EC2 VPCs and associated networking resources. The Celerity VPC presets map to configurations of subnets, routing and access controls required for resources such as applications, databases and caches to be placed in the VPC.

A managed VPC is tagged with its Celerity name. A referenced VPC is resolved by looking up that same name tag in the target AWS account, so a VPC shared across applications is matched without any cross-blueprint reference. Because AWS VPCs are regional, the referenced VPC must be in the same region as the resources being placed into it.

Google Cloud

🚀 Planned for v1 - The Google Cloud deployment target is planned for v1, it may become available in a future v0 evolution.

Celerity VPCs are provisioned in Google Cloud using the VPC resource type in custom mode along with associated networking resources. The Celerity VPC presets map to configurations of subnets, routing and access controls required for resources such as applications, databases and caches to be placed in the VPC. A referenced VPC is resolved by its Celerity name (via network labelling); Google Cloud VPCs are global, so no region needs to match.

Azure

🚀 Planned for v1 - The Azure deployment target is planned for v1, it may become available in a future v0 evolution.

Celerity VPCs are provisioned in Azure using VNets and associated networking resources. The Celerity VPC presets map to configurations of subnets, routing and access controls required for resources such as applications, databases and caches to be placed in the VNet. A referenced VNet is resolved by its Celerity name; as with AWS, Azure VNets are regional, so the referenced VNet must be in the same region as the resources placed into it.

App Deploy Configuration

Configuration specific to a target environment can be defined for celerity/vpc resources in the app deploy configuration file.

This section lists the configuration options that can be set in the deployTarget.config object in the app deploy configuration file.

AWS Configuration Options

Available in v0

aws.vpc.cidrBlock

The CIDR block for the IPv4 range to use for the VPC.

type

string

default value

10.0.0.0/16

aws.vpc.enableDNSSupport

When set to true, DNS support will be enabled for the VPC. For more information, see DNS attributes in your VPC.

type

boolean

default value

true

aws.vpc.enableDNSHostnames

Indicates whether the instances launched in the VPC get DNS hostnames. If enabled, instances in the VPC get DNS hostnames; otherwise, they do not. This is disabled by default for nondefault VPCs. You will want to enable DNS hostnames if you intend to use VPC endpoints to connect to AWS services using the public host names that SDKs use to connect to the services by default.

type

boolean

default value

false

Last updated on