Skip to main content
Every apply creates or reuses a deployment run for the latest pushed configuration version. Runs give you a timeline and per-resource visibility, so changes are traceable.

​
Before a run is queued

Minenet performs preflight checks, including:
  • active subscription,
  • plan capacity,
  • optional spending limit,
  • configuration/team ownership,
  • pushed version availability.
If checks fail, apply is rejected early with a clear reason. Common example: 409 NO_PUSHED_VERSION when a configuration has never been pushed.

​
Queueing behavior

When checks pass, the run is queued and assigned a queue position. For safety, runs execute in controlled order per team.

​
Run status lifecycle

Typical progression:
  • queued
  • planning
  • executing
  • finalizing
  • terminal: succeeded, failed, canceled

​
Per-resource action types

During execution, each resource is classified as:
  • create
  • update
  • replace
  • delete
  • noop
This explains exactly why Minenet touched (or skipped) each resource.

​
Idempotency for automation

If you automate applies through API, use idempotency_key. This prevents duplicate run creation from retries in CI/CD pipelines.

​
What to inspect when something looks wrong

  1. Run summary status.
  2. configuration_version_id and configuration_version_number.
  3. Per-resource action/status rows.
  4. Event timeline messages.
  5. Final error code/message (if failed).

​
Resume behavior

Failed or canceled runs can be resumed. Use resume after correcting the root cause (for example, quota, validation, or provider-side issue).

​
Next step

Continue to Safe rollouts and troubleshooting.