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 thepreset, and owns their lifecycle.referenced: The resource is a reference to an existing Celerity-managed VPC that has the samename. 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:
presetis 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
managedmode, identified by the Celerity VPCname. 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.
Links To
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.
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 linkedcelerity/sqlDatabaseorcelerity/cache) and, where the VPC provides a NAT gateway, the public internet. This default requires the VPC to provide a private subnet; on thepublicandlight-publicpresets, which provision none, setsubnetTypetopublicexplicitly.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 thepublicandlight-publicpresets: 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 thestandardpreset),publicoffers no advantage overprivate.
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