DEV Community

BSanroma
BSanroma

Posted on

How a Chat File on GitHub Became a Pocket DevOps Tool

#ai #automation #devops #showdev

The story of how I accidentally built a local-first AI bot that controls my entire dev environment from Telegram.

It started with a simple question I asked myself one afternoon:

"How can I talk to Antigravity from my Telegram?"

Antigravity is my AI coding assistant β€” a local agent that lives on my Mac and helps me build software. It's powerful, but it has one fundamental limitation: I have to be sitting in front of my laptop to use it.

That afternoon, I was outside. Walking. And I had an idea for a fix to one of my projects. A small thing β€” just a config change. But I couldn't do it. My laptop was at home.

So I started thinking: What if I could just send a message and have it executed?

πŸ§ͺ The chat.md Experiment

My first attempt was absurd β€” and it worked.

I created a file called chat.md in one of my GitHub repositories. The idea was simple:

  1. I write a message in the file from my phone (via GitHub's mobile editor).
  2. My local agent detects the file change (via polling or webhook).
  3. It reads my instruction, processes it, and writes the response back to chat.md.
  4. I refresh the page on my phone and read the answer.

It was slow. It was ugly. It required refreshing a GitHub page manually. But it worked. I was having a conversation with my local machine through a Markdown file on GitHub.

And that's when I realized: the core concept was valid. I just needed a better transport layer.

Telegram was the obvious answer.

🧠 From File Polling to AI-Powered Chat

The original chat.md approach taught me three things:

  1. The need is real. Being away from your machine and needing to do one small thing happens constantly.
  2. Text is enough. You don't need a fancy GUI. A chat window is the perfect interface.
  3. The execution must stay local. The moment your code leaves your machine, you've created a security problem.

So I rebuilt the concept from scratch as a Telegram bot β€” but with a fundamental difference from traditional bots:

I didn't hardcode commands.

Instead of mapping /deploy to a script, I connected the bot to Google Gemini. Now I could type:

"Check the API logs for errors in the last hour"

And the AI would interpret my intent, figure out the right shell command, and execute it on my local machine. No predefined routes. No rigid syntax. Just natural language.

It even works with voice notes. I can literally talk to my infrastructure while walking down the street.

πŸ— The Architecture

The setup is intentionally minimal:

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”     β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”     β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚  Telegram    │◄───►│  Nexus AI Daemon │◄───►│  Your Local  β”‚
β”‚  (Phone)     β”‚     β”‚                  β”‚     β”‚  Projects    β”‚
β”‚              β”‚     β”‚  πŸ€– Gemini AI    β”‚     β”‚              β”‚
β”‚  Text/Voice  β”‚     β”‚  πŸ›‘οΈ Security    β”‚     β”‚  Git, Docker β”‚
β”‚              β”‚     β”‚  ⚑ Shell Access β”‚     β”‚  npm, logs   β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜     β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜     β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                     Runs on YOUR machine
                     Outbound polling only
                     Nothing exposed to internet
Enter fullscreen mode Exit fullscreen mode

Key design decisions:

  • Polling, not webhooks. The bot calls Telegram's API outbound. No ports opened. No public endpoints. No attack surface.
  • AI interpretation, not command mapping. Gemini processes natural language and decides what to execute.
  • Multi-project aware. A simple projects.json file maps project names to local paths. I can say "run tests on the web project" and the bot knows where to go.
  • Voice-native. Telegram voice notes are transcribed and interpreted by Gemini. DevOps by voice is surprisingly natural.

πŸ” Security: The Non-Negotiable Layer

Let's be honest: a bot that executes shell commands on your local machine is a terrifying idea if done wrong.

Before writing a single line of the AI logic, I established strict constraints:

Owner-Only Access

Every incoming message is checked against a hardcoded OWNER_ID. If the Telegram user ID doesn't match, the message is ignored entirely. Not rejected β€” ignored. The bot pretends it doesn't exist.

Three-Tier Command Classification

Not all commands are created equal. The security module classifies every command before execution:

🟒 Safe commands β€” Execute immediately:

git status, npm test, ls, cat, docker ps, grep, tail
Enter fullscreen mode Exit fullscreen mode

🟑 Dangerous commands β€” Require explicit confirmation:

rm, sudo, chmod, git push --force, npm publish, kill -9
Enter fullscreen mode Exit fullscreen mode

When a dangerous command is detected, the bot responds with inline Telegram buttons:

⚠️ Dry-Run Mode: Potentially dangerous command detected:

`sudo systemctl restart nginx`

Confirm execution?
[βœ… Execute]  [❌ Cancel]
Enter fullscreen mode Exit fullscreen mode

The confirmation expires after 60 seconds. No action means no execution.

πŸ”΄ Blocked commands β€” Never execute, even with confirmation:

rm -rf /    mkfs    dd if=    > /dev/    chmod 777 /    fork bombs
Enter fullscreen mode Exit fullscreen mode

These are permanently blocked at the pattern level. The AI cannot override this.

Rate Limiting

  • Maximum 100 commands per hour.
  • 2-second cooldown between commands.
  • Prevents accidental loops, spam, and abuse.

No Inbound Exposure

The single most important architectural decision: the bot polls Telegram outbound. There is no webhook, no public endpoint, no open port. The only network traffic is the bot calling Telegram's API from inside my network.

This eliminates an entire category of vulnerabilities.

πŸ”‘ BYOK: Bring Your Own Key

Here's something most people don't expect about the pricing model:

Every user provides their own API keys.

  • Your own Telegram bot (created via @botfather β€” free).
  • Your own Google Gemini API key (from Google AI Studio β€” free tier available).

This means:

  • I have zero operational costs per user. No servers, no API bills, no cloud infrastructure.
  • Your keys never leave your machine. They live in a local .env file.
  • A $3 lifetime license is sustainable β€” because there's nothing to sustain.

The BYOK model aligns perfectly with the local-first philosophy: you own everything, I own nothing.

πŸ§ͺ What I Actually Use It For

Here's what I trigger via Telegram on a typical day:

  • Deploy a static landing page to cPanel via FTP
  • Check git status across multiple projects
  • Run npm test on a specific module
  • Read a config file I forgot to check before leaving
  • Restart a local Docker container
  • Ask "what changed in the web project since yesterday?" (the AI figures out the right git log command)
  • Send a voice note: "Push the latest changes on the nexus project"

It genuinely feels like having a DevOps terminal in my pocket.

πŸ’‘ What I Learned Building This

1. Local-first is underrated

We assume everything must live in the cloud. It doesn't. The most secure server is the one that doesn't exist.

2. Security is architectural, not reactive

By removing inbound exposure entirely, you eliminate whole classes of exploits. The sandbox and rate limiting are defense-in-depth, not the primary defense. The primary defense is not being reachable.

3. AI changes the bot paradigm

Traditional bots require you to memorize commands. AI-powered bots let you describe what you want. The difference in usability is enormous. I never check a help menu anymore.

4. Voice is the killer feature nobody expected

I added voice support almost as an afterthought. It turned out to be the feature I use most. Sending a voice note while walking is faster than typing a command.

5. Simplicity compounds

This entire system is a single JavaScript file. No framework. No microservices. No Kubernetes. One daemon, one .env file, one projects.json. And it handles everything I need.

🧭 When This Architecture Makes Sense

This approach is designed for:

  • Solo developers and indie builders
  • Digital nomads who work from multiple locations
  • Anyone running services on local or private infrastructure
  • Developers who value control over convenience
  • Emergency situations when you're away from your machine

It's not meant to replace enterprise CI/CD pipelines.

It's meant to give independent builders superpowers.

πŸš€ What's Next

The foundation is solid. The roadmap includes:

  • Structured JSON audit logging for full command forensics
  • Auto-update notifications via Telegram when a new version is available
  • Nexus Skills marketplace β€” pre-configured command packs for Docker, Git, Kubernetes workflows
  • Team mode β€” share a bot securely with teammates
  • Temporary download links β€” Stripe webhook integration for time-limited distribution

🧩 Final Thought

This whole project started with a Markdown file on GitHub that I was editing from my phone's browser, hoping my laptop would pick up the message.

It was hacky. It was ridiculous. But it proved that the instinct was right:

Developers need a way to talk to their machines when they're not sitting in front of them.

Not through a cloud dashboard. Not through an exposed SSH port. Not through a third-party platform that stores your secrets.

Through a simple, encrypted, AI-powered chat. Running on your own hardware. Controlled by you alone.

A Telegram bot.
A local daemon.
A few shell scripts.
An AI that understands what you mean.

That's Nexus AI.

And honestly? It started with a chat.md file and a crazy idea.

Nexus AI β€” Pocket DevOps is available for macOS, Windows, and Linux. $3 lifetime license. Your keys, your machine, your rules.

Built by Bernat SanromΓ .

Top comments (0)