Overrides & Escape Hatch
The escape hatch for when the defaults aren't enough.
Most Anvil components accept a hatch argument that reaches into the underlying Pulumi
resources (an S3 bucket, a DynamoDB table, an API Gateway stage, and so on) and lets you override
individual fields — without losing any of the secure defaults applied to the fields you don't touch.
const bucket = new anvil.aws.Bucket('custom', {
versioning: false,
hatch: {
bucket: { forceDestroy: true, tags: { env: 'dev' } },
},
});bucket = anvil.aws.Bucket("custom",
versioning=False,
hatch=anvil.aws.BucketHatchArgsArgs(
bucket=anvil.aws.BucketOverridesArgs(
force_destroy=True,
tags={"env": "dev"},
),
),
)bucket, err := anvilaws.NewBucket(ctx.PulumiCtx(), "custom", &anvilaws.BucketArgs{
Versioning: pulumi.Bool(false),
Hatch: &anvilaws.BucketHatchArgsArgs{
Bucket: &anvilaws.BucketOverridesArgs{
ForceDestroy: pulumi.Bool(true),
Tags: pulumi.StringMap{"env": pulumi.String("dev")},
},
},
})hatch is shaped after the underlying provider resource — in the example above, bucket maps to the arguments of the upstream aws.s3.Bucket resource. Each
component's page lists whether it supports hatch and, where relevant, the named
sub-objects it exposes (lifecycle rules, policy, versioning, and so on).
The values are deep-merged into Anvil's defaults: maps merge key by key, a value you set replaces the default, and a list you set replaces the default list rather than appending to it.
Not every component exposes hatch — components composed from many resources (like Vpc) expose their escape hatches as typed sub-arguments instead
(nat, bastion, flowLogs) rather than one catch-all override.