Terraform and S3 Compatibility
Terraform's AWS provider manages S3 resources through the AWS S3 API. Because IBEE implements the full S3 API, the same provider, with one configuration change, manages IBEE buckets instead of AWS S3 buckets. No custom provider is required, no community forks, no alternative registry. 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 block, with s3_use_path_style set to true. This tells the AWS provider to use path-style S3 URLs rather than virtual-hosted style, which is required for non-AWS S3-compatible providers. Three additional skip_* settings prevent the provider from making AWS-specific validation calls that would fail against a non-AWS endpoint. The complete provider configuration with all required settings is available at ibee.ai/docs.
Store your IBEE access key and secret key as Terraform input variables sourced from environment variables or a secrets manager. Never hardcode credentials in .tf files. The recommended variable setup and CI/CD environment configuration are covered in the documentation at ibee.ai/docs.
The diagram below shows how the full workflow connects: Terraform configuration files flow through plan and apply into IBEE Object Storage, with remote state written back to a dedicated IBEE bucket and shared across the team and CI/CD pipeline.
Flow from and to Ibee Buckets
Basic Bucket Resources
A minimal production bucket configuration in Terraform covers three resources: the bucket itself, a versioning configuration with versioning enabled, and a public access block with all four block settings set to true. This is the recommended baseline for any bucket holding application or user data.
For a bucket that needs public read access, such as a static asset origin for a CDN, the public access block is omitted and replaced with a bucket policy granting read access to all principals on all objects in the bucket. Complete resource definitions for both private and public bucket configurations are available at ibee.ai/docs.
Lifecycle Policy Resources
Lifecycle rules defined in Terraform are version-controlled alongside the rest of your infrastructure. A pull request to add or modify a lifecycle rule goes through code review before being applied, which prevents accidental data deletion from misconfigured expiry values. We have seen teams lose weeks of data debugging what turned out to be a lifecycle rule that was applied manually without review — getting this into version control is the first thing worth doing.
Common lifecycle rule patterns include expiring temporary upload objects after a short window of 7 days, and purging old non-current versions after 90 days to control storage costs on versioned buckets. Full lifecycle configuration examples with filter prefixes and expiration blocks are at ibee.ai/docs.
CORS Configuration
For applications where a browser client uploads directly to IBEE using presigned POST URLs, or reads objects via JavaScript, CORS must be configured on the bucket. The CORS configuration specifies allowed origins, methods, headers, and the max age for preflight caching.
Restrict allowed origins to your actual application domains. A wildcard origin is a security risk for buckets containing user data: it allows any website to make cross-origin requests to your bucket using the user's session credentials. CORS configuration examples for common frontend upload patterns are at ibee.ai/docs.
Object Lock for Compliance Workloads
For regulatory compliance workloads requiring WORM (Write Once Read Many) storage, such as audit logs, financial records, and legal hold evidence, object lock prevents deletion or overwrite for a defined retention period. Object lock must be enabled at bucket creation time and cannot be added to an existing bucket, so it must be present in the initial Terraform resource definition.
With COMPLIANCE mode, no user, including the account root, can delete or overwrite objects within the retention period. A 180-day default retention satisfies CERT-In's audit log retention requirement and similar regulatory mandates without relying on process controls. GOVERNANCE mode is available for environments where administrators need override capability with appropriate permissions. Object lock Terraform examples are at ibee.ai/docs.
Using IBEE as the Terraform Remote State Backend
Terraform remote state requires an S3-compatible backend. IBEE works as a Terraform state backend using the standard S3 backend block with IBEE's endpoint URL and force_path_style set to true. Credentials for the state backend are passed via environment variables rather than hardcoded in the backend block, since the backend block does not support variable interpolation.
With IBEE as the state backend, your Terraform state is stored on India-sovereign infrastructure, not on AWS and 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. The full backend configuration block is available at ibee.ai/docs.
Module Structure for Multi-Bucket Projects
For projects with multiple buckets serving different purposes, organising Terraform into reusable modules keeps configuration concise and consistent. A typical module encapsulates the bucket resource, versioning configuration, and public access block behind three input variables: bucket name, whether versioning is enabled, and whether public read is required.
Calling the module for a new bucket is four lines. Adding a new environment is a separate directory that calls the same modules with different variable values. The provider configuration lives once in the root module and is inherited by all child modules, so the IBEE endpoint configuration does not need to be repeated per bucket. A reference module structure and example calling code are at ibee.ai/docs.
