Local Testing

chant synthesizes each cloud’s native format — CloudFormation for AWS, ARM for Azure, Config Connector for GCP — and can apply that output to a local emulator instead of a real account. That runs the deployer code you use in production against an emulated cloud API, at no cost and offline.

The applier issues the same calls it would against AWS, Azure, or GCP; only the endpoint changes. A green local run has exercised synthesis, serialization, and apply.

“Offline” here means after the image is pulled: chant emulator up needs the container image once, and every call after that is loopback. See Network Egress for what each phase reaches.

The same pipeline, local or real — the applier speaks each cloud's native protocol, and only the endpoint changes

Nothing on the path shells out to a CLI. chant build is a pure function — TypeScript in, a validated spec-native artifact out. The applier then speaks the cloud’s own protocol directly: awsApply calls the CloudFormation API, azApply PUTs ARM resources, gcpApply calls the GCS/PubSub/IAM REST APIs. It doesn’t wrap aws, az, or gcloud. So a green local run tests the real deployer.

See all three at once

examples/local-cloud-trio deploys the same object store to AWS, Azure, and GCP — each on its own local emulator — with one op per cloud. It’s the fastest way to watch every path run. Jump to The tri-cloud example.

What runs locally

Each cloud keeps its native format and its own local target. The emulators are the Floci suite — LocalStack-compatible, Quarkus/GraalVM native, one per cloud.

Cloud	Resource shape	Synthesizes to	Applied by	Emulator	Port
AWS	S3, IAM, Lambda, …	CloudFormation	awsApply	floci	4566
Azure	Storage, KeyVault, …	ARM template	azApply	floci-az	4577
GCP	GCS, PubSub, Secrets, …	Config Connector	gcpApply	floci-gcp	4588

The resource description is identical in shape across clouds. What differs is how each cloud’s apply reaches the emulator — because each cloud’s control plane is different.

Why three different appliers

There is no shared apply verb off-cluster. Each cloud’s local story forced a different path:

• AWS — awsApply calls the CloudFormation API directly (create-or-update the stack, then poll it to a settled state) against Floci’s emulated CloudFormation control plane. The stack is the deploy boundary.
• Azure — floci-az has no Microsoft.Resources/deployments provider, so az deployment can’t run locally. azApply reads the ARM template and PUTs each resource directly to floci-az’s ARM resource CRUD, in dependency order, resolving reference()/listKeys() from live responses.
• GCP — GCP has no native deployment service. gcpApply maps each Config Connector resource to its underlying REST call and drives create/update/delete itself, including long-running operations and orphan pruning.

In every case the deployer code is the thing under test, run against a real cloud-shaped API.

Note

Local emulators cover a subset of each cloud’s services. Floci reports its coverage at /_localstack/health. If a service isn’t emulated, that resource can’t run locally — but synthesis and lint still validate it, and the same op targets real cloud by dropping the endpoint override.

Pick your path

Each page walks the full loop for one cloud: boot the emulator, build the stack, apply it, verify the resource, tear down.

AWS — Floci awsApply drives the CloudFormation API directly against floci:4566 — no aws CLI.

Azure — floci-az ARM resources applied directly with azApply, since floci-az has no deployments provider.

GCP — floci-gcp Config Connector resources driven as native REST calls by gcpApply against floci-gcp:4588.

Test Harness — vitest deployStack from @intentius/chant/testing: deploy per suite, assert against the live stack, destroy in afterAll.

The tri-cloud example

examples/local-cloud-trio is the reference for all three paths in one project. The same infrastructure — an object store — is described once per cloud and deployed to each cloud’s emulator.

cd examples/local-cloud-trio
npm install

chant run aws     # S3 bucket → Floci
chant run azure   # storage account → floci-az
chant run gcp     # GCS bucket → floci-gcp

Each op boots that cloud’s emulator, builds the stack, applies it, verifies the resource exists, and tears the emulator down. The project needs Docker plus aws and curl on PATH — no cloud account.

The chant.config.ts loads all three cloud lexicons so chant run resolves each cloud’s applier activity:

export default { lexicons: ["aws", "azure", "gcp", "fountain"] } satisfies ChantConfig;

From local to real cloud

The emulator is only an endpoint. The same stacks and ops target a real account by dropping the endpoint override — and, for AWS, unsetting AWS_ENDPOINT_URL. Nothing about the resources or the apply logic changes, which is what makes a green local run meaningful.