I'm building a private support bot over tickets and Confluence pages. What stack makes sense?

A good stack for a private support bot over tickets + Confluence is usually:

Recommended baseline stack

1) Ingestion / sync

• Confluence API + ticketing API (Jira Service Management, Zendesk, Freshdesk, etc.)
• A small ETL worker in Python or Node.js
• Schedule with cron, Celery/RQ, or a queue like SQS / Redis Queue / BullMQ

2) Storage

• Postgres as the system of record
• If you want vector search in the same DB: pgvector
• Store:
  • raw documents
  • cleaned/chunked text
  • metadata: source, updated_at, permissions, ticket status, space/project, URL

3) Search / retrieval

• For a simple setup: Postgres + pgvector + full-text search
• For larger scale or more complex retrieval:
  • OpenSearch / Elasticsearch for keyword search
  • vector DB like Pinecone, Weaviate, Qdrant, or Milvus

For most internal support bots, Postgres + pgvector is enough to start.

4) RAG / orchestration

• Use a lightweight framework:
  • LlamaIndex if you want document ingestion/retrieval to be easy
  • LangChain if you need broader agent/tooling patterns
• Keep the system simple: retrieval + answer generation + citations
• Avoid overusing agents unless you truly need multi-step actions

5) LLM

Depending on privacy and compliance:

• Hosted API: OpenAI / Anthropic / Azure OpenAI
• Self-hosted: Llama 3.1/3.2, Mistral, Qwen via vLLM or TGI

If this is sensitive internal support data, many teams choose:

• Azure OpenAI for enterprise controls
• or self-hosted models if data must never leave your environment

6) Backend API

• FastAPI (Python) is a great default
• Or Node.js + NestJS if your team prefers TypeScript

Expose endpoints for:

• asking questions
• feedback
• admin sync status
• source inspection / citations

7) UI

• Next.js for a web chat interface
• Slack/Teams bot if your support team works there
• Add citation links and confidence/source indicators

8) Auth / permissions

This is critical for support data.

• SSO/OIDC: Okta, Auth0, Azure AD
• Enforce document-level permissions at retrieval time
• Filter by user/group so the bot only retrieves what the user can access

9) Observability / evaluation

• Logging: OpenTelemetry, ELK, or Datadog
• LLM traces/evals: LangSmith, Phoenix, or your own eval harness
• Track:
  • answer correctness
  • source grounding
  • latency
  • hallucinations
  • “no answer” rate

---

A practical “best default” stack

If you want a stack that’s easy to ship:

• Python + FastAPI
• Postgres + pgvector
• LlamaIndex
• OpenAI / Azure OpenAI
• Next.js UI
• Confluence + ticket API sync workers
• Redis + Celery for background jobs
• OIDC/SSO
• OpenTelemetry + basic eval scripts

This is a strong “v1” stack for most teams.

---

When to choose a different stack

Choose Elasticsearch/OpenSearch if:

• you have lots of tickets
• keyword search matters a lot
• you need hybrid search at scale

Choose a dedicated vector DB if:

• you expect very large corpora
• you need frequent reindexing at scale
• you want advanced vector operations or separation of concerns

Choose self-hosted LLMs if:

• data residency is strict
• compliance forbids external APIs
• you can handle GPU ops and quality tradeoffs

Choose Azure OpenAI / enterprise hosted LLM if:

• you want enterprise controls without running models
• you need faster implementation
• your legal/compliance team approves it

---

Important architecture note

For support bots, the hard part is usually not the LLM. It’s:

1. permission-aware retrieval
2. fresh sync from sources
3. good chunking and metadata
4. citation quality
5. evaluation and guardrails

If you get those right, the model can be relatively simple.

---

My opinionated recommendation

If you’re starting from scratch and want the least painful path:

• FastAPI
• Postgres + pgvector
• Redis + Celery
• LlamaIndex
• Azure OpenAI or OpenAI
• Next.js
• SSO + document-level ACL filtering

That gives you a very solid private support bot without too much infra.

If you want, I can also give you:

1. a reference architecture diagram in words,
2. a MVP vs production stack, or
3. a concrete schema for tickets + Confluence ingestion.