Releases that can be explained and recovered

Record the request first

Shiplet records a deployment request in durable storage before contacting the runtime provider. That order matters. If a process restarts or a provider response is ambiguous, the system still has an application-level record of the intended operation.

Retry with context

A scheduler claims due jobs with leases, applies backoff to transient failures, and refreshes queued or building provider state. Ambiguous operations are reconciled rather than blindly replayed, reducing the chance that a timeout becomes a duplicate deployment.

• Durable request state
• Leased workers
• Backoff for transient errors
• Reconciliation for ambiguous provider outcomes

Recovery stays attached to the application

Every release can retain a versioned application specification. That makes the prepared state diffable and exportable, while release history and the deploy timeline explain what happened at each step. Recovery is then part of the application workflow, not a hunt through an unrelated cloud console.