Aurora Vault

Data. Proof. Time. Without custody.

Visit Website
June 4, 2026 Why I Built a CLI Tool That Proves You Had a File

I spent two decades in IT, telecom and optics networks before moving into HSSEQ work — health, safety, security, environment, quality. Audits, compliance documentation, incident reports, chain-of-custody records. The kind of work where when something was known, and by whom, and in what state — actually matters.

Late 2025 my health forced a pause. I had time to think about what I actually wanted to do next. What came back, almost immediately, was code. I had missed it for years. The terminal. The satisfaction of something either working or not working, with no ambiguity in between.

So I started over. Updated myself on new tools, spun up some real Linux environments, got back on the nerd-train.

The first idea that came to mind was Vault.

The problem I kept running into

In HSSEQ work, provenance is everything. Not just what a document says, but when it existed, in what form, and whether it has changed. Courts care about this. Auditors care about this. Insurance investigators care about this.

The existing solutions are mostly one of three things:

Timestamps from a provider you have to trust. S3 object metadata, Google Drive version history, a database updated_at column. These prove the provider recorded something. They don't prove you had a specific file in a specific state at a specific moment — and they prove nothing if the provider is also a party to a dispute.

Hash-the-file-yourself workflows. Technically sound, practically fragile. You're maintaining your own chain, your own key infrastructure, your own verification logic. One missed step and the chain breaks. Nobody outside your own script can verify it.

Blockchain-based solutions. Heavy, expensive, slow, and mostly solving a different problem.

What I wanted was simple in concept and surprisingly hard to find: a CLI tool that takes a file, seals it with a cryptographic signature I could hand to someone else, and produces a receipt they could verify independently — without calling home to me or trusting my infrastructure.

Pipeable. Composable. Zero-knowledge on the provider side. Audit-friendly by design.

What Vault actually does

Every file you store generates an Ed25519-signed receipt. The receipt binds a cryptographic commitment to your specific file version, a timestamp, and a server signature you can verify with a public key — offline, without touching our servers.

Receipts are hash-chained into an append-only ledger. Inserting or modifying a past entry breaks the chain visibly. You can verify the full sequence any time.

The CLI is first-class. Everything pipeable:

$ vault put sensitive-doc.pdf

$ cat dump.sql | vault put --stdin --name "db-dump-2026-05"

$ vault verify sensitive-doc.pdf

$ vault get <object_id> --stdout | sha256sum

Streams are first-class too. Pipe anything through Vault and get a tamper-evident, time-chained record:

$ top | vault stream start --stdin --interval 30 --name mystream

$ vault stream start --target ./project --interval 3600 --background

$ vault stream report <stream_id>

It composes with the rest of your toolchain the way a Unix tool should.

Why I'm building more on top of it

Vault started as the thing I wanted to exist. It's also becoming the foundation layer for other tools I'm building — anything that benefits from provenance. A document that was drafted over time. A log that shouldn't be tampered with. A record that needs to survive a dispute.

The HSSEQ background is useful here. I've seen what happens when documentation integrity is questioned and there's no clean answer. Vault is my answer to that problem, built the way I'd want to use it: from the terminal, composable, independently verifiable.

It's early. Linux x86_64 and arm64 are supported today. MacOS and Windows binaries are in progress.

If you work with files that matter — legally, operationally, or just to you — take a look.

Trial is invite-based for now. Request one here.

Morten

2 Comments

  1. 1

    File provenance is such an underserved problem. The CLI approach is smart — developers trust tools they can run locally over anything cloud-based for sensitive proof. What's the primary use case driving adoption right now?

    1. 2

      Honestly, it's early so I'm watching rather than claiming. The use case I built it for is compliance and audit evidence . I've felt it when documentation integrity gets questioned and there's no clean answer.. :) But the pipeline/stream angle seems to resonate with DevOps people: vaulting build artifacts, config snapshots, anything where you need to prove state at a point in time without trusting the platform that stored it.

      While developing, "suddenly" AI can generate convincing anything, so knowing what's real and when it existed is becoming a genuine infrastructure problem i think — not just a legal one. A signed receipt that verifies offline without calling home feels like a small piece of that answer.

      Curious what your use case is. :) -- Morten/auroranode

June 2, 2026 Release

Today I released the first real public version of Aurora Vault.

It's a small CLI-first project I've been working on for quite a while: encrypted storage, signed receipts, and verifiable event history.

There is still a lot to improve, but it feels good to finally put something in front of real users instead of endlessly polishing it in private.

Looking forward to learning from feedback, mistakes, and whatever comes next.

Comment

About

Started Aurora Vault because I wanted encrypted storage with verifiable history. I also plan to reuse the same foundation in future projects where traceability, auditability and verifiable track records matter.