Skip to Main Content
Reliquary
Sign In

How Reliquary Works

The Reliquary Digital Preservation System

Reliquary stores your most important files using verified digital preservation packages inside your own secure digital vault.

A preservation package keeps your files together with the metadata and checksum records needed to understand them and verify their integrity over time. Reliquary builds one package using the open BagIt file packaging format documented by the Library of Congress, validates it, stores it in your organization’s provisioned secure digital vault, and creates temporary working copies whenever you need to access them.

Follow the Files
Four steps summarize the file lifecycle. Multiple files and folders become one BagIt package. The package is saved in VAULT with its metadata. A requested verification compares the package with its recorded SHA-256 values. When the files are needed, Reliquary creates an exact working copy for sharing and OPERATIONS while the package in VAULT remains unchanged.

01 / System

Dual-Layer Paranoid Infrastructure.

Your Vault stores the verified preservation packages containing your files, with strict deletion protection enabled. Files are never altered in the Vault without your express permission. Instead, your Operations environment holds temporary working copies for access and verification. Your Vault and Operations are provisioned uniquely to your team.

Preserve the Source. Work From a Temporary Copy.

The complete package and all of its original files stay in VAULT. Reliquary creates temporary working copies in OPERATIONS without changing the preserved package.

The source files remain visible inside their preservation package in VAULT. Reliquary can extract selected working material into OPERATIONS for access, then let that temporary material expire without changing the original package.

02 / Ingest

From Selected Files to One Preservation Package

Your files enter data/ with their folder structure intact, metadata and checksum records are added, and the finished package is validated and published to VAULT.

Start With the Files You Need to Preserve

Select the files and folders that belong together. Reliquary retains each filename and logical path throughout ingest.

Move the Same File Bytes to OPERATIONS

A scoped, resumable session sends each selected file directly from the browser to temporary storage. Reliquary manages permissions and job state without proxying the files.

Confirm Exactly What Arrived

Reliquary records the stored object’s generation, byte count, and CRC32C, then waits until every selected file is finalized.

Build One Preservation Package Around the Files

Reliquary places every selected file inside data/ under its logical path, adds package-level and file-level metadata, and writes SHA-256 manifests. The files and companion records become one BagIt preservation package, which Reliquary validates and publishes to VAULT.

The selected files move from the browser to OPERATIONS. Reliquary records each uploaded object, places the files and their companion records inside a BagIt package, validates the package, and publishes it to VAULT.

03 / Package

Open the Finished Package

The BagIt file packaging format grew from digital-preservation collaboration involving the Library of Congress, the California Digital Library, and Stanford Libraries. It keeps every selected file and folder inside data/ with its original hierarchy while metadata and checksum manifests sit beside that content. The complete package can travel and be checked without Reliquary. Its open specification is published as RFC 8493.

Every Original File Remains a File

The selected files live inside data/ under their original logical paths. The package structure does not convert their formats. It adds a standard hierarchy and companion preservation records.

Metadata That Stays Inside the Package

BagIt permits additional tag files. Reliquary uses that provision for two structured JSON files: one records package-level metadata, and the other associates file-level metadata with logical paths. Both sit inside the package boundary and outside data/, exactly where tag material belongs.

Two Manifests, Two Kinds of Coverage

manifest-sha256.txt covers every payload path. tagmanifest-sha256.txt covers the package declaration, bag information, payload manifest, and both Reliquary metadata files.

Standard Validation, Richer Interpretation

Ordinary BagIt validation software can confirm structure and checksums without interpreting Reliquary’s JSON. Reliquary-aware software can also open those files as readable package and file metadata.

The finished BagIt package opens to show all selected files and folders inside the data folder. Core BagIt tag files and two Reliquary metadata tag files sit beside them inside the same package boundary. The payload manifest covers the original files. The tag manifest covers bagit.txt, bag-info.txt, manifest-sha256.txt, reliquary-bag-metadata.json, and reliquary-file-metadata.json, but never itself.

Technical Reference

Inside the BagIt Package

