Scody Cloud
xPanel

Autonomous operations: reconcile, don't remember

The core loop behind xPanel is desired-state reconciliation. On each configured maintenance cycle the platform refreshes its resource graph, compares declared and observed state, records drift, and can prepare policy-bounded remediation for supported actions.

How it works

Three concepts, one loop

Desired state

You declare what a site or node should look like: runtime version, TLS status, backup schedule, resource limits, security baseline.

Drift detection

On each configured ScodyX maintenance cycle, xPanel refreshes the resource graph, compares declared state with observed platform state and records detected drift.

Remediation policy

Known failure classes have a defined response. Policy decides whether that response runs automatically or waits for approval.

Worked example

A certificate renewal fails — what actually happens

A concrete walk-through of the reconciliation loop, not a hypothetical.

The scenario

  1. 1. A site's TLS certificate is due for renewal. The declared state says the site must always hold a valid certificate.
  2. 2. The renewal attempt fails — the domain's DNS validation record is missing because a nameserver was changed outside xPanel.
  3. 3. Reconciliation detects that actual state (certificate expiring in 3 days) no longer matches desired state (certificate always valid), and logs the drift.
  4. 4. The event and the failed renewal attempt are written to the evidence ledger with a timestamp and cause.

The response today

Desired-state reconciliation for this class of drift is in beta: the platform can detect the state mismatch on its maintenance cycle and prepare the supported renewal/DNS workflow; certificate retry behavior remains tied to the underlying certificate service so an operator can fix the nameserver record quickly. Automatically rewriting DNS or switching validation methods without approval — full autopilot remediation — is in build. Until it ships, the last mile of this specific fix is a human action, backed by a system that already found the cause for you.

Where a human stays in the loop

Automation with boundaries

Destructive actions — deleting data, terminating an account, wiping a node — always require explicit confirmation.

Novel failure signatures that don't match a known policy are surfaced to an operator rather than guessed at.

Every automated action is reversible where technically possible, and logged to the evidence ledger either way.

Operators can pause reconciliation on a node or account at any time.

See reconciliation on a real node

We're happy to walk through how declared state, drift and remediation apply to your workload today.