Ideochrom is a free web tool I built for generating publication-ready chromosome karyotype ideograms. I don’t make money from it — if anything, I lose money. It pales in comparison to my surf fishing hobby, where lures, terminal tackle, and other gear I buy to “assure” I’ll catch something add up by the end of the season. But it’s a hobby project that genuinely helps my colleague and his lab, so I keep it running.

Part of keeping it running means occasional maintenance. In an ambitious cleanup effort, one of my goals was removing old, unneeded deployment backups that GitHub Actions had accumulated. With the help of my less-than-great Linux command knowledge, I somehow deleted files that left my DigitalOcean droplet unable to run or restart. The repository had all the source code — but I had never signed up for DigitalOcean’s weekly backups. Not ideal.

Server racks in a data center

What needed to be rebuilt

If this were an enterprise application, I’d have been in serious trouble. But I had a good friend: Claude. I knew how the application worked at a high level, had the GitHub Actions YAML, and just needed to map out what a full restore would require. Here’s what I outlined:

  • nginx configurations for dev.ideochrom.com and ideochrom.com
  • SSL setup for HTTPS via Let’s Encrypt
  • A cron job to handle monthly SSL certificate renewal
  • A background service that fetches band files from the NCBI cytogenetic data repository, with another cron job that fires monthly to check for and add any missing files
  • SSH key setup and updating the corresponding secret in GitHub’s Settings > Secrets > Actions

The recovery process

Code on a screen reflected in eyeglasses

I spun up a new DigitalOcean droplet using the same Ubuntu server image as before, opened Claude Code inside Ideochrom’s source repo, and got to work. Claude handled most of the changes inside the GitHub Actions YAML. The rebuild actually came out slightly better than what was there before — for example, deployment directories were isolated rather than reused, which reduced the risk of the same cleanup mistake happening again.

A few things I handled manually throughout the process:

  • Copied and pasted logs from failed GitHub Actions workflow runs so Claude could diagnose errors
  • Scoped all deployments during the restore to dev.ideochrom.com, so my colleague could test on his end before anything went to production
  • Created a new infrastructure/ folder with services/ and nginx/ subfolders to organize all service files, cron jobs, and nginx configurations in one place — rather than scattered across the repo as before

One constraint worth noting: I don’t give Claude access to the GitHub CLI to trigger workflows or SSH into the droplet directly. Everything infrastructure-side had to go through me.

The most important thing we did

Hands writing notes in a notebook

I had Claude generate a README documenting every step required to bring the application back online from a bare droplet. This was the most valuable output of the entire recovery. Whether the next incident is another catastrophic mistake, a planned migration to a new droplet, or a move to AKS, that document means we’re not starting from scratch — we’re handing a known playbook to Claude or any other tool and getting straight to work.

Results

The process took about 4 hours to get the application back online. Without Claude, this would have taken weeks — tasks like SSL renewal with a cron job are not in my Linux administration wheelhouse. In the end, my colleague was back to using the application, and we came out of it with better infrastructure organization and documentation than we had going in.

The lesson: keep your source code in version control, document your infrastructure as if you’ll need to rebuild it from scratch (because someday you will), and don’t run cleanup commands you’re not confident in on a production server.