Digital Will for Developers: A Sysadmin's Guide

Developers and sysadmins accumulate a unique category of digital assets that standard estate planning does not address. Your SSH keys, API tokens, infrastructure credentials, CI/CD pipelines, DNS configurations, and server access represent real operational and financial value --- and unlike a bank account, there is no institution your family can call to recover access.

If you manage servers, maintain open-source projects, run infrastructure for clients or employers, or hold cryptocurrency, you have digital assets that require explicit succession planning. This guide covers what those assets are, why they are different from consumer accounts, and how to organize them into a digital will that your successor can actually use.

Why Developers Need a Different Approach

Standard digital estate planning advice focuses on consumer accounts: email, social media, banking, subscriptions. For developers, the critical assets are different in three ways.

Access is credential-based, not identity-based. Your bank will eventually grant your executor access with a death certificate. Your VPS provider might. Your self-hosted Gitea instance running on a Hetzner server will not --- it requires the SSH key or root password. No legal document substitutes for the actual credential.

Assets have operational dependencies. If you run a client's website on a server only you can access, your death creates an operational emergency for the client. The server keeps running, the domain keeps resolving, but when the TLS certificate expires or the server needs a patch, nobody can intervene. The clock starts ticking immediately, not when probate begins.

Some assets are ephemeral by design. API tokens expire. OAuth tokens need refreshing. SSL certificates have expiry dates. A static list of credentials written once and never updated becomes useless faster than a list of bank accounts.

Inventory: What Developers Need to Document

SSH Keys and Server Access

Your SSH keys are the master credentials to your infrastructure. Document:

• Where your private keys are stored. Local machine paths, hardware security keys (YubiKey), or key management services.
• Which servers each key accesses. Map key fingerprints to server hostnames and IP addresses.
• Root or sudo access. Which servers you have root access to, and how to escalate privileges.
• Non-standard SSH configurations. Custom ports, jump hosts, ProxyCommand chains, SSH config file locations.
• Key passphrases. If your SSH keys are passphrase-protected (they should be), your successor needs the passphrases.

A practical format:

Server: prod-web-01 (203.0.113.10)
SSH Key: ~/.ssh/id_ed25519_prod (passphrase in will)
User: deploy (sudo access)
Port: 2222
Jump Host: bastion.example.com (same key)
Purpose: Production web server for client X
Action on death: Transfer to [successor name], or notify client X

API Tokens and Service Credentials

Document every API token and service credential you hold, including:

• Cloud provider credentials. AWS IAM keys, GCP service account keys, Azure credentials, DigitalOcean tokens, Hetzner API tokens, Linode tokens.
• Domain registrar access. Namecheap, Cloudflare, Google Domains, Route 53 credentials.
• DNS provider access. Cloudflare, Route 53, or whichever service manages your DNS zones.
• Container registry credentials. Docker Hub, GitHub Container Registry, private registries.
• Monitoring and alerting. Datadog, Grafana Cloud, PagerDuty, Uptime Robot credentials.
• CI/CD service credentials. GitHub Actions secrets, GitLab CI variables, CircleCI contexts.

For each credential, note:

• Where the credential is stored (password manager, environment variable, secrets manager)
• What it provides access to
• Whether it expires and when
• What to do with it (transfer, revoke, or let expire)

Infrastructure as Code

If you manage infrastructure with Terraform, Pulumi, Ansible, or similar tools:

• Where are the state files? Terraform state files are the source of truth for your infrastructure. If they are in S3, document the bucket and access credentials. If they are local, document the file path.
• Where is the IaC repository? Document the Git repository location and access credentials.
• What are the provider credentials? IaC tools need cloud provider credentials to operate. Document where these are stored and how to configure them.
• Are there manual resources? Resources created outside IaC (click-ops) should be documented separately since they will not appear in state files.

Domain Names and DNS

Domain names are among the most operationally critical assets. An expired domain can be registered by squatters within hours.

For each domain:

• Registrar and login credentials
• Expiration date and auto-renewal status
• DNS provider (if different from registrar)
• Critical DNS records --- especially MX records, CNAME records for services, and any records with low TTLs that indicate active configuration
• DNSSEC status and key material
• Transfer lock status

Priority note: domains should be at the top of your successor's action list. If auto-renewal is enabled and the payment method is valid, there is a grace period. If not, domain recovery becomes urgent.

Cryptocurrency and Digital Financial Assets

Cryptocurrency is the most commonly discussed developer digital asset for estate planning, and for good reason: loss is permanent and total.

• Hardware wallet locations and PINs
• Recovery seed phrases (the 12 or 24 words that can reconstruct a wallet)
• Software wallet locations and passwords
• Exchange account credentials
• DeFi protocol positions --- which chains, which protocols, which contract addresses
• Multi-signature wallet configurations --- who are the other signers, what is the threshold

Never store recovery seed phrases digitally unless they are encrypted with a strong, separately stored key. BAP's encrypted document storage with Shamir's threshold recovery is designed for exactly this use case --- the seed phrase is encrypted, and multiple trusted people must cooperate to decrypt it.

Open-Source Projects

If you maintain open-source projects:

• Repository access. Who else has write access? If you are the sole maintainer, consider adding a co-maintainer now.
• Package registry credentials. npm, PyPI, crates.io, and other registries where you publish packages. Who should take over publishing?
• Signing keys. GPG keys used for commit signing or release signing.
• CI/CD secrets. Deployment tokens, API keys, and other secrets stored in CI/CD pipeline configuration.
• Domain and hosting. If the project has a website or documentation site, document the hosting and domain configuration.

For significant projects, document your wishes: should the project be archived, transferred to another maintainer, or continued by a specific person?

Client and Employer Infrastructure

If you manage infrastructure for clients or employers as a contractor or freelancer:

