The Solo Dev's Automation Arsenal: From Git Commit to Social Post, Zero Manual Effort
Table of Contents
Last night, I was fixing a rate limit bug.
After the fix, I ran git commit and went to sleep.
This morning, I woke up to find a new post had automatically appeared in our Discord #build-log channel, describing in detail what I'd done and why it mattered. A public version had also been posted to Threads.
I never manually posted a single thing.
This is the system I built over the weekend: Dev-to-Social Pipeline, from git commit to social media post, fully automated.
Why Build This
The biggest contradiction of running a solo business: you're both the engineer and the marketer.
At the end of every workday, you know you should post a "build in public" update sharing what you accomplished. But you're exhausted, and the last thing you want to do is open Threads and write something.
The result: you ship a lot, but nobody knows about it.
The problem I wanted to solve is simple: make the development process itself the source of marketing content.
Architecture: Three Layers of Automation
Layer 1: Dev-to-Social (every 2 hours)
Monitor 3 Git repos → detect new commits
→ Filter: only feat: commits get published
→ AI Agent generates two versions: Discord (developer tone) + Threads (general audience)
→ Auto-publish to Discord #build-log + Threads
Layer 2: Nightly Auto-Commit (every night at 23:30)
Scan 3 repos → find blog posts written today
→ Whitelist filter (only commit content/blog/*.md)
→ Auto commit + push
→ Triggers Layer 1 detection
Layer 3: Security Safeguards
Blacklist: files containing secret/key/token/proposal are always rejected
Whitelist: only .md files in the blog directory get auto-committed
Nothing new that day → zero action
The entire flow: write code, commit, social media updates automatically. No manual intervention required at any point.
The Most Dangerous Part: Security
The scariest thing about automation isn't "it didn't post," it's "something that shouldn't have been posted got posted."
My repos contain:
.envfiles (API keys)pitch-deck/client proposalscontent/coco-proposal-internal.mdinternal pricing
If the nightly auto-commit blindly ran git add -A, all of this would get pushed to GitHub.
So I designed a two-layer defense:
Whitelist: Only content/blog/*.md files are auto-committed. Any other path (.tsx, .ts, .json) gets skipped entirely.
Blacklist: Even within the whitelist, filenames containing secret, key, token, password, proposal, or pitch are always rejected.
Dry-run test results: 50+ changed files in the repo, only one blog post passed. Everything else was blocked.
✅ SAFE: content/blog/gemini-billing-trap.md
❌ BLOCKED by blacklist: .env.prod.tmp (matched: .env)
❌ BLOCKED by blacklist: ULTRAPROBE_API_KEY.txt (matched: key)
❌ BLOCKED by blacklist: content/coco-proposal-internal.md (matched: proposal)
❌ BLOCKED by blacklist: pitch-deck/ (matched: pitch)
❌ BLOCKED by whitelist: src/App.tsx (not in safe patterns)
❌ BLOCKED by whitelist: api/notify.ts (not in safe patterns)
... 44 more files blocked
What about nights when nothing happened? git status shows no changes, so the script exits immediately. Zero action.
Bonus: Fixed a Security Vulnerability Along the Way
While building this system, I ran a security audit on the site (since I planned to submit it to Hacker News).
The finding: the contact form API endpoint had no rate limiting.
That meant anyone could write a loop hitting my contact form 1,000 times per second, draining my Telegram notification quota and Resend email limits.
The fix:
- Rate limiting: max 5 submissions per IP per hour
- Server-side validation: name/email/service required + length limits
- HTML sanitization: prevent malicious HTML injection into my Telegram notifications via the form
This vulnerability is unlikely to be exploited under normal circumstances, but if your site hits the Hacker News front page... you know what happens.
Dev-to-Social Content Generation Logic
Not every commit deserves a social post. My filtering rules:
| Commit Type | Action |
|---|---|
feat: prefix |
Always post (new features are newsworthy) |
fix: + security/critical |
Post (war stories have value) |
fix: routine fixes |
Skip |
chore:, docs:, etc. |
Skip |
Commits that pass the filter are sent to an AI Agent, which generates two versions:
Discord version (for the developer community):
Fixed a rate limit vulnerability on the contact form. Previously, anyone could spam /api/notify indefinitely. Now it's capped at 5 per IP per hour. Also added HTML sanitization to prevent code injection into TG notifications via form submissions.
Threads version (for the general audience):
Found a security vulnerability on my own website today: the contact form could be spammed endlessly. Took 30 minutes to fix: added rate limiting, input validation, and injection prevention. Running a solo business means you're your own security team too. #SoloBusiness #BuildInPublic #IndieHacker
Same event, two tones, two platforms, zero manual effort.
Numbers
| Metric | Value |
|---|---|
| Git repos monitored | 3 |
| Detection frequency | Every 2 hours |
| Auto-commit frequency | Nightly at 23:30 |
| Files filtered by security | 50+ blocked, only blog posts pass |
| API vulnerabilities patched | 1 (rate limit + sanitization) |
| Total system cost | $0 (runs entirely on local WSL2) |
Takeaways for Solo Devs
If you're also an indie developer, this approach can be applied directly:
- Development activity is content: Don't wait until you're done to write about it. Let your commits become posts automatically
- Automation needs security boundaries: Whitelist > blacklist > dual-layer defense. Better to miss a post than to publish something you shouldn't
- Run a security audit before launch: Especially before any Hacker News exposure. Does your contact form have rate limiting?
- Two tones, two platforms: Developer communities want technical details; the general audience wants stories and relatability
Want to Build in Public Together?
I launched the Solo Lab Discord community in March 2026, specifically for indie developers who arm themselves with AI.
As of 2026-09-27, inside you'll find:
- #build-log: Where my Dev-to-Social system auto-posts updates. You can share yours too
- #ask-agent: Have questions? Ask our AI Agent directly (it actually responds)
Whether you're working on a side project, running a solo business, or looking to transition from a 9-to-5, you're welcome to join.
This article was written by a human. But the summaries posted to Discord and Threads were AI-generated. That's life as a solo business.
FAQ
How do you turn git commits into social media posts automatically?
The author's setup checks 3 Git repos every 2 hours for new commits and filters them first: only feat: commits (plus fix: commits involving security/critical issues) get through. Commits that pass are sent to an AI Agent that writes two versions, a developer-toned one for Discord and a general-audience one for Threads, and both are published automatically with no manual step in between.
How do you stop an auto-commit script from pushing API keys or internal files to GitHub?
Don't blindly run git add -A. Use a two-layer defense of a whitelist plus a blacklist: only content/blog/*.md files are auto-committed and every other path is skipped, and even inside the whitelist, filenames containing secret, key, token, password, proposal, or pitch are always rejected. In the author's dry run, 50+ changed files were in the repo and only one blog post passed.
Which commits are worth posting to social media automatically?
The author's rules: feat: commits always get posted because new features are newsworthy; fix: commits get posted only when they involve security or critical issues, because war stories have value; routine fix: commits and types like chore: and docs: are skipped.
What is the risk of a contact form without rate limiting?
Anyone can write a loop that hits the form 1,000 times per second and drains your Telegram notification quota and Resend email limits. The author's fix was a cap of 5 submissions per IP per hour, server-side validation of required fields and length, and HTML sanitization to block malicious HTML injected through the form.