Slerim

Overview

After seeing multiple developers lose access to their GitHub accounts overnight (some due to false positive bot detections, others from geo-restrictions), I built Slerim. It's not just another backup tool - it's insurance for your entire coding career. Every 6 hours, it clones all your repos, encrypts them with your own keys, and stores them safely. You keep the encryption keys, so even if my servers get compromised, your code stays private.

The Problem

In late 2023, GitHub started aggressively banning accounts they suspected of automation or suspicious activity. Innocent developers woke up to find their accounts suspended with no warning. Some lost access to years of work - private projects, client code, everything. The standard advice of "just use git locally" doesn't work when you have 50+ repos and work across multiple machines. Plus, nobody backs up regularly. I know I didn't until I had a scare myself.

The Solution

Slerim connects to your GitHub via a fine-grained PAT (read-only), pulls down all your repos every 6 hours, and encrypts them using AES-256-GCM with keys you control. The encrypted bundles go to S3 with lifecycle policies for cost optimization. You can restore any repo, any commit, any time - even if GitHub bans you or the platform goes down. The CLI takes 2 minutes to set up. No Docker, no complex config - just npm install and you're done. I'm using it myself for 80+ personal and client repos.

Technical Details

• •Backend in TypeScript/Node.js with a Fastify server for the API and dashboard
• •Bull queue system running backup jobs - each repo gets its own job to prevent cascading failures
• •GitHub API v4 (GraphQL) for efficient repo discovery, v3 for actual git operations
• •Client-side encryption in the CLI before upload - I never see your plaintext code
• •Deduplication using git's pack files to save ~70% storage on average
• •PostgreSQL tracking backup status, job history, and user quotas
• •S3 with intelligent tiering for older backups (saves about $200/mo at current scale)
• •Rate limit handling with exponential backoff and jitter - learned this the hard way
• •Restoration is just `slerim restore owner/repo` and it recreates the .git structure locally

Challenges

• •Monorepos broke the first version - some repos are 2GB+. Had to implement streaming clones with progress tracking instead of loading everything in memory. Now using libgit2 bindings directly.
• •GitHub's rate limits are brutal (5000 req/hour sounds like a lot until you're processing hundreds of repos). Built a sophisticated queuing system that predicts rate limit resets and schedules jobs accordingly. Still hit limits during peak hours sometimes.
• •Key management is tricky - users need to be able to restore even if they lose their laptop. Implemented a key splitting scheme where they can optionally store encrypted shards across multiple locations. Still working on making this UX smooth.
• •Some users have repos with huge binary files (one guy had 400GB of ML datasets committed to git). Had to add .slerimignore support and warnings for repos over 10GB. Considering adding LFS support.
• •Concurrent backups were corrupting the git bundles occasionally. Traced it to race conditions in git gc. Now running with GIT_OPTIONAL_LOCKS=0 and manually coordinating garbage collection.

Results

• •147 paying users backing up 2,847 repositories (as of last week)
• •$8.5K MRR, growing about 15% month-over-month
• •Successfully saved 3 users from GitHub account suspensions - they were able to restore everything locally within minutes
• •Zero data loss incidents in production (knock on wood)
• •Average backup completion time: 2.3 minutes for standard repos, 12 minutes for monorepos
• •Storage efficiency: 68% reduction through deduplication vs naive full clones
• •One user restored a deleted repo from 6 months ago to recover a single commit message that had a crucial password (yeah, I know). Made his day.
• •Currently handling ~4TB of encrypted repository data across 3 AWS regions