Reviving My School's AI Assistant: Moodle + Ollama

Ilias Almerekov — Thu, 28 May 2026 07:54:01 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Moodle AI Assistant — an AI-powered learning companion embedded directly into Moodle, the LMS used at my vocational school Berufsschule ITECH in Germany, where I'm training as a Fachinformatiker (IT Specialist)

This project means a lot to me because it solves a real problem I see every day at school: students get stuck on assignments after hours, teachers get flooded with the same repeated questions, and there's no smart help available on demand. I built this to change that.

Demo

Github Repository: https://github.com/IliasAlmerekov/moodle
Demo Video: https://youtube.com/shorts/Iiy4re43cMM?feature=share

The Comeback Story

The project started as a school initiative at Berufsschule ITECH. My teachers loved the idea and we were planning to finish it together and actually deploy it to the school's real Moodle instance. Then our block-based curriculum kicked in — a new Lernfeld (learning field) began, everyone's schedules shifted, and the project quietly slipped into the "we'll get back to it someday" pile.

It sat there. Months passed. Then I found the GitHub Finish-Up-A-Thon Challenge — and something clicked. This was exactly the push I needed. The thought of finally showing my teachers a working, production-ready version of what we once planned together was all the motivation I needed to open the repo again.

My Experience with GitHub Copilot

When I first built this project, I had a GitHub Student subscription with access to powerful models and no strict weekly limits. Back then, Copilot was my real pair programmer — it helped me move fast and learn even faster.

Unfortunately, the tighter weekly limits that came later made it much harder to use Copilot the same way. But those months of working with it weren't wasted — I learned a lot, grew as a developer, and now I feel ready to come back to this project and do a full refactoring, applying everything I picked up along the way.

The Comeback 04.06.2026: What was broken and What I Actually Fixed?

The prototype worked — it answered questions. But it was a single-file Fastify server with logic mixed into routes, and it would not have survived contact with real students. Here's the honest before → after, by area:

🔐 Identity

Before: userId trusted straight from the request body — any user could read another's chat (IDOR).
After: HMAC-SHA256 signed identity, constant-time verify, per-session ownership checks (401/403).

🏛️ Architecture

Before: Business logic tangled into route handlers.
After: Clean Architecture, 4 layers, dependency rule enforced — use cases testable without Fastify or Docker.

🤖 AI grounding

Before: The model could see all courses.
After: Course search is fail-closed to the student's own enrolments; no secrets reachable by the model.

🛡️ Frontend XSS

Before: Model output dumped into raw innerHTML.
After: DOMPurify + tag/attribute allowlist + Moodle-origin-locked links, with a CSP backstop.

⚙️ Reliability

Before: Direct fetch, no limits.
After: Timeout + retry (Moodle), circuit breaker + bounded queue (Ollama), graceful shutdown, SSE abort on disconnect.

💾 Persistence

Before: In-memory — every restart wiped all chat history.
After: SQLite (WAL, prepared statements, indexed, retention pruning) behind a repository interface.

🚀 Deploy

Before: Manual, container ran as root.
After: Multi-stage non-root Docker image, healthchecks, ordered startup, one-command Compose.

✅ Quality gate

Before: None.
After: 417 tests, ESLint, Prettier, npm audit, Gitleaks, Trivy image scan + container smoke test in CI.

The 3 critical blockers I closed for this challenge

Unauthenticated PII leak — /moodle/user/:id and /moodle/users/:id/courses returned personal data with no auth (only accidentally hidden by nginx routing). Now production-gated to 404.
Known high-severity CVEs — Fastify 4.28.1 carried 3 high CVEs (body-validation bypass, host/proto spoof). Upgraded to Fastify 5 + matching plugins; npm audit now reports 0 vulnerabilities.
Root container, no build hardening — rebuilt as a multi-stage image running as USER node with npm ci and a HEALTHCHECK.

Where I was honest instead of perfect

I didn't fake "done." The per-user rate limiter is in-memory (fine for a single instance, documented as a known limit), and the prompt-injection guard is a best-effort blocklist — its real safety net is that the model simply can't reach anything sensitive (fail-closed course scope, no secrets in context). These are written down in the README's Limitations section, not hidden.

The result

The prototype went from "it answers questions on my laptop" to a production-lite service: Clean Architecture (90/100 in my own readiness
review), HMAC auth, sanitized LLM output, resilient external calls, persistent history, a hardened container, and a full CI pipeline — all
behind a single docker compose up.

The next step is the one that started it all: showing my teachers a working version, and finally deploying it to the school's real Moodle
instance.

Thank You 🙏

Huge thanks to GitHub and the DEV community for the chance to take part in such a cool challenge. The Finish-Up-A-Thon was exactly the push I needed to reopen a project I genuinely cared about and finally carry it across the finish line.

These challenges do more than hand out prompts — they turn "someday" projects into shipped ones and give motivation real momentum. Thank you for creating that space. I had a great time building this, and I'll happily jump into more challenges like this one in the future. 🚀