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.