Skip to content
Rime Docs

Change Management

Rime uses a two-phase workflow for all infrastructure changes. You make modifications to your desired configuration in the UI, then review a change preview before anything is applied to your Snowflake account or AWS environment. This approach prevents accidental modifications and provides a clear audit trail of every change.

The plan/apply workflow

Every infrastructure change in Rime follows the same steps:

  1. Configure — modify your desired state through the UI (add a resource, change a warehouse size, update a grant)
  2. Plan — Rime generates a change preview by comparing your desired state against the current actual state
  3. Review — examine what will be created, modified, or destroyed before committing
  4. Apply — approve the change and Rime provisions it in your cloud environment
  5. Verify — Rime confirms the operation succeeded and updates the actual state

This mirrors the plan/apply model used in infrastructure-as-code tools, but you interact with it through a visual interface rather than command-line tools or configuration files.

Pending changes

When you modify infrastructure configuration in the UI — creating a new warehouse, changing a role grant, adjusting a lifecycle rule — those modifications are saved as pending changes. They appear in Infrastructure > Changes with a Pending status.

Pending changes are not applied automatically. They accumulate until you choose to plan and apply them. This lets you batch related changes together (for example, creating a new database, its schemas, and the associated role grants as a single operation).

Viewing pending changes

The Changes page lists all pending modifications grouped by resource. Each entry shows:

  • Resource type — database, schema, warehouse, role, grant, S3 bucket, IAM role, or SNS topic
  • Resource name — the identifier of the affected resource
  • Change type — create, modify, or destroy
  • Summary — what specifically will change (e.g., “warehouse size X-Small to Small”)

You can discard individual pending changes if you change your mind before planning.

Running a plan

Select Plan Changes to generate a detailed preview. Rime compares your desired state against the actual state tracked in its Terraform state file and produces a change report.

The plan shows each resource that will be affected, organised into three categories:

Resources to create

New resources that do not exist yet. The plan shows all configuration values that will be set. Rime also lists any dependent resources that will be created automatically (for example, creating an S3 bucket may also create an associated IAM role if one was configured).

Resources to modify

Existing resources whose configuration differs from the desired state. The plan shows the current value and the new value for each changed attribute. Pay attention to whether a modification is non-disruptive or requires replacement:

  • Non-disruptive — the change can be applied in place (e.g., changing warehouse auto-suspend timeout)
  • Requires replacement — the resource must be destroyed and recreated (e.g., renaming a database). Rime flags these clearly because they may cause temporary downtime or data loss

Resources to destroy

Resources that are being removed. The plan lists all dependent resources that will also be destroyed. Destroying a database, for example, destroys all schemas and tables within it.

Applying changes

After reviewing the plan, select Apply to execute it. Rime runs Terraform internally in an isolated workspace. During application:

  • Progress is displayed in real time with per-resource status (pending, in progress, completed, failed)
  • Each resource is applied in dependency order — Rime creates parent resources before children and destroys children before parents
  • If any resource fails, the operation stops and reports the error. Resources that were successfully applied before the failure remain in place

Application typically completes in seconds for small changes and a few minutes for large batches.

Operation history

Every plan and apply operation is recorded in the operation history, accessible from Infrastructure > History. Each entry includes:

  • Timestamp — when the operation ran
  • User — who initiated it
  • Operation type — plan or apply
  • Status — succeeded, failed, or cancelled
  • Resource summary — counts of resources created, modified, and destroyed
  • Duration — how long the operation took

Select any operation to view its full details, including the exact changes that were made and any error messages from failed resources.

Audit context

The operation history serves as an audit log for infrastructure changes. You can answer questions like:

  • Who created the ANALYTICS_WH warehouse and when?
  • When was the ANALYST_ROLE last modified?
  • Which changes were applied in the last 30 days?

For broader audit requirements, see Governance for Rime’s full audit logging capabilities.

Rolling back changes

If an applied change causes problems, you have two options for remediation:

Reverting configuration

Navigate to the affected resource, undo the configuration change, and run a new plan/apply cycle. For example, if you increased a warehouse size and want to revert, change the size back to its previous value and apply.

Restoring from history

Select a previous operation in the history view and choose Restore Configuration. This copies the resource configuration from that point in time into your desired state as new pending changes. You can then review and apply the restoration through the normal plan/apply workflow.

Rollback always goes through the plan/apply workflow. Rime does not apply reversions automatically — you always get a chance to review before anything changes.

Concurrent changes

Rime prevents concurrent apply operations within the same project. If one user is applying changes, another user attempting to apply will see a message indicating that an operation is already in progress. Both users can create pending changes and run plans simultaneously, but only one apply can execute at a time.

This prevents conflicting modifications from being applied in an unpredictable order.

Best practices

Group related changes and apply them together. Creating a new data pipeline typically involves a database, schemas, warehouse, roles, grants, an S3 bucket, and an SNS topic. Configure all of these, then run a single plan/apply cycle. This is faster than applying them one at a time, and the plan gives you a complete picture of everything that will change.

Review plans carefully

Treat the plan review the same way you would review a pull request. Check for unintended modifications, verify that no resources are being destroyed unexpectedly, and confirm that replacement operations (destroy + create) are acceptable.

Use descriptive comments

When creating or modifying resources, fill in the comment field. Comments appear in both Rime and Snowflake, making it easier to understand the purpose of each resource months later.

Separate environments

Use separate Rime projects for development, staging, and production environments. This prevents a development change from accidentally being applied to production. Each project has its own desired state, actual state, and operation history.

Coordinate with your team

Since pending changes accumulate until applied, communicate with your team when you have pending changes. Another team member running a plan will see your pending changes included in their preview. The operation history records who applied each change.