TL;DR
- A non-developer manages 25 servers entirely through markdown documentation and Claude Code
- When a server died from hardware failure, full reconstruction took only 90 minutes using documented procedures
- Key approach: One markdown file per server with purpose, IP, ports, services, configs, and troubleshooting history
- Best for: Business owners who accumulated infrastructure over years without proper documentation
- Key insight: Documentation is externalized expertise—you don’t need to be a sysadmin when Claude can read your docs
Claude Code transforms markdown documentation into a living IT department—enabling non-developers to manage complex infrastructure through text files alone.
Marcus made a confession that shocked his tech friends.
“I stopped using pretty much any GUI-based tool. My entire network config is now in markdown files.”
Twenty-five servers. Multiple services. Complete infrastructure documentation. All managed through text files and Claude Code.
Marcus wasn’t a developer. He was a small business owner who’d accumulated servers over the years — website hosting, email, file storage, backup systems. Each server had been set up by different contractors at different times. The configurations lived in scattered notes, lost emails, and tribal knowledge that only existed in his head.
“If I got hit by a bus, no one could reconstruct any of it.”
The Documentation Problem
Managing infrastructure without documentation is terrifying.
Server A needs port 443 open. Server B requires a specific SSL configuration. Server C has a cron job that runs at 3 AM. None of this was written down anywhere coherent.
“I had sticky notes on my monitor. Screenshots saved to random folders. Configuration files I’d never revisit. If something broke, I’d spend hours trying to remember how it was supposed to work.”
Professional sysadmins use documentation tools. Version-controlled configs. Infrastructure-as-code. But those tools assumed knowledge Marcus didn’t have.
The Markdown Discovery
Marcus started using Claude Code for simpler tasks — organizing files, processing documents. Then he had a thought.
“What if I documented my servers in markdown files? And what if Claude could help me keep them accurate?”
He created a folder called infrastructure/. Inside, a markdown file for each server:
infrastructure/
├── server-web.md
├── server-email.md
├── server-backup.md
├── network-overview.md
└── common-procedures.mdEach file contained everything about that server: purpose, IP addresses, ports, services running, configuration details, troubleshooting history.
The Living Documentation
The documentation came alive through Claude.
“When I needed to check something about a server, I’d ask Claude: ‘What’s the SSL configuration on the web server?’ Claude would read the markdown file and tell me.”
Better than that — Claude could help update documentation.
“I changed the firewall rules on server B. I’d tell Claude: ‘Update server-backup.md to reflect that port 8443 is now open for remote backup connections.’ Claude would edit the file, adding the change and a timestamp.”
The documentation stayed current because updating it took seconds.
The Reconstruction Test
Marcus tested his system. Could he actually rebuild a server from the documentation?
“I spun up a blank VPS. Asked Claude: ‘Read server-web.md and guide me through recreating this server from scratch.’”
Step by step, Claude walked him through the setup. Install these packages. Configure nginx this way. Set up SSL with these parameters. Enable these services.
“Two hours later, the server was running identically to the original. From markdown documentation. That I maintained myself.”
The bus-test was passed. If Marcus disappeared, someone with Claude Code could rebuild everything.
The Network Map
Individual server docs were valuable. But infrastructure is interconnected.
Marcus created network-overview.md — a high-level map of how everything connected.
“Which server talks to which. What depends on what. The flow of data from user request to database to response.”
When troubleshooting issues, he’d start there.
“Claude, based on network-overview.md, if users can’t access the website, what are all the potential failure points?”
Claude would trace the path: DNS, load balancer, web server, application server, database. Each hop a potential culprit.
“It turned debugging from ‘random guessing’ to ‘systematic elimination.’ Because the system was documented.”
The Procedure Library
Routine tasks got documented as procedures.
common-procedures.md contained step-by-step instructions:
- How to restart the email server safely
- How to add a new user to the backup system
- How to renew SSL certificates
- How to roll back a failed deployment
“I’d do a task once, document it immediately with Claude’s help, then never have to figure it out again.”
When the task needed doing months later, he’d ask: “Claude, walk me through the SSL renewal procedure from common-procedures.md.”
The expertise was captured, not lost.
The Version Control Insight
Marcus learned about Git from developer friends. Not to write code — to track changes.
“Every change to my infrastructure docs gets committed with a message. ‘Updated firewall rules for backup server.’ ‘Added new cron job documentation.’”
If something broke after a change, he could see exactly what was modified.
“Claude, show me all changes to infrastructure files in the last week.”
Git log revealed the timeline. Often, the bug correlated directly with a recent change.
The Automation Bridge
Documentation enabled automation.
Marcus couldn’t write bash scripts. But Claude could — based on his documentation.
“I’d say: ‘Based on common-procedures.md, write a script that does the nightly backup verification.’ Claude would generate a script that followed my documented procedures.”
He’d review the script, test it, then schedule it. The documentation became executable.
“My markdown files turned into automation specs without me knowing how to automate.”
The Disaster Recovery
The real test came when a server died.
Hardware failure. Unrecoverable. The web server that ran his main business was gone.
“Old Marcus would have panicked. Hours of scrambling. Calling old contractors. Praying someone remembered the configuration.”
New Marcus had documentation.
“I spun up a new server. Pointed Claude at server-web.md. Asked for guidance through the reconstruction.”
Ninety minutes later, the website was back online. Running on new hardware. Configured identically to what was lost.
“That’s when I knew the system worked. Not during normal operations. During a crisis.”
The Scaling Story
As the business grew, infrastructure grew with it. New servers. New services. New complexity.
Each addition got documented immediately.
“Before I’d configure a new server, I’d create its markdown file. Document what it should do, how it should connect, what it depends on.”
The documentation grew alongside the infrastructure. Twenty-five servers worth of knowledge, searchable and queryable.
“I can ask Claude: ‘Which servers would be affected if the database server went down?’ It reads all the docs and gives me the dependency chain.”
The Non-Expert Reality
Marcus emphasized his lack of traditional expertise.
“I don’t know Linux administration deeply. I can’t debug networking issues from first principles. I don’t understand every configuration option.”
But he didn’t need to.
“I documented what works. When something breaks, I ask Claude to compare current state against documentation. The delta is usually the problem.”
The documentation was his expertise, externalized and preserved.
The Recommendation
For others managing infrastructure they didn’t fully understand:
“Start documenting. One markdown file per system. Purpose, configuration, connections, procedures.”
The initial documentation took time. But the ongoing maintenance was trivial — just describe changes as you make them.
“And keep them in one folder Claude can access. That folder becomes your IT department. Your institutional memory. Your disaster recovery plan.”
The Current State
Marcus’s infrastructure folder has grown to fifty files.
Every server documented. Every procedure recorded. Every configuration preserved.
“I can rebuild my entire business infrastructure within an hour if I had to. From markdown files. That I maintain myself. As a non-developer.”
The chaos was tamed. Not through expertise, but through documentation that Claude made easy to create and use.
