Working offline

The desktop app is built for venue and show-site conditions: dead uplinks, captive-portal Wi-Fi, or no network at all. The entire designer keeps working, your local project survives anything short of wiping the machine, and a cached license keeps your paid plan alive; you only need to have signed in online once before.

What works offline, and what doesn't

Everything local works: all four workbenches, wiring and power, mounting, test patterns, the Live Output window, and every export your plan includes: PDF, DXF, CSV, PNG, and .ledproj project files all generate on the machine, no server involved. Your saved title blocks are kept on the machine too, so a new project still starts with your default title block with no connection.

What needs a connection:

• Opening and saving cloud projects (including cloud autosave and cloud version history).
• Creating and managing share links.
• Publishing to the organization or community library, and seeing equipment that other people have added since you were last online. Equipment you have already loaded stays available offline; see Your equipment library offline below.
• Billing and account changes.
• Signing in itself: the first sign-in on a machine must happen online. After that, your session is cached and the app opens straight into your work even with no network.

How the app knows it's really online

The desktop app doesn't trust the operating system's "connected" flag. It positively confirms real internet by pinging a lightweight health endpoint at LED.FYI (with a generic connectivity fallback), timing out after 5 seconds. The health check only counts a genuine answer from LED.FYI, so a venue Wi-Fi login page that answers every address doesn't fool it. On a venue network with a captive portal or a dead uplink (where the OS still reports "connected"), the app flips to offline behavior immediately: cached license, no hanging cloud calls, no multi-second stalls.

The web app can't do this; it relies on the browser's connectivity flag plus an 8-second timeout per cloud call, so a dead uplink feels much slower there.

Your equipment library offline

Every panel, processor, switch and card that shipped with the app is built in, so the pickers are never empty, even on a machine that has never been online.

On top of that, the app remembers the equipment it last downloaded. The extra gear your organization has published, and anything added to the community library since the app was built, is saved on the machine the first time you load it while online. Quit, reboot, or work a whole show with no uplink: it's all still in the pickers, and there's no wait for a download when you open the app.

It refreshes itself whenever you are online, so corrections and new gear reach you normally; the saved copy is only ever a stand-in for a connection you don't currently have. Two details worth knowing:

• An app update always wins. If a newer version of the app ships with newer equipment data, that data is used, not the older copy saved on your machine. Gear only your organization or the community added is unaffected; it's kept either way.
• It doesn't go stale forever. If the app hasn't reached LED.FYI in about a month, the saved copy is dropped and the pickers fall back to the equipment built into the app, rather than quietly serving month-old data. Reconnect once and everything comes straight back.

Projects you have already saved are never affected by any of this: a project file carries its own copy of the equipment it uses, so it opens correctly whatever the library is doing.

Your local project survives relaunch

(If you were working in a cloud project, relaunching reopens that one instead; see Reopening where you left off.)

The project you're working on locally (one that isn't saved to the cloud) is stored durably on the machine, with its full version history: every version you've committed, not just the latest state. Quit the app, lose power, reboot: relaunching reopens the same project at its latest committed version with the complete history intact. See Undo, redo & versions for how versions work.

Unsaved edits are covered too: work you did after your last committed version is continuously autosaved, and restored on relaunch along with the unsaved-changes indicator, so a crash right before a commit doesn't lose the edits.

One local project at a time

The machine holds one durable local project. File → New, Open, or Import replaces it (after the usual Replace confirmation) and permanently discards the previous local project's version history. Cloud projects are unaffected; their history lives in the cloud. If you need to keep the current local project, export it as a .ledproj file (Project files) or save it to the cloud first (Projects, saving & autosave).

Offline limits to know about

• Plan features follow your cached license. Paid features keep working offline through the license grace window; see the offline license for the mechanics and the timeline.
• Live usage counts aren't available offline. Checks that depend on server-side totals (like your cloud-project count) can't run without a connection, which rarely matters, since the actions they gate need connectivity anyway.
• Cloud saves need a connection. Keep working locally; when you're back online, save to the cloud as usual.