bag-root/
├── bagit.txt
├── bag-info.txt
├── manifest-sha256.txt
├── tagmanifest-sha256.txt
├── metadata/
│   ├── reliquary-bag-metadata.json
│   └── reliquary-file-metadata.json
└── data/
    └── payload files and folders
  • bagit.txt declares the package version and UTF-8 tag-file encoding.
  • bag-info.txt records package facts such as bagging date and payload size.
  • data/ contains media, documentation, and the original logical hierarchy.
  • manifest-sha256.txt lists every payload file and its expected SHA-256 digest.
  • metadata/reliquary-bag-metadata.json stores structured package-level metadata as a checksum-covered tag file.
  • metadata/reliquary-file-metadata.json stores metadata associated with logical file paths as a checksum-covered tag file.
  • tagmanifest-sha256.txt covers the declaration, bag information, payload manifest, and both Reliquary metadata files.

04 / Workflows

Multiple Workflows for Complete File Management

Reliquary was built for museum-level preservation, but works for everyday simple file storage workflows as well. Optionally store files in your Vault directly, without the preservation package, or utilize the Local Bagger to create local packages.

Managed, Local, and Direct File Handling

Use Bag & Upload when Reliquary should package, validate, store, verify, and provide access to the work. Choose one of the alternatives when you need a local package or simple file storage instead.

Build the Package in Your Browser

Local Bagger accepts multiple files and folders, preserves their logical paths, applies package-level and file-level metadata, calculates SHA-256 manifests, and creates a BagIt ZIP entirely in browser memory. Your file bytes never enter Reliquary’s VAULT or OPERATIONS storage.

  • Multiple files and folders
  • Package and file metadata
  • Local SHA-256 hashing
  • Downloaded ZIP that you preserve

Use it when: the package belongs in another repository, must stay on local infrastructure, or needs to travel as a self-contained handoff.

Store Standalone Files Without Packaging

Direct Upload accepts a batch of files and folders, then stores each file as its own object in VAULT. Scoped resumable sessions send bytes directly to storage. Reliquary records the filename, logical path, size, generation, MIME type, and CRC32C for each object.

  • One stored object per file
  • Folder paths retained
  • Preview, transfer, and download
  • No manifests or package metadata

Use it when: a standalone, access-oriented file needs secure storage quickly and preservation packaging is unnecessary. Direct Upload is not recommended as the long-term preservation path.

Local Bagger takes multiple selected files, builds a BagIt package entirely in the browser, and saves the finished ZIP to the user’s device without uploading the files to Reliquary. Direct Upload sends multiple selected files to VAULT and stores each one as an independent object without a preservation package or manifests.

05 / Integrity

Integrity You Can Test

Months, years, or decades after preservation, an authorized user can ask Reliquary to recalculate SHA-256 values for the package’s payload and tag files and compare them with the values recorded when the package was created.

Compare the Package to Its Record

A visible verification request starts one scan. Reliquary compares current SHA-256 values with the exact values recorded for the package’s payload and tag files.

Keep the Dated Result

Reliquary reports a result only after every comparison completes. A dated Valid or Invalid result remains with the package record for future reference. Verification is user initiated, visible, and repeatable.

An authorized user requests verification of the package. Reliquary compares current SHA-256 values for the package’s payload and tag files with the values recorded when the package was created. Matching comparisons produce a dated Valid result that remains with the package record.

06 / Access

Access Without Disturbing the Source

Easily access your files without disturbing the original source. For operations like transfers, downloads, and validation, Reliquary leaves your completed preservation package in VAULT and creates a perfect temporary working copy in OPERATIONS. The preserved source stays fixed while you retrieve, preview, and deliver what they need.

Create a Temporary Working Copy

Reliquary extracts the selected file into OPERATIONS as a temporary working copy. The package remains anchored in VAULT throughout the configured access period.

Preview, Transfer, or Download

The copy supports browser-ready previews, expiring transfers, and fresh download URLs. Transfers can add a password, limit the access mode, and record activity. Reliquary removes the copy when its access period expires.

Preview / Transfer / Download · Password: Optional · Expiration: Configured

The original files remain unchanged inside their preservation package in VAULT. Reliquary extracts one selected file as a temporary working copy into OPERATIONS, where it can support preview, controlled transfer, or download before its configured access period expires.

07 / File Access

Preview, Transfer, or Download

