Terraform Best Practices

Use Terraform to manage durable Files.com configuration through reviewed code. Establish which resources it owns, keep state secure, and test changes with the credentials and destinations intended for each environment.

Assign One Configuration Authority

For each managed resource, make routine changes through Terraform. The web interface, API, CLI, SCIM, and other provisioning tools can change some of the same objects. A later Terraform plan may detect those changes and propose reverting them to match the configuration.

For example, let the identity provider own SCIM-managed users and groups instead of also trying to manage their lifecycle through Terraform. A CLI script can upload files into Terraform-managed folders without taking over management of the folder configuration.

When an emergency requires a manual change, reconcile the code and live resource before the next apply. Do not assume two tools cannot conflict simply because one is called an operational tool.

Import Existing Resources

Follow Adopting Terraform on an Existing Files.com Site to bring existing resources under management. Write matching configuration, import incrementally, and review the plan until it proposes only the changes you intend.

Terraform state records the association between configuration and live objects. Do not edit its JSON by hand to make routine configuration changes. Use configuration files and the supported import or state commands for their intended purposes.

Protect State and Credentials

Use a backend with appropriate access control and a recoverable history. Configure state locking where the backend supports it, and prevent concurrent applies. Locking support and setup vary by backend; remote storage alone does not establish that it is enabled.

Supply the Files.com API key through a protected environment or secret-management mechanism. State and saved plans can contain sensitive values even when variables are marked sensitive. Protect those artifacts and keep them out of ordinary source-control commits and logs.

State backups help recover Terraform's records. Restoring an old state file does not undo changes to live Files.com resources or recover deleted file contents.

Separate Environments

Keep production and test configuration values, credentials, and state distinct. A test Workspace can isolate the resources for a limited experiment. Use a Child Site when testing requires independent site settings. Account Structure & Environments covers that choice.

Check the provider endpoint and Remote Server destinations before applying. An environment labeled “test” can still carry production credentials or point at a production folder.

Review and Apply Small Changes

Run terraform fmt and terraform validate, then review terraform plan for the intended environment. Inspect deletions, replacements, permission changes, and shared dependencies. Syntax validation does not prove that the resulting users can transfer files or that a workflow's destination is correct.

Apply a focused change in the test environment and verify the resulting behavior. Review the production plan with production values before applying it. Reuse modules where they clarify a repeated configuration, while keeping consequential environment differences visible.

If the result is wrong, stop dependent work and inspect the live state before planning a correction. Reverting configuration can be part of recovery, but it does not reverse files already delivered or deleted. Include those effects in Production Validation & Change Control.