AI-Git-Bot turns engineering chores into repeatable, automated workflows — directly inside Gitea, GitHub, GitLab, and Bitbucket. Self-hostable. AI-agnostic. No Kubernetes required.
Then open http://localhost:8080 — create your admin account and wire the first bot
Every team has a list of "we know we should be doing this" engineering chores. AI-Git-Bot turns them into repeatable workflows that fire on Git events you're already producing.
A writer bot inspects your vague bug report, reads related issues and repo context, asks the minimum clarifying questions — then produces a structured AI Created Issue with acceptance criteria. No more "clarify in DMs three days later."
A review bot posts inline + summary feedback every time the bot is requested as reviewer. Large diffs are chunked. @bot mentions keep follow-up Q&A in the PR thread with full session memory.
The Full-stack QA workflow plans user journeys from the diff, authors Playwright specs, deploys to a per-PR preview environment, runs the suite, and posts the report — then tears down on PR close.
Assign an issue to a coding bot. It reads the source, drafts the change in a workspace, validates with your project's own build tooling (Maven / Gradle / npm / Go / Cargo / .NET), and opens a PR for review.
The AI Unit Tests workflow generates focused tests for the PR diff, runs them with the project's own runner, commits them onto the PR branch transparently, and posts the pass/fail + coverage report.
The PR-close lifecycle hook calls your deployment target's teardown action — webhook, MCP tool, CI workflow dispatch, or static no-op. Forgotten previews stop burning cluster budget and leaking data.
All shipped and tested. Every workflow is opt-in per bot — pick the chore that hurts most, wire one bot, done.
@bot mention in PR comment or inline review thread@bot generate-tests slash commande2e-test workflow + deployment target💬 Slash commands in PR comments: @bot rerun-tests, @bot regenerate-tests <feedback>, @bot generate-tests, @bot rerun-unit-tests
AI-Git-Bot is a gateway, not a script. Every Git platform plugs in through a RepositoryApiClient SPI. Every AI provider plugs in through an AiClient SPI. One admin UI, one PostgreSQL database, one set of encrypted credentials.
Cloud providers need only an API key. Local LLMs (Ollama, llama.cpp) run on your own hardware — nothing leaves your infrastructure.
A single AI-Git-Bot instance serves mixed estates — GitHub for product, Gitea for embedded, Bitbucket for the legacy acquisition — all from one admin UI.
AI-Git-Bot works the same way everywhere — reviews, inline comments, E2E test reports, and coding agents across Gitea, GitHub, GitLab, and Bitbucket.
One Docker image, one PostgreSQL database, one admin UI. No Kubernetes required.
git clone https://github.com/tmseidel/ai-git-bot.git && cd ai-git-bot && docker compose up -d
Navigate to http://localhost:8080 and create your administrator account.
Create an AI Integration (Anthropic, OpenAI, Ollama, …) and a Git Integration (Gitea, GitHub, GitLab, Bitbucket). API keys are encrypted at rest (AES-256-GCM).
Create a bot combining one AI integration with one Git integration. Enable the workflows you want. Copy its unique Webhook URL.
Configure the webhook in your Git provider. Done. Assign the bot as a reviewer on a PR — watch it post its first review.
Adoption risk is the #1 reason AI-in-the-SDLC pilots die. Every design choice below exists to keep that risk near zero.
Every workflow ships behind a prworkflow.<name>.enabled flag. Only review defaults to true. Nothing changes for repos you don't touch.
Every credential, webhook secret, and deployment-target config is encrypted with AES-256-GCM. API keys never appear in logs.
Per-bot built-in tool whitelist + per-MCP-config tool whitelist. The admin decides what the agent can do — not the LLM, not the prompt.
The bot triggers your existing CI — it never invents a deploy path. Four interchangeable DeploymentStrategy implementations keep deployment under your control.
Every workflow run, step, and tool call is persisted. Micrometer meters (prworkflow.run_total, prworkflow.run_duration_seconds) exposed at /actuator/prometheus.
Workflow params expose hard caps (maxTestCases, maxRetries) and the agent loop honours the shared agent.budget.* token budget.
Generated E2E tests don't evaporate on PR close. Four lifecycle modes (ephemeral, commit-to-pr, offer-as-pr, promote-on-merge) let tests graduate into the codebase under operator control.
Every new column on bots is nullable. Existing bots without a WorkflowConfiguration keep running the legacy review workflow only. No migration drama.
Self-hostable end-to-end, including local LLMs — nothing has to leave your infrastructure.