Skip to content

Offline Behaviour

There is no unlimited offline mode. PteroCloud is server-authoritative. Offline operation is bounded by the last server-signed lease_expires_at, and nothing on the client can extend it.

When the licensing server is unreachable

  1. The refresh fails transiently. The existing signed lease is kept.
  2. While now < lease_expires_at, the control layer stays usable and the diagnostics mark the lease as stale (SERVER_UNAVAILABLE reported, state remains active/expiring).
  3. Once now >= lease_expires_at, the state becomes lease_expired and the control layer locks. Existing VMs keep running.
  4. When the server returns, the next refresh ingests a fresh signed lease and the control layer unlocks — no reinstall required.

What the client will never do

  • It will not extend lease_expires_at locally.
  • It will not treat a cached lease as valid past its signed window.
  • It will not accept a lease without a valid signature or installation binding, even if the local cache says otherwise.
  • It will not "grace" a suspended/revoked state.

First install offline

If the server is unreachable on first install (no existing valid lease), the installer stops with LICENSE_SERVER_UNAVAILABLE and installs nothing. There is no offline first-install path.

Clock security

  • A significant rollback (local time far behind the last trusted server time) is detected, recorded as LICENSE_CLOCK_ANOMALY, and requires online revalidation before the lease is trusted again.
  • A forward jump triggers revalidation but does not burn the license.

Practical guidance

  • Keep outbound HTTPS to the licensing API open.
  • Use the default 5-minute refresh cadence; the lease window is sized by the server, not the client.
  • Monitor pterocloud:license:diagnostics and alert on expiring.