• Which clients depend on your access? List every client whose infrastructure you can access.
• What access do you hold? Server access, cloud console access, domain management, DNS control.
• Who should be notified? Each client needs to be informed so they can rotate credentials and establish alternative access.
• Is there a bus factor problem? If you are the only person with access to a client's production infrastructure, that is a risk that should be addressed while you are alive, not after.

Document enough information for your successor to notify each client and facilitate credential rotation. Your successor does not need (and should not have) direct access to client infrastructure --- they need to know who to contact.

Organizing Your Developer Digital Will

Structure by Priority

Organize your digital will by urgency of action:

Immediate (within 48 hours):

• Client notification --- clients with sole-access infrastructure need to know immediately
• Server monitoring --- ensure critical servers continue to be monitored
• Domain auto-renewal verification --- ensure payment methods are valid
• Cryptocurrency security --- ensure hardware wallets are physically secure

Short-term (within 2 weeks):

• Cloud provider account access transfer or closure
• DNS management transfer
• CI/CD pipeline credential rotation
• Package registry access transfer

Medium-term (within 3 months):

• Open-source project succession
• Personal server decommissioning or transfer
• Subscription cancellation for development tools

Structure by Access Method

Group credentials by how your successor will access them:

In the digital will itself (encrypted by BAP):

• SSH key passphrases
• Master passwords for password managers
• Cryptocurrency recovery phrases
• One-time recovery codes for critical accounts

In your password manager (referenced by the will):

• Service-specific credentials
• API tokens
• Cloud console passwords

In physical storage (referenced by the will):

• Hardware security keys (YubiKey)
• Hardware wallets
• Printed recovery codes

The digital will serves as the index and master key. It tells your successor where everything is and provides the credentials needed to access the other storage locations.

Setting Up BAP for Developer Assets

Burning Ash Protocol's architecture maps well to the developer succession problem.

Encrypted Document Storage

Store your infrastructure documentation as encrypted documents in BAP. This includes:

• A master inventory document listing all assets, credentials, and action items
• Server access documentation with SSH configurations
• Client contact information and infrastructure summaries
• Instructions for your successor (what to do, in what order, who to contact)

These documents are encrypted with AES-256-GCM using a per-will Data Encryption Key, which is itself encrypted by the Master Key.

Threshold Recovery for High-Value Secrets

Use Shamir's Secret Sharing to protect your highest-value secrets. For a developer, this might be:

• Cryptocurrency recovery phrases
• Root credentials for critical infrastructure
• Signing keys for high-impact open-source projects

Configure the threshold based on your trust model. A 2-of-3 split between your spouse, a trusted colleague, and your lawyer ensures that no single person can access your most sensitive credentials alone, while any two of them can cooperate in an emergency.

Multi-Channel Notifications

Configure BAP with multiple notification channels. Your Survivors should be reachable through at least two independent channels. For developer-oriented Survivors (colleagues, co-maintainers), Telegram or email may be appropriate. For family members, SMS or WhatsApp may be more reliable.

Liveness Check Configuration

For developers who travel, work irregular hours, or go off-grid for periods, configure generous liveness check parameters:

• HCIT (Check-In Interval): Weekly or bi-weekly
• HCRT (Response Time): 48-72 hours
• HCRAC (Miss Threshold): 3-4 consecutive misses

This configuration means the switch triggers only after 3-4 weeks of total non-responsiveness, reducing false positives from vacations, intensive work periods, or intentional digital detoxes.

The Bus Factor Problem

Everything in this guide addresses what happens after you die. But the same vulnerabilities exist if you are simply unavailable: hospitalized, in an accident, or unreachable in a remote location.

The developer community calls this the "bus factor" --- how many team members can be hit by a bus before the project is unrecoverable? For your personal infrastructure, your bus factor is one.

A digital will is one solution, but the better solution is to increase your bus factor while you are alive:

• Share access with a trusted colleague. For critical client infrastructure, ensure at least one other person has access.
• Use team-based credentials. Where possible, use role-based access rather than personal credentials. AWS IAM roles, GCP service accounts, and similar mechanisms allow access to be granted and revoked without sharing personal credentials.
• Document your infrastructure. Even without a dead man's switch, your infrastructure should be documented well enough that a competent replacement can take over.
• Automate what you can. Infrastructure managed by Terraform is infrastructure that another person can manage with the state file and provider credentials. Infrastructure managed by SSH-and-prayer requires your specific knowledge to maintain.

A digital will is a safety net. Reducing your bus factor while you are alive is the first line of defense.

Maintenance Schedule

Developer digital assets change more frequently than consumer accounts. Set a quarterly maintenance schedule for your digital will:

Quarterly review:

• Verify all documented credentials are still valid
• Add new servers, services, or credentials acquired since the last review
• Remove decommissioned resources
• Update client contact information
• Test that your Survivors can be reached through configured notification channels

Annual review:

• Full end-to-end test of the will transfer process (with a test Survivor)
• Review and update the prioritized action list
• Verify domain auto-renewal and payment methods
• Update cryptocurrency positions and wallet documentation
• Review open-source project succession plans

Conclusion

Developers and sysadmins carry a unique burden of digital assets that standard estate planning ignores. SSH keys, API tokens, server access, domain names, and infrastructure credentials represent real operational and financial value, and they require explicit documentation, secure storage, and a reliable trigger mechanism to ensure your successor can act when needed.

A digital will system like Burning Ash Protocol, with encrypted document storage, threshold key recovery, and configurable liveness checks, provides the technical infrastructure to solve this problem. But the technology is only as good as the documentation you put into it. Take the time to inventory your assets, write clear instructions, and test the recovery process. Your future successor --- and your clients, colleagues, and family --- will be grateful that you did.