DevLog #0: legacyctl - An Open Source Platform for Posthumous File Distribution

Background

A few months ago, I remembered I was going to die someday. More specifically, I thought about what would happen afterwards. After my dad passed away a couple of years ago, I ended up having to sift through swathes of the unsorted CAD files, saved emails, and other little random .txts he apparently kept in an unsorted, all-purpose folder on his desktop to find some important tax documents and just to see if there was anything relevant or worth keeping. Recently, the thought of how I want to pass on my own digital legacy struck me. Maybe I’m weird but I guess I’ve been kind of semi-consciously weighing whether or not someone looking through my hard drives after I died would find a given file useful or even amusing to find when deciding whether or not to delete it.

The idea of putting some kind of plan in place for that eventuality led me to start a new Google account specifically to create a designated Google Drive to be shared with a select group of people should anything… unexpected come to pass. Their inactive account manager feature is made specifically for this purpose. This works great for a quick and easy solution but it has its limitations. The most immediate one for me was that designated recipients received download links for the entire Drive, but what if I wanted to personalize what each person received and didn’t necessarily want every recipient to get everything? What if I also wanted to be able to trigger a webhook to make sure that some action I wanted to occur after I passed took place? Google’s “dead man’s switch” mechanism is fairly robust since I’m constantly interacting with Google services but what if I wanted something platform independent? Or what if I wanted to go crazy and add in some biometric readings from a FitBit or something that could tell the service that I’m still alive, just incapacitated and unable to log into Google for whatever reason? I just wanted more control over the who, what, when, and where of it all.

Thus, legacyctl — an open source, modular, self-hostable digital legacy platform, designed from the ground up to provide a flexible solution to posthumous file distribution and management.

At its core, the idea is simple: define who should get what, under what conditions, and let the system handle the rest. The system checks in on you in whatever way you configure and if it determines that you’ve likely passed, it informs your designated recipients and gives them access to the bundles of files you wanted them to have.

Core Concepts

Dead Man’s Switch

As the name implies, this system’s job is to make the final call on whether or not you’re still alive. It then sends out a trigger which can be mapped to any actions you like, but by default it sends emails (formatted with customizable templates) to your designated recipients with instructions on how to download whichever file bundles you wanted them to have.

Bundles

A bundle is a secure package of files intended for posthumous delivery. Bundles can be:

• Composed of any combination of files and/or folders in your storage drive

• Defined via an admin portal interface or the CLI

• Associated with one or more recipients

In a nutshell, a bundle is just a specified set of files or folders that reside in whichever storage solution you’ve configured.

Recipients

Recipients are people you want to receive data. Each recipient:

• Has a name and contact method (usually email)

• Can be assigned specific bundles

• Can be assigned a specific message template

They receive access only if the associated trigger fires.

Executors

Executors are others who you want to give access to the admin portal. Their permissions can be edited to allow (or disallow) them to:

• Modify bundle contents

• Update bundle assignments

• Manually trigger actions

Think of them as posthumous data stewards.

Plugin System

The system is designed to be pluggable at key points:

• Storage Adapters: S3, MinIO, local disk

• Job Queue Adapters: BullMQ, RabbitMQ, simple cron

• Trigger Plugins: Dead man’s switch, webhook listener

• Action Plugins: Email, SMS, webhook

This makes it easy to swap providers or extend the system for custom use cases.

Security & Audit

All actions are:

• Logged for auditing

• Optionally encrypted

• Rate-limited and access-controlled

• Designed for privacy and traceability

Current Status

The project isn’t quite off the ground yet. I’ve initialized the repo, added TypeScript, set up a dev container with Node, and Postgres and begun drafting the core schema and plugin interfaces. Nothing works yet — but it’s starting to take shape.

The plan is to build out the MVP as a monorepo with:

• A CLI for setup, bundle management, and recipient assignment

• A job processor to handle trigger conditions

• Adapters for storage, job queue, triggers, and actions

• A simple admin UI to manage bundles, recipients, and audit logs

• A recipient-facing portal to download assigned data

Everything is built to be extensible — want to use RabbitMQ instead of BullMQ? Go for it. Swap SendGrid for SES? Easy. Add a FitBit integration? Fantastic!

Next Steps

This week I’m working on:

• Finalizing the data model with Prisma

• Defining the adapter interfaces for storage, job queuing, trigger plugins, and action plugin

• Building out the skeleton for a CLI

Closing Thoughts

This project is personal, but I know I’m not the only one thinking about digital legacy, data ownership, or trigger-based automation. I’ll be posting weekly updates as I build — raw progress, architectural choices, mistakes, lessons learned, maybe even a demo or two along the way.

If that sounds interesting, follow along here or on GitHub. The code will be open from day one.

🔗 Check it out on GitHub

💬 Questions, ideas, or just want to say hi? Drop a comment!