DataBridge Ops

The operator’s daily tool

Datacenter operators handle dozens of storage devices every shift. They plug in drives, monitor copies, verify uploads, troubleshoot failures, and keep the pipeline moving. Ops is the application they have open all day.

It connects directly to DataBridge Core on the local machine or LAN via port 9125. No cloud dependency, no browser, no login page. Launch the app, and it shows the current state of the server: which lanes are active, what devices are in the queue, what needs attention.

Every action the operator takes in Ops is logged to the audit trail. Every device state transition, every priority change, every alert acknowledgement. When something goes wrong six months later, the full history is there.

Real-time lane status

Each DataBridge Core server runs up to 5 concurrent ingest lanes. Ops connects to Core’s status endpoint on port 9125 and streams updates via a persistent connection. Lane state refreshes every second.

For each active lane, Ops shows the current phase (copying, uploading, verifying), the device label, a progress bar with percentage, real-time throughput in MB/s, and estimated time remaining. Idle lanes are visible too, so operators know immediately when capacity is available.

Ingest queue management

When multiple devices are plugged in and all lanes are busy, devices wait in a queue. Ops shows the queue in order and lets the operator rearrange it. A CFexpress card from a priority shoot can jump ahead of routine SD cards. A 4TB HDD that will take an hour can be pushed back to off-peak.

Operators can also pause and resume individual devices. If a device needs to be physically inspected before ingest, pause it in the queue without affecting everything else. When it is cleared, resume and it picks up where it was.

Guided 8-step workflow

Operators are not engineers. They handle physical media under time pressure, often across long shifts. The workflow in Ops is designed to prevent mistakes by guiding the operator through each step explicitly. No step can be skipped. Each transition is logged.

When a device is active, Ops highlights the current step and dims completed ones. If something fails at step 7 (verification), the operator sees exactly what happened, what Core is doing about it (re-uploading), and whether any action is needed on their end.

Device health and diagnostics

Every device that enters the pipeline is profiled. Ops displays the device model, manufacturer, total capacity, used space, filesystem type (exFAT, NTFS, ext4, HFS+), and serial number when available. For devices that support SMART, Ops pulls health indicators: reallocated sector count, power-on hours, temperature, read error rate.

Devices showing early signs of failure are flagged with a warning. An SD card with an unusually high error rate or an HDD with reallocated sectors gets a yellow indicator in the queue. The operator can choose to proceed with ingest (the data is still readable) or pull the device for inspection.

This matters because field teams reuse storage media hundreds of times. Catching a degrading device before it fails in the field prevents data loss at the source, where it cannot be recovered.

Alert display and escalation

Core generates alerts when something needs human attention: disk pressure on the buffer drive, a stalled upload that has not progressed in 5 minutes, a verification failure, a USB device that disconnected mid-copy. These alerts are pushed to Ops in real-time.

Each alert shows severity (critical, warning, info), a timestamp, the affected device or lane, and a description of what happened. Operators can acknowledge an alert to clear it from the active list, or escalate it, which pushes the alert to DataBridge Watch for the remote monitoring team to handle.

Works on air-gapped networks

Many datacenter environments have restricted or no internet access on the ingest network. Ops does not require internet connectivity. It communicates exclusively with the local Core daemon, either on the same machine (localhost:9125) or on the same LAN segment.

There are no external API calls, no telemetry, no update checks, no CDN-hosted assets. The entire application is self-contained in the native binary. If the operator’s workstation can reach the Core server over the local network, Ops works fully.

This was a deliberate design choice. In production deployments, ingest servers often sit on isolated VLANs where only the upload path to the cloud endpoint is routed. Ops respects that network architecture instead of fighting it.

Built with Tauri v2

Ops ships as a native application. On macOS, it is a signed .dmg. On Windows, a standard .exe installer. The binary is under 25 MB. It launches in under 2 seconds on typical hardware.

Tauri v2 gives us a Rust backend for system-level operations (USB device enumeration, filesystem access, network socket management) with a lightweight webview frontend for the UI. No Chromium bundle, no Electron overhead, no background browser processes consuming memory.

The same codebase produces both the macOS and Windows builds. Updates are distributed as new binaries through the same deployment channel as Core updates, so the operator’s console always matches the server version.

Where Ops fits in the platform

DataBridge is four modules working in sequence. Tag handles labeling in the field. Core handles ingest and upload on the server. Ops is the human interface at the datacenter, sitting between the operator and Core. Watch provides the fleet-wide view for remote monitoring.

An operator using Ops never needs to SSH into the server, read log files, or run CLI commands. Everything they need to do their job, from checking lane status to prioritizing the queue to acknowledging alerts, is in the Ops interface. The complexity stays in Core. The clarity stays in Ops.