This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend.
What I Built
I built OpsBuddy for my best friend, who is learning DevOps.
When a Kubernetes pod keeps restarting, a Docker container exits unexpectedly, or a CI/CD run fails, it can be difficult to understand which part of the error matters or what to check first.
OpsBuddy is a small troubleshooting assistant for those situations. You choose the area you are working on, paste an error or diagnostic output, and ask for help understanding it. It returns a plain-language summary, possible causes, recommended next checks, and commands to review.
My friend has tried the app and shared feedback with me while I was building it. I'm keeping their name and personal details private.
OpsBuddy is designed to help someone decide where to investigate next, rather than claim a definitive diagnosis. It does not connect to a Kubernetes cluster, execute commands, or make changes to a system.
Demo
Demo video: [https://youtu.be/ZXHzGoTD3U0]
The demo shows a sanitized troubleshooting example being entered into OpsBuddy and the resulting explanation, possible causes, and suggested checks.
The application currently runs locally, so there is no public deployment link. The video demonstrates the complete working flow instead.
Code
How I Built It
OpsBuddy has a small browser-based interface and a FastAPI backend. The backend sends the submitted diagnostic text to Ollama running on the same computer and asks the open-weight model to produce a structured troubleshooting response.
The default model is qwen2.5-coder:3b.
While testing the application, I found an interesting problem. The model suggested restarting a Kubernetes pod even though the prompt specifically asked it to stick to read-only troubleshooting. That made it clear that prompt wording alone was not enough.
I added backend safeguards that remove known system-changing actions and common shell commands from suggested steps. I also limit displayed commands to a small read-only allowlist and ask for more information when the input is too vague to support a useful analysis.
These checks are safeguards, not a guarantee that every response is correct or suitable for every environment. OpsBuddy never executes the suggested commands, and users should review them before deciding whether to run them.
Diagnostic text is sent to the local Ollama service. Users should still remove passwords, tokens, API keys, and other secrets before sharing logs or diagnostic output.
Why Does Open Innovation Matter?
Troubleshooting logs and diagnostic output can contain information that people may not want to send to a hosted AI service.
With the default setup, OpsBuddy sends the request to Ollama running on the same computer instead of sending it to a hosted AI API. Once Ollama and the model are installed, the analysis can run locally.
Using an open-weight model also means the project is not tied to one proprietary AI API. A user can choose another compatible local model and decide what works best on their own machine.
The trade-off is that local inference requires enough computing resources, and the model can still produce incorrect or overconfident answers.
For this project, open innovation made it possible to build a local-first troubleshooting tool that gives the person using it more control over their diagnostic data and model choice.
Top comments (0)