Manage devices

The Devices panel is your tenant’s roster of paired desktops. Every Tauri install that’s enabled cloud sync against this tenant shows up here, with the last-seen timestamp, OS / version, sync stats, and an Approved / Pending / Revoked badge. It’s where you welcome a new till, see which device hasn’t checked in for a week, and force-unpair a lost tablet.

Updated 5 May 2026·For v2.2.0·5 min read

settings · system · devices panel · approved and pending devices listed

What’s on the list

Each device row shows:

• Device name — the friendly name set on the desktop’s Settings → System tab (defaults to the OS hostname, e.g. MacBook Pro of Hassan).
• OS / version — the Tauri build’s reported platform (darwin-arm64, windows-amd64) and Fexl Lite version (v2.2.0).
• Last seen — timestamp of the most recent successful sync health check. A device that’s powered off shows its last successful check-in time.
• Status — Approved (live, syncing), Pending (registered, waiting for owner approval), Revoked (rejected; can’t sync until re-paired).
• Today’s sync stats — pushed-rows, pulled-rows, and any conflicts logged in the last 24 hours. Quick glance at “is this device healthy?”.

The list is sorted by status (pending at the top, then approved by last-seen descending, then revoked at the bottom).

Pairing a new device

The desktop side of pairing is in Settings → System → Cloud Sync on the device itself. Once that’s filled in, the device shows up here as Pending within 30 seconds.

1

See the pending row

A Pending badge with the device name. The owner approves from this panel.

2

Click Approve

Confirms a permission dialog (“This device will receive your tenant’s full data on its next sync”). Approve.

3

Wait for the first sync

The desktop’s next 30-second tick pulls the full tenant snapshot — products, customers, suppliers, invoices, journal entries — and the row’s badge flips to Approved. The pulled-rows count surges in the first cycle (often thousands of rows), then drops to single-digit deltas on subsequent cycles.

!

Approve only devices you recognise

An attacker who got hold of your license key + tenant UUID can register a pending device. Approving them gives them a full read of your data. Verify the device name and the user who’s expecting it before clicking Approve. If you don’t recognise a pending device, click Reject and rotate the license key in System settings.

Renaming a device

Cosmetic; helpful when three “MacBook Pro” entries appear. Click the row → Rename → type a friendlier name (Front till, Back office, Hassan’s tablet). Saved on the cloud and reflected on the device’s local Settings → System tab on the next pull.

Revoking a device

Two reasons to revoke: a device is lost / stolen, or a staff member’s tablet is being repurposed.

1

Click the row, then Revoke

Confirmation dialog: Are you sure? The device will be unable to sync. Local data on the device remains accessible. Confirm.

2

The device's next sync is rejected

On the next 30-second cycle, the cloud returns a 403 to the desktop. The desktop falls back to read-only-on-local mode — it can still display whatever’s in local SQLite, but writes are blocked.

3

If the device is recovered, re-approve

The device row stays in the list with a Revoked badge. To re-pair, click Re-approve — the device’s pending status flips back to approved on its next cycle.

✕

Revoke ≠ wipe

Revoking blocks sync. It does not delete the local SQLite file on the lost device. If the tablet is genuinely lost (not just being repurposed), assume an attacker who finds it can read everything that synced down before revoke. For high-sensitivity tenants, consider rotating prices, deleting customer PII, or wiping locally before sync if you suspect a compromise.

Force-unpair vs revoke

Two adjacent verbs:

• Revoke — cloud-side action; the cloud rejects the device’s future sync requests. The desktop can still run offline.
• Force unpair (advanced) — same as revoke, plus marks the device’s _cloudIds as “no longer authoritative”. On re-approve, the device pulls a fresh tenant snapshot rather than diffing against its existing local data. Slower (full re-pull) but cleaner — useful if you suspect the local SQLite drifted badly.

Use revoke for normal cases; force-unpair only when there’s reason to believe the local state is corrupt.

Per-device permissions — coming soon

Today every approved device has full read/write access to the tenant. Per-device read-only mode (a kiosk that shows menus but can’t ring sales) is on the roadmap but not shipped. For now, if you need a read-only device, use a separate user role with only read permissions and have it log in there.

The cloud-primary failover model

Once approved, an Approved device’s API client uses the cloud URL as primary and localhost:8089 as backup:

• Read / write → cloud first.
• Cloud times out or returns 5xx → fail over to local. Toast warns the cashier.
• Local serves the request from local SQLite (which is up to date as of the last successful pull).
• Network recovers → next API call goes back to cloud first.

This is why the desktop keeps running even when the cloud drops. The local server is the safety net, not a separate source of truth — every offline write is _isDirty = 1 and pushes to cloud as soon as the link is back. See Cloud architecture for the full picture.

Related

SYSTEM

System settings (desktop)

The desktop side of pairing — where you enter cloud URL, license key, tenant UUID.

SYNC

Sync overview

The big-picture sketch and the pairing walkthrough.

CONFLICT

Conflict resolution

Last-write-wins, the duplicate-UUID retry, and the corner cases.

MANUAL

Manual sync

Force a cycle when last-seen has drifted further than expected.