The Twelve-Gigabyte Map We Did Not Deploy

The archive and the application are different products

The source archive behind the UFO disclosure map is roughly twelve gigabytes. It contains documents, images, video, audio, metadata, and release-specific source structures from the United States Department of Defense UAP archive.

The map is an interface over that archive. It does not need to become another complete archive to do its job.

Deploying every source file would create a large bundle, slow releases, duplicate government-hosted material, and transfer long-term media hosting responsibility to Devzilla. Linking everything remotely would create the opposite problem: a small source URL change could remove critical visual context from the interface.

The application therefore uses a hybrid media model.

What the deployment owns

The map bundles the twenty-four images that its interface displays directly. Those images provide stable visual context inside event and detail views. Keeping them with the application also makes the repository self-contained.

This corrected an earlier build dependency. The build script copied images and thumbnails from a parent archive directory that neither repository tracked. A clean clone could not reproduce the deployed bundle without that workstation-specific directory layout.

Moving the displayed images into the application repository removed that hidden dependency. The thumbnails were different. The application code never read the thumbnail field, so approximately seven megabytes of files traveled through every deployment without serving a user-visible purpose. That copy step and those files were removed.

What remains remote

Documents continue to link to war.gov. Video and audio continue to embed from DVIDS, the source media host used by the disclosure material.

This keeps the deploy close to twenty-one megabytes rather than twelve gigabytes. It also preserves a direct path to the primary source.

The cost is explicit: Devzilla does not control those remote files. If a government host changes a path or retires a media object, the map can still render its marker, metadata, and description while the remote media link fails. That failure must remain visible and repairable instead of being mistaken for an application outage.

Shareable state without path routing

The application stores filters and selected-event state in the URL hash. A shared map view therefore does not require a server route for every state combination.

That decision allowed the Cloudflare Worker to return real 404 responses for unknown paths. An earlier single-page-application fallback returned the home document with status 200 for every missing path, including broken assets. The hash-based state model did not need that fallback, so it was removed.

A missing application asset now fails as a missing asset. A shared map state remains a normal root-page request with a hash the browser interprets.

Keep regeneration separate from serving

The deployed repository contains everything required to build and serve the map. The larger archive repository still owns the pipeline that regenerates events.json from source material.

This is a deliberate boundary:

• The application repository can build from a clean clone.
• The public Worker can serve the complete interface without the archive.
• Regenerating the dataset requires the source archive and its extraction pipeline.
• The destination for generated event data is explicit and overridable rather than an assumed sibling directory.

The boundary keeps ordinary releases small while preserving the full source workflow where it belongs.

The general rule

Bundle the media that the interface requires to remain coherent. Link large primary-source media when another authoritative host already owns it. Record the external dependency, make broken remote media visible, and keep a reproducible local path for every asset the application itself promises to render.

Explore the UFO Disclosure Map case study or open the live map.