An AI triage workbench that connects to your internal systems.
Start from a ticket, pull code, logs, and config together, and finish the first round of investigation.
It routes events from internal systems into an Agent, wires project source, logs, config, and internal tools into one analysis, then writes evidence-backed conclusions back to the source system.
What it is · Demo · Core capabilities · Get started · Architecture · Docs · Deploy pitfalls
DeepTicket is a self-hosted AI ticket triage and Agent orchestration platform deployed in your own environment.
It exposes a unified HTTP Ingress API and configurable Webhooks: internal ticketing, alerting, monitoring, or custom systems can integrate using a common event format as long as they can send or receive HTTP requests. DeepTicket provides generic integration capabilities—it does not ship vendor-specific adapters out of the box.
Tickets routed into DeepTicket are mapped to the right Git repos, log-query Skills, config-center MCPs, and other internal tools per project. After OpenHands completes multi-turn analysis, DeepTicket can write summaries, evidence, impact, root-cause hypotheses, and recommendations back via Webhook—or store results only without callback.
In one line: DeepTicket turns internal tickets from “someone re-describes the problem” into “automated first-pass triage with full project context.”
_2026-08-19_00-07-35_5mb.mp4
ad-agent ROI attribution demo · log lookup and similar capabilities require real Skill / MCP wiring · some UI is enhanced for demo and may differ from your deployment
Many issues do not need engineering immediately—but they also cannot be closed with “please check the logs.”
DeepTicket puts everything needed for analysis in one workbench: project source, runtime logs, config, internal tools, and the original ticket. Support, ops, product, and engineering can collaborate on the same context. The Agent reads facts first, then explains cause, impact, and suggested next steps.
From “ask an AI” to “complete an investigation.”
The goal is not longer chat—it is conclusions backed by evidence.
- Teams that want business units to deploy and wire internal data themselves
- Teams that need product, ops, QA, or on-call to run a first factual check before escalation
- Teams that already have Git, log platforms, config centers, or ITSM but lack a unified Agent entry point
DeepTicket is not a replacement for company-wide Copilot, nor a pure RAG stack that ingests all docs into a vector store. It is a project-scoped triage and write-back orchestration layer: hook real tools, bound by project, and make the Agent work against verifiable context.
- Git knowledge sync: sync one or more repos into the Agent workspace; source, docs, and config searchable together
- Logs and config lookup: built-in Skill templates or MCP to existing platforms—no data pipeline rewrite required
- Multi-project isolation: per-project repos, MCP, Skills,
agents.md, and membership
- Evidence first: answers cite source paths, log snippets, config keys, and related files
- Scoped access: Git and internal systems use read-only tokens;
agents.mdadds analysis rules, citation, and uncertainty handling - Visible process: workbench shows Agent steps, streaming replies, confidence, and chat history
- Say when unsure: missing evidence is stated explicitly—not filled with generic advice
- Ingress: HTTP API / Webhook for any internal ticket, ITSM, alert, or custom system
- Async analysis: background queue runs Agent jobs; callers need not hold a connection
- Webhook write-back: push conclusions to the source ticket system, or store only
- Human in the loop: machine gathers facts; people judge cause, impact, and action
- Docker one-liner: Web, OpenHands Agent Server, and Redis via Compose
- YAML + admin sidebar: versioned config and runtime admin edits
- Token and run observability: Agent usage, run status, Ingress queue, Webhook success/failure
- Self-hosted: data, model config, and project wiring stay in your environment
Ticket / alert / user question
↓
Ingress
↓
Route by project: Git + logs + config + MCP / Skill
↓
OpenHands Agent multi-turn analysis
↓
Evidence-backed output: summary · hypothesis · impact · recommendations
↓
Workbench review / human confirm / Webhook write-back
| Capability | Pure RAG | Company Copilot | DeepTicket |
|---|---|---|---|
| Read project source | Doc chunks | Varies | ✅ Git workspace |
| Internal logs / config | Ingest first | Often coarse | ✅ MCP / Skill |
| Multi-project isolation | Limited | Central platform | ✅ Per-project config |
| Ingest tickets / alerts | ❌ | Varies | ✅ HTTP API / Webhook |
| Write back to source system | ❌ | Varies | ✅ Webhook |
| Business team self-host | Varies | Usually no | ✅ Docker / YAML |
Relationship to OpenHands: OpenHands runs the Agent; DeepTicket provides the workbench, project config, knowledge sync, Ingress, and write-back.
After wiring logs and config, support, ops, and product can ask directly:
“Does this behavior match the requirement?”
“Why does prod config differ from the doc?”
“Data issue, config issue, or code issue?”
Answers include logs, config keys, and code locations so teams can decide next steps together.
Any HTTP-capable ticket or alert system can push events. DeepTicket correlates the project, reads code and config, summarizes impact, and writes back via Webhook. On-call gets a reviewable draft—not an isolated error line.
With a reporting or BI MCP, analyze mismatches between campaign ROI, daily reports, and delivery logs. Vertical example: ad_agent; DeepTicket handles isolation, tooling, and orchestration—not a fixed domain.
Prerequisites: Docker Desktop or Docker Engine + Compose v2.
mkdir deepticket && cd deepticket
curl -LO https://raw.githubusercontent.com/shanananana/deepticket/main/docker-compose.image.yml
curl -LO https://raw.githubusercontent.com/shanananana/deepticket/main/.env.docker.example
cp .env.docker.example .env
docker compose -f docker-compose.image.yml up -dOpen http://127.0.0.1:8600 and sign in with admin / admin. Set your LLM key in .env before start, or in the sidebar LLM settings after login.
⚠️ Default credentials are for local trial only. Change password, auth, and persistence before internal or production deployment.
git clone https://github.com/shanananana/deepticket.git
cd deepticket
bash scripts/setup.sh
bash scripts/start_all.shCopy the Nginx log prompt from DEMO_PROMPT.md for a first chat; for the full “logs → config / code → ROI” flow see Quick start & ROI demo.
Common commands:
docker compose logs -f deepticket # tail logs
docker compose down # stop
bash scripts/verify.sh # local self-check
Vector source: architecture.en.svg
DeepTicket is split into input, knowledge, engine, output, and storage layers: input handles chat and Ingress; knowledge handles Git / Skill / MCP; OpenHands runs analysis; output handles streaming UI and Webhook write-back; storage holds chats, project config, and run records.
| Doc | When to read |
|---|---|
| docs/docker.md | Docker deploy, GHCR image, volumes, internal pilot |
| docs/quickstart-demo.md | Demo and ROI walkthrough from scratch |
| docs/DEMO_PROMPT.md | Copy-paste Nginx / ROI sample prompts |
| deepticket.example.yaml | Full config and integration examples |
| deepticket/skills/README.md | Authoring and mounting project Skills |
| CONTRIBUTING.md | Local dev, tests, contributing |
| CHANGELOG.en.md | Release notes and known limits |
Multi-project, MCP, Ingress, and agents.md are configurable in the workbench sidebar or via admin API /api/admin/projects/{id}.
DeepTicket is in Alpha (v0.5.1). Core flows cover project management, Git knowledge base, Skill / MCP, OpenHands Agent, workbench chat, Ingress async analysis, Webhook write-back, and run observability.
Java edition (planned): A Java/Spring-based implementation is on the roadmap for teams that prefer JVM stacks and on-prem Maven/Nexus workflows. It will align with the same Ingress contract and project model; watch this repo for updates.
If this direction helps you, please Star, open an Issue, or share your integration story.
Notes from real on-prem deployments—for teams whose primary stack is Java / Go / ops rather than Python packaging.
If your internal PyPI or artifact mirror does not mirror the full OpenHands dependency chain with prebuilt wheels for your target platform, pip may fall back to source builds. Some native dependencies need C/C++ and Rust toolchains; downloading and compiling on a packaging host behind a restricted network can take hours or fail.
Mitigation: on a build host that matches production, prefetch and validate the full wheel set into your artifact mirror; install wheels only in production builds. Mirroring this project's pre-built Docker image to an internal registry avoids most of this pain. See docs/docker.md.
CentOS 7 ships glibc 2.17. If a binary wheel in the OpenHands chain requires GLIBC_2.28 or newer, install or runtime fails—extra Python packages will not fix it.
Do not use CentOS 7 as build or runtime base; prefer Rocky Linux 9 or similar, or use this project's Debian Bookworm-based image (python:3.12-slim-bookworm in the Dockerfile). Use the exact package name from the error log when debugging.
DeepTicket · Evidence before escalation · MIT License