The Problem: Cloud Dependency in Emergencies

Most modern software assumes constant internet connectivity. In normal conditions, this is fine. But emergencies are, by definition, abnormal conditions. Consider these real-world scenarios:

• Hurricane landfall — Cell towers knocked offline for days. First responders lose access to dispatch systems that require cloud connectivity.
• Rural ambulance call — No cell coverage in remote areas. Patient data, protocols, and routing unavailable when seconds count.
• Tunnel/underground fire — No radio, no cellular, no WiFi. Incident commanders working blind without local incident records.
• Concert crowd collapse — Network overloaded by thousands of phones. Hospital diversion status, bed counts, and transport tracking unreachable.
• Cyberattack on municipal infrastructure — Internet deliberately severed. Cloud-hosted CAD systems completely inaccessible.

The TPT Emergency Architecture

TPT Emergency is designed with a dual-storage, zero-external-dependency architecture. Every feature works locally. Every piece of data is stored on-device. Network connectivity is treated as a nice-to-have, not a requirement.

SQLite + IndexedDB: The Dual-Storage Strategy

The backend uses SQLite as the primary database — a single file, zero-configuration, serverless database that stores every incident, unit, resource, audit log, and configuration setting. The entire database is contained in one file that can be backed up, copied, exported to USB, or transferred between systems.

The frontend uses IndexedDB via Dexie.js as a client-side cache. When the app loads, it pulls data from the server into IndexedDB. If the connection drops, the app continues operating from the local cache. When connectivity returns, a background sync engine reconciles changes.

Service Workers & Workbox: True PWA Offline Support

TPT Emergency is built as a Progressive Web App (PWA). Workbox generates a service worker that precaches the application shell and runtime caches for dynamic content. Once installed, the app opens instantly — even with no network at all.

The service worker handles:

• Application shell caching (HTML, JS, CSS assets)
• Runtime API response caching with stale-while-revalidate strategy
• Background sync queues for POST/PUT requests made while offline
• Fallback to cached content when the server is unreachable

Background Sync Engine & Conflict Resolution

When a user creates or updates data while offline, the change is stored in an outbox queue. The service worker’s background sync API attempts to send queued changes when connectivity returns. If multiple devices made conflicting changes, a last-write-wins conflict resolution strategy applies, with full audit logging so nothing is silently overwritten.

Map Tile Offline Caching

Mapping is critical for emergency response. TPT Emergency uses MapLibre GL JS with a custom tile cache. Map tiles are downloaded on first view and stored locally. The system pre-caches tiles for operational areas so maps render instantly even without connectivity. Search & rescue patterns, hazard zones, and unit positions all display on fully offline maps.

Real-World Scenarios

Scenario 1: Hurricane Response

A Category 4 hurricane makes landfall. Cell towers are down across three counties. The Emergency Operations Centre loses internet. TPT Emergency, running on a local laptop with the SQLite database, continues to receive incident reports via local WiFi mesh. Dispatchers assign units, track resources, and log all activity. When a satellite uplink is established 6 hours later, all queued data syncs to the central server. Nothing is lost.

Scenario 2: Rural Ambulance Transport

An ambulance is dispatched to a remote mountain road — no cell coverage for 40 minutes. The paramedic opens TPT Emergency on a tablet. All protocols, hospital diversion statuses, and patient forms are cached locally. They document the patient encounter, record vitals from a Bluetooth-enabled monitor, and enter transport details. When the ambulance returns to coverage, everything syncs automatically to dispatch and the receiving hospital.

Scenario 3: Tunnel Fire Incident Command

A vehicle fire in a major tunnel cuts all communications. The incident commander, stationed at the tunnel mouth, runs TPT Emergency on a ruggedised laptop. Bluetooth beacons on each responder’s gear report their position as they move through the tunnel. The IC sees unit locations on an offline map, manages the accountability roster, and logs PAR checks. No internet required.

---

Comparison: TPT Emergency vs. Cloud-Dependent Systems

Security & Trust

Zero external connections. TPT Emergency makes no calls to third-party APIs, analytics services, or cloud platforms. All data stays within your network. This is not a feature — it’s a core design principle.

No session timeouts. Emergency dispatchers cannot afford to be logged out during a multi-hour incident. TPT Emergency disables all automatic session timeouts.

Black-start recovery. If every system fails, you can boot from a USB drive containing the static HTML build and the SQLite database file. The system is operational in under 30 seconds with zero infrastructure.

Encrypted export. All data can be exported to an encrypted file for offline backup or transfer. Import it on any other TPT Emergency instance and resume operations immediately.

Get Started

TPT Emergency’s offline-first architecture isn’t a fallback — it’s the default. Install it, disconnect from the internet, and watch everything still work. That’s the point.