Why I am Building Atlas

I have a problem.

My operating system sees my files clearly, but shallowly. It knows names, locations, timestamps, and the basic hierarchy of folders. But the moment I rename a file or move it, that thread snaps. Nothing that depended on the old path is notified. Every file is a known object in an unknown story — and its history begins fresh every time I reorganize.

For nearly two decades my work has lived and died by this problem. I’ve built elaborate folder structures, naming conventions, and backup systems to bend the way I work to the realities of how my OS behaves. Plenty of individual programs offer their own systems for managing a project’s resources — but none of them solve this problem across every tool I use. The workarounds help, but they’re duct tape over a missing foundation.

What if…

…I could teach my computer to understand my files the way I do — to remember what a file used to be called, to know what depends on it, to recognize when two files are copies of each other?

That’s what I’m building with Atlas.

What Atlas does

Atlas adds a layer of understanding on top of your existing filesystem. It builds three kinds of knowledge your OS never had:

Identity — Atlas identifies files by their content, not their name. Rename a file and it’s still the same file. Copy it somewhere else and Atlas recognizes the copy. Edit the copy and Atlas tracks the divergence.

History — Atlas isn’t version control — it doesn’t store copies of your files at every state. But it does record every event: every rename, every move, every modification. You get a complete timeline of what happened to a file and when, without manual saves or version suffixes like final_v2_REAL.psd.

Dependencies — Atlas looks inside your project files and maps the connections between them. It knows which samples your DAW session uses, which images your website references, which textures your game scene needs. When something moves or disappears, Atlas tells you exactly what’s affected.

Your files stay exactly where they are — or you move them, rename them, reorganize them more freely than you ever could before. Atlas keeps track of it all and understands their dependencies the way you do.

How it works

Atlas runs a lightweight daemon that watches directories you specify. When files change, it:

1. Hashes the content with BLAKE3 — fast enough to process gigabytes per second.
2. Records the event — creation, rename, move, modification — in a local SQLite database.
3. Maps references between files using format-aware parsers called Packs (more on those soon).

You query your filesystem through the atlas CLI, asking questions your OS can’t answer: “What depends on this file?”, “Where did this file come from?”, “Do I have duplicates?”

Why CLI-first

I actually started building Atlas as a GUI app. I had mockups, a window, the works. But I kept getting pulled into layout decisions, icon choices, and interaction patterns — spending more time on how Atlas looked than on what it actually needed to do. The GUI was a distraction from the foundation, and Atlas is the foundation that all my work depends on. This foundation needed to be solid.

So I started over with a CLI and turned all my attention to the data model. How files are identified in Rust, how events are stored in SQLite, how the hashing captures identity across renames, how the dependency graph holds together as files change. These are the problems that determine whether Atlas actually works — and none of them have anything to do with what the interface looks like.

A GUI will come eventually. But the data model had to come first. Get that wrong and no interface can save you. Get it right and the interface is just a window into something that already understands your files.

Why local-first

That data model also needed to stay on your machine.

Your filesystem is deeply personal. It’s your projects, your documents, your creative work. A tool that maps all the connections between those files has access to a remarkably detailed picture of how you work. That data should stay on your machine.

Local-first also means Atlas is fast. No network round-trips, no API rate limits, no waiting for a server to index your files. Everything happens at the speed of your SSD, stored in a single SQLite file you own completely.

Atlas is also private by default. It automatically skips sensitive files — credentials, keys, environment files — and if you ever want to erase a file’s history entirely, atlas forget makes it permanent.

For you, your team, and your tools

Part of starting over was rethinking who Atlas is for. When I rebuilt around the data model, I realized the same foundation — content-addressed identity, event history, dependency mapping — works whether one person is tracking their files or a whole team is. The data model doesn’t care how many people are contributing. It just tracks what changed, when, and how everything connects.

It also doesn’t care what tools you use. This is where Packs come in. A sound designer working with Ableton sessions and thousands of samples across drives needs Atlas to understand different files than a web developer managing hundreds of linked assets or a game developer with a massive scene graph. Packs let Atlas speak each domain’s language, and anyone can build their own for the formats they work with.

Beyond Packs, Atlas exposes its knowledge graph through Atlas Connect — a machine-readable interface that lets AI agents, automation pipelines, and external tools query your filesystem without crawling it from scratch every time. Atlas provides the data. Your tools provide the intelligence.

And because everything lives in a single SQLite file with clear table names and self-describing metadata, your data outlives Atlas itself. Any developer could write queries against it in an afternoon. Nothing is locked in.

What’s next

The core engine of Atlas is now solidly in place and I’ve begun teaching Atlas to parse file references and map the connections between files. Soon I’ll be writing a follow-up post dedicated to how Packs work under the hood and how Atlas is built to let you add your own for the specific file formats you work with.

Follow along on the blog for deep dives, product updates, and the occasional design decision explained.

If you want to be among the first to try Atlas, join the waitlist.