When access requires temporary preparation, Reliquary handles that working material in OPERATIONS. It selects a format-aware preview, creates a controlled delivery, or issues a fresh download URL while the source in VAULT remains unchanged.

Use the File Without Rewriting It

Preview, transfer, and download are separate actions with separate controls. None of them changes the preserved source encoding or the package stored in VAULT.

Inspect More Than Browser-Native Media

Reliquary chooses a viewer from the file extension, filename, and MIME type. Common images and browser-ready audio and video open directly. Preservation media such as MXF, MOV, MKV, AVI, DV, MTS, M2TS, and BWF opens as technical inspection when native playback is unavailable. Specialized viewers cover documents, tables, 3D, scientific, medical, molecular, and spectral files.

Share Through a Controlled Link

Choose preview-only, download-only, or combined access. Add an optional password, set an expiration, and record preview and download activity. The public link exposes only the selected transfer material.

Deliver the Original Bytes

A fresh, short-lived URL delivers an individual file without becoming a permanent public address. When the complete preservation package is needed, download its ZIP with the files, metadata, and checksum records together.

A temporary file in OPERATIONS remains fixed while three separate actions are demonstrated. Preview opens a format-aware browser viewer without changing the source bytes. Transfer creates a controlled sharing token with an optional lock and expiration. Download uses a fresh short-lived URL to deliver original bytes.

Format-Aware Preview

Supported Preview File Formats

Reliquary routes these formats to native, document, data, media-inspection, 3D, scientific, or fallback viewers. A listed format may provide visual rendering, structured inspection, or technical metadata according to what the browser and file encoding support.

Images

.avif · .bmp · .gif · .ico · .jpeg · .jpg · .png · .webp · .svg · .tif · .tiff · .cog · .geotiff · .j2k · .jp2 · .jpf · .jpx · .jxl · .arw · .cr2 · .cr3 · .dng · .nef · .raf · .rw2

Audio & Video

.bwf · .flac · .m4a · .mp3 · .ogg · .wav · .avi · .dv · .m2ts · .mkv · .mov · .mp4 · .mts · .mxf · .ogv · .webm

Documents & Office

.pdf · .docx · .ods · .xls · .xlsb · .xlsm · .xlsx · .pptx · .odp · .odt · .rtf · .markdown · .md · .epub · .doc · .ppt

Text, Tables & Code

.css · .ead · .htm · .html · .ini · .js · .json · .jsonl · .log · .mets · .mods · .py · .tei · .ts · .txt · .xml · .yaml · .yml · .csv · .psv · .tsv

3D, CAD & BIM

.3dm · .3ds · .3mf · .amf · .bim · .brep · .dae · .fbx · .fcstd · .glb · .gltf · .ifc · .iges · .igs · .obj · .off · .ply · .step · .stl · .stp · .wrl

Scientific & Medical

.dcm · .mha · .mhd · .minc · .mnc · .nii · .nrrd · .ngff · .zarr · .cif · .cube · .mmcif · .mol · .mol2 · .pdb · .sdf · .xyz · .dx · .jdx · .ome.tif · .ome.tiff · .nii.gz · DICOMDIR

Any other extension, including an extensionless file, receives a safe metadata and limited text-or-hex fallback preview.

08 / Preservation Practice

Good Practice, Built Into the Work

The mechanics of storage, integrity, metadata, control, and access become most useful when a team can repeat them under everyday pressure.

Read the System by Layer

The BagIt package boundary used in born-digital preservation makes the package portable. SHA-256 manifests make its recorded state testable. Reliquary metadata stays with its context, while provider-managed geographic redundancy protects the package stored in VAULT.

  • Portable package
  • Testable integrity
  • Metadata with context
  • Geographic redundancy
  • Separate access layer
  • Visible control

Built for the Shape of Time-Based Media

A work may depend on masters, project files, software, installation instructions, technical documentation, and descriptive context. Reliquary preserves their hierarchy in one package so the files and the knowledge needed to use them travel together.

The same preservation package is shown in two ways. First, one stable package holds the content and metadata, a verification line confirms its integrity, and a separate working copy supports OPERATIONS. Next, the package opens to show master media, project files, software, installation instructions, technical documentation, and descriptive context as parts of one time-based media work.