For DevOps engineers and infrastructure leads at Indian companies managing cloud storage through Infrastructure as Code.
Terraform and S3 Compatibility
Terraform's AWS provider manages S3 resources through the AWS S3 API. Because IBEE implements the same S3 API, the same provider — with one configuration change — manages IBEE buckets instead of AWS S3 buckets. No custom provider required. No community forks. The official hashicorp/aws provider, pointed at IBEE's endpoint, creates, configures, and manages IBEE buckets through plan, apply, and destroy cycles exactly as it does for AWS.
The configuration change is the endpoint URL in the provider configuration:
The s3usepath_style = true setting is the critical line. It tells the AWS provider to use path-style S3 URLs (https://s3.ibee.in/bucket-name/key) rather than virtual-hosted style (https://bucket-name.s3.ibee.in/key), which is required for non-AWS S3-compatible providers including IBEE.
Store ibeeaccesskey and ibeesecretkey as Terraform variables sourced from environment variables or a secrets manager — never hardcoded in .tf files.
Basic Bucket Resources
A minimal production bucket with versioning and public access blocked:
For a bucket that needs public read access — static asset serving, CDN origin — remove the public access block and add a bucket policy:
Lifecycle Policy Resources
Lifecycle rules defined in Terraform are version-controlled alongside the rest of your infrastructure. A PR to add or modify a lifecycle rule goes through code review before being applied — preventing accidental deletion of important data due to misconfigured expiry values.
CORS Configuration
For applications where a browser-side client uploads directly to IBEE (using presigned POST URLs) or reads objects via JavaScript, CORS must be configured on the bucket:
Restrict allowed_origins to your actual application domains. Wildcard origin ("*") is a security risk for buckets containing user data — it allows any website to make cross-origin requests to your bucket with the user's credentials.
Object Lock for Compliance Workloads
For regulatory compliance workloads requiring WORM (Write Once Read Many) storage — audit logs, financial records, legal hold evidence — object lock prevents deletion or overwrite for a defined retention period:
With COMPLIANCE mode, no user — including the account root — can delete or overwrite objects within the retention period. This satisfies CERT-In's 180-day log retention requirement and similar regulatory mandates without relying on process controls.
Using IBEE as the Terraform Remote State Backend
Terraform remote state requires an S3-compatible backend. IBEE works as a Terraform state backend with the standard S3 backend configuration:
Store credentials for the state backend as environment variables (AWSACCESSKEYID and AWSSECRETACCESSKEY are read by the backend configuration even when using non-AWS endpoints) rather than hardcoding them in the backend block.
With IBEE as the state backend, your Terraform state is stored on India-sovereign infrastructure — not on AWS, not subject to US CLOUD Act reach. For teams managing infrastructure for regulated Indian businesses, this extends the India-sovereignty posture to the infrastructure management layer itself.
Module Structure for Multi-Bucket Projects
For projects with multiple buckets serving different purposes, organise Terraform into modules:
Calling the module for a new bucket is a few lines:
