potatoqualitee/eol-dr: a crowd-sourced checklist for the tech you leave behind
🕊️ A crowd-sourced guide to help techs help their non-tech spouses / partners / parents / kids when we are at the end-of-life
At a glance
- What is it?
- eol-dr is a markdown checklist, plus a GitHub Action that regenerates it as a Word document, for engineers who want their non-technical partner to survive their homelab. It is a document, not software, and that is the whole point.
- Who is it for?
- Adopt eol-dr if you own infrastructure at home or in the cloud that another person depends on and cannot administer: the checklist is the cheapest artifact you will ever produce for that person. Do not adopt it if you want an automated inventory tool, a password manager or a dead-man switch, because the repository contains none of those.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 63 days ago.
- What is it written in?
- GitHub does not report a main language for this repository.
Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The problem eol-dr names: the homelab outlives its admin
Most disaster planning for engineers assumes the company survives and the person is gone. eol-dr inverts that. The README tells the story of Andy, a VDI engineer the author worked with in Belgium, who died unexpectedly. The question that started the project was blunt: what about his homelab? The README quotes his widow saying that six months on she avoids his office at all costs and worries what happens when her TV or wifi stops working. That is the failure mode eol-dr targets. Not data loss, not downtime, but a surviving partner who cannot get an IP address because the DHCP server was a machine in the spare room, and who finds the idea of calling for help torturous. The audience is narrow and specific: the person in a household who runs the router, the DNS, the storage array, the Azure subscription and the bank accounts, and who has a partner or parent or child who depends on all of it without knowing how any of it works. The README frames the same problem from the other side too, asking who would close your Azure accounts and who should get the PureStorage array.
What is actually in the repository: one checklist, two formats
The repository is small. The top level holds .github/, CONTRIBUTING.md, LICENSE, README.md, checklist.docx and checklist.md. The README states the relationship between the two checklist files plainly: checklist.md is the markdown source, and checklist.docx is generated by a GitHub Action. That means the Word document is a build artifact, not a separately edited file, and the README says the Word doc is regenerated for others once a pull request is approved. The intended workflow is therefore GitHub-native: you read or copy the markdown, you fill in your own copy by hand, and if you think the shared checklist is missing something you open a pull request. The README describes the author's own use: within hours of the conversation that started the project, a Word document was created, printed out, a couple of passwords were filled in manually, and the result was stored in a fireproof bag. That detail matters more than it looks. The project's own recommended storage medium is paper in a fireproof container, not a vault, not an encrypted archive. The digital artifact exists to be printed.
The checklist is a document, so treat it as one
There is no runtime here. No daemon, no agent, no schema you can validate against, no API. The repository's primary language is not stated, and the top-level entries contain no source tree, which is consistent with a project whose deliverable is prose. This has a direct consequence for anyone evaluating it: you cannot test eol-dr, you can only read it and decide whether the questions it asks match your life. The README says the initial draft was written for the author's own wife and then crowdsourced, and that the author originally planned a gist before a friend suggested GitHub so pull requests would be possible. The whole contribution model is review of text. If you were hoping to point a scanner at your network and have the checklist fill itself in, this is the wrong project and the README does not pretend otherwise.
Getting the checklist and putting it to work
There are no install steps in the README, because there is nothing to install. The project says to get the checklist in one of two formats, both linked from the README: the markdown file and the docx generated by the GitHub Action. The practical first move is to clone the repository and read checklist.md, or download checklist.docx if you would rather work in a word processor. The commands below are ordinary git usage against the repository, not project-specific tooling.
git clone https://github.com/potatoqualitee/eol-dr.git
cd eol-dr
ls checklist.md checklist.docx CONTRIBUTING.md LICENSEAfter the clone you should see both checklist files listed alongside CONTRIBUTING.md and LICENSE. Open checklist.md in an editor and work through it against your own setup. The README's example of finishing the job is deliberately low-tech: print the document, fill in the sensitive values by hand rather than typing them into the file, and store the paper in a fireproof bag. If you decide the checklist itself is missing a question, the contribution path is a pull request, and the README notes the docx is regenerated once that change is approved.
Where eol-dr stops, and where you need something else
The README is honest about scope in the only way that counts: it links to other resources rather than absorbing them. It lists In Case You Get Hit by a Bus, a book on organizing personal and business information; The Next of Kin box, a fireproof physical box with a checklist for critical documents; Rememory, described as a digital safe with multiple keys designed for non-techies where information can be split among trusted contacts and recovered after a tragic event; and Evergreen Blogs, a collection of personal blogs with timeless content. That table is effectively a statement of the project's own limits. eol-dr tells you what to write down. It does not store secrets, does not split them among custodians, and does not give you a recovery mechanism. The author's own answer to the storage problem was a printed page in a fireproof bag, which is a deliberate choice and also a boundary: if you need cryptographic recovery by multiple people, the README points you at Rememory instead. The other real limitation is maintenance of your own copy. Nothing in the repository will notice that you changed banks, moved DNS providers or replaced the storage array. A stale checklist is worse than none, because it sends a grieving person to the wrong account.
Alternatives, and how each differs in approach
The closest alternative in the README's own list is Rememory, and the difference is architectural rather than stylistic. Rememory is software: a digital safe with multiple keys, aimed at non-techies, where information is split among trusted contacts and recovered after a tragic event. eol-dr is a questionnaire. One gives you a mechanism with a recovery path; the other gives you a prompt that you answer in your own handwriting. The Next of Kin box is the physical counterpart, a fireproof box with its own checklist for critical documents, which overlaps with eol-dr's recommended storage but not with its content. In Case You Get Hit by a Bus is broader, covering personal and business information organization as a book rather than a repository you can fork. Evergreen Blogs is not really an alternative at all; it is included as a reminder about preserving digital legacies. The honest comparison is this: if your problem is 'I do not know what to write down', eol-dr is the cheapest starting point. If your problem is 'I need my partner to be able to recover a secret without me', eol-dr does not solve it and the README says so by pointing elsewhere.
Maintenance, contribution and licensing
The repository is not archived, and the last push was on 2026-07-29. Contribution goes through pull requests, with CONTRIBUTING.md at the top level and a .github/ directory that holds the Action generating checklist.docx. That means the maintenance cost to you as a user is near zero and the maintenance cost to the project is editorial: every accepted change regenerates the Word document for everyone. The LICENSE file exists at the top level, but the licence it contains is not stated in the README, so check that file directly before you reuse the text in your own materials or redistribute the docx. Nothing here is legal advice, and a document that asks you to record account numbers and passwords raises questions a licence does not answer: where the filled-in copy lives, who can read it, and what happens to it after the event it was written for.
Editorial conclusion
Adopt eol-dr if you own infrastructure at home or in the cloud that another person depends on and cannot administer: the checklist is the cheapest artifact you will ever produce for that person. Do not adopt it if you want an automated inventory tool, a password manager or a dead-man switch, because the repository contains none of those. Before you fill anything in, read checklist.md end to end, then open a pull request against it if your situation is missing, since the maintainers say the Word document is regenerated only after a change is approved.
Frequently asked questions
What does eol-dr mean?
The README expands it as End-of-life Disaster Response. It is a crowd-sourced checklist, in markdown and Word formats, for helping a non-technical spouse, partner, parent or child deal with the technology and accounts you leave behind.
Is eol-dr software I install, or just a document?
It is a document. The repository's top level holds README.md, checklist.md, a generated checklist.docx, CONTRIBUTING.md and a LICENSE, with no application source. The only automation mentioned is the GitHub Action that regenerates the Word document after a change is approved.
How do I get the eol-dr checklist in Word format?
The README links both formats: checklist.md for markdown and checklist.docx, which the README says is generated by the GitHub Action. The docx is a build artifact of the markdown, so the markdown is the version to read first.
Can I suggest something that is missing from the eol-dr checklist?
Yes. The README asks readers to submit a pull request, pointing at CONTRIBUTING.md, and states that upon approval the Word document will be regenerated for others.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/potatoqualitee-eol-dr)