oxid apply

Apply infrastructure changes. Oxid only touches resources that have actually changed, executing operations in parallel across the dependency graph.

Usage

oxid apply [flags]
oxid apply <plan-file>

The apply command executes the planned changes against your infrastructure. It creates, updates, destroys, or replaces resources as needed, respecting the dependency graph to maximize parallelism while maintaining correctness.

Smart Apply

Oxid only operates on resources that have changed. If your configuration has 200 resources but only 3 have diffs, only those 3 (and their dependents if necessary) are touched. This makes applies fast and predictable.

TipUnlike wave-based systems that process all resources at the same depth level together, Oxid uses event-driven per-resource parallelism. A resource starts executing the moment all its dependencies have completed.

Example Output

$ oxid apply

Oxid will perform the following actions:

  + aws_s3_bucket.logs
  ~ aws_security_group.web
  -/+ aws_instance.api

Plan: 1 to add, 1 to change, 1 to replace.

Do you want to apply these changes? (yes/no): yes

Creating aws_s3_bucket.logs...
  aws_s3_bucket.logs: Created (1.2s)

Updating aws_security_group.web...
  aws_security_group.web: Updated (0.8s)

Destroying aws_instance.api...
  aws_instance.api: Destroyed (32.4s)
Creating aws_instance.api...
  aws_instance.api: Created (45.1s)

Apply complete. 2 created, 1 updated, 1 destroyed.
Outputs saved to state database.

Duration: 47.3s

Operation Verbs

Oxid uses clear verbs during apply to indicate exactly what is happening:

Creating - A new resource is being provisioned
Updating - An existing resource is being modified in-place
Destroying - A resource is being deleted
Replacing - A resource is being destroyed and recreated (forces new)

History Recording

Every change made by oxid apply is recorded in the resource_history table. This includes the action taken, a timestamp, the before/after state, and key attributes. You can query this history with oxid history or directly via SQL.

oxid query "SELECT address, action, created_at FROM resource_history ORDER BY created_at DESC LIMIT 10"

Output Persistence

After a successful apply, all defined output blocks are evaluated and persisted to the state database. Sensitive outputs are encrypted at rest when using the PostgreSQL backend with pgcrypto.

# View outputs after apply
oxid output
oxid output --json

Flags

Flag	Description	Default
--target <address>	Limit apply to a specific resource and its dependencies.	all resources
--auto-approve	Skip the confirmation prompt. Useful for CI/CD pipelines.	false
--parallelism <n>	Maximum number of concurrent resource operations.	10

CI/CD Usage

For automated pipelines, combine --auto-approve with a saved plan file:

# In CI pipeline
oxid init
oxid plan --out plan.oxid
# ... review step ...
oxid apply plan.oxid --auto-approve

Error Handling

If a resource fails during apply, Oxid records the partial state and skips only the transitive dependents of the failed resource. All other independent resources continue to apply normally.

NoteFailed resources are marked in state so the next oxid plan will show them as needing attention. You do not need to manually clean up partial state.