DEV Community: Mārtiņš Veiss

Weekly Update: ✨ refactor(agents): split memory-monitor into capture vs cur

Mārtiņš Veiss — Wed, 12 Aug 2026 09:00:09 +0000

Weekly Update: ✨ refactor(agents): split memory-monitor into capture vs curation so capture runs on the cheap tier (#14139)

AutoBot is an open-source, self-hosted AI agent platform — your data, your AI.

This week we shipped:

🔧 refactor(agents): split memory-monitor into capture vs curation so capture runs on the cheap tier…
🔧 docs(claude): split CLAUDE.md into a trigger-routed index and deconflict the doc set (#14133)
🔧 perf(agents): pin explicit model tiers on all agent definitions and add a Haiku repo-sweeper…

Contributors: +2

→ Full changelog: https://github.com/mrveiss/AutoBot-AI/commits/Dev_new_gui?since=2026-08-05T09:00:03.299578Z
→ Discuss on GitHub: https://github.com/mrveiss/AutoBot-AI/discussions

Weekly Update: ✨ test(kb): make the GPU chunker and KB stats tests able to

Mārtiņš Veiss — Wed, 05 Aug 2026 09:00:05 +0000

Weekly Update: ✨ test(kb): make the GPU chunker and KB stats tests able to fail (#13563) (#13613)

AutoBot is an open-source, self-hosted AI agent platform — your data, your AI.

This week we shipped:

🔧 test(kb): make the GPU chunker and KB stats tests able to fail (#13563) (#13613)
🔧 test(mcp): make the injection tests reach the handler instead of a 404 (#13598) (#13612)
🔧 fix(api-contract): keep absolute filesystem paths out of OpenAPI schema defaults (#13572) (#13611)

Contributors: +2

→ Full changelog: https://github.com/mrveiss/AutoBot-AI/commits/Dev_new_gui?since=2026-07-29T09:00:02.182745Z
→ Discuss on GitHub: https://github.com/mrveiss/AutoBot-AI/discussions

Weekly Update: ✨ fix(analytics): exclude test modules from the endpoint sca

Mārtiņš Veiss — Wed, 29 Jul 2026 09:00:06 +0000

Weekly Update: ✨ fix(analytics): exclude test modules from the endpoint scan (#12957) (#12958)

This week we shipped:

🔧 fix(analytics): exclude test modules from the endpoint scan
🔧 fix(deploy): consolidate DB credentials onto one store and s
🔧 feat(skills): add findings-first /secreview skill — emit bef

Contributors: +2

→ Full changelog: https://github.com/mrveiss/AutoBot-AI/commits/Dev_new_gui?since=2026-07-22T09:00:02.984622Z
→ Discuss on GitHub: https://github.com/mrveiss/AutoBot-AI/discussions

Weekly Update: ✨ fix(llm,npu): openrouter LLMResponse field names + depreca

Mārtiņš Veiss — Mon, 06 Jul 2026 05:00:08 +0000

Weekly Update: ✨ fix(llm,npu): openrouter LLMResponse field names + deprecated pydantic .json() (#10947, #10952) (#10962)

This week we shipped:

🔧 fix(llm,npu): openrouter LLMResponse field names + deprecate
🔧 feat(skills): role-curated skill bundles in SkillHub (#10540
🔧 feat(knowledge): tool-agnostic connector category resolution

Contributors: +2

→ Full changelog: https://github.com/mrveiss/AutoBot-AI/commits/Dev_new_gui?since=2026-06-29T05:00:04.393955Z
→ Discuss on GitHub: https://github.com/mrveiss/AutoBot-AI/discussions

Weekly Update: ✨ feat(ansible): pg_hba supports coexisting app users on one

Mārtiņš Veiss — Mon, 29 Jun 2026 05:00:06 +0000

Weekly Update: ✨ feat(ansible): pg_hba supports coexisting app users on one instance (#10636) (#10638)

This week we shipped:

🔧 feat(ansible): pg_hba supports coexisting app users on one i
🔧 refactor(memory): retire enhanced_memory_manager_async + wir
🔧 refactor(memory): consolidate TaskPriority/Priority to canon

Contributors: +2

→ Full changelog: https://github.com/mrveiss/AutoBot-AI/commits/Dev_new_gui?since=2026-06-22T05:00:02.773725Z
→ Discuss on GitHub: https://github.com/mrveiss/AutoBot-AI/discussions

Weekly Update: ✨ fix: U7 #9926 leftover discoveries — hook over-block + git

Mārtiņš Veiss — Mon, 22 Jun 2026 05:00:06 +0000

Weekly Update: ✨ fix: U7 #9926 leftover discoveries — hook over-block + git-cliff dropped commits (#10126, #10118) (#10433)

This week we shipped:

🔧 fix: U7 #9926 leftover discoveries — hook over-block + git-c
🔧 chore(deps): bump the all-dependencies group across 1 direct
🔧 chore(deps): raise backend dep floors to latest, ecosystem-c

Contributors: +3

→ Full changelog: https://github.com/mrveiss/AutoBot-AI/commits/Dev_new_gui?since=2026-06-15T05:00:04.195437Z
→ Discuss on GitHub: https://github.com/mrveiss/AutoBot-AI/discussions

Weekly Update: ✨ feat(secrets): UnifiedSecretsService — envelope CRUD + sha

Mārtiņš Veiss — Mon, 15 Jun 2026 05:00:07 +0000

Weekly Update: ✨ feat(secrets): UnifiedSecretsService — envelope CRUD + sharing (#10111) (#10134)

This week we shipped:

🔧 feat(secrets): UnifiedSecretsService — envelope CRUD + shari
🔧 feat(llc/sprint): project timeline + Gantt view for sprint p
🔧 feat(secrets): RBAC authorization policy (pure) — accessible

Contributors: +2

→ Full changelog: https://github.com/mrveiss/AutoBot-AI/commits/Dev_new_gui?since=2026-06-08T05:00:03.682819Z
→ Discuss on GitHub: https://github.com/mrveiss/AutoBot-AI/discussions

Weekly Update: ✨ feat(backend): lightweight inference mode — bypass RAG/mem

Mārtiņš Veiss — Mon, 01 Jun 2026 05:00:12 +0000

Weekly Update: ✨ feat(backend): lightweight inference mode — bypass RAG/memory for trivial tier (MVA-1992) (#9160)

This week we shipped:

🔧 feat(backend): lightweight inference mode — bypass RAG/memor
🔧 feat(plugins): add capability approval dialog and audit log
🔧 fix(ci): sync Ansible slm_agent role + fix chromadb hardened

Contributors: +2

→ Full changelog: https://github.com/mrveiss/AutoBot-AI/commits/Dev_new_gui?since=2026-05-25T05:00:04.234278Z
→ Discuss on GitHub: https://github.com/mrveiss/AutoBot-AI/discussions

Running AI in regulated environments: how AutoBot keeps your documents on-premise

Mārtiņš Veiss — Thu, 28 May 2026 06:51:48 +0000

Most AI productivity tools are asking you to trust a third party with your data. For a solo dev building side projects, that trade-off is fine. For a law firm, a hospital system, or a fintech company — it isn't.

This post is for the second group. I want to walk through exactly how AutoBot handles data in a regulated environment, where the risks actually sit, and what you need to configure to deploy it safely.

The problem with cloud AI in regulated industries

When you send a prompt to GPT-4, Claude, or Gemini, your text crosses the network. That's obvious. What's less obvious is what else goes with it when you're using most AI platforms:

The documents you've uploaded to provide context
The "system prompt" that describes your business or patient workflows
Metadata about what you're working on and when

For HIPAA-covered entities, PHI (Protected Health Information) cannot be processed by a business associate without a signed BAA. Most consumer AI products don't offer BAAs. The ones that do cost enterprise pricing and require legal review cycles.

GDPR's article 28 has similar requirements for data processors. SOC 2 Type II audits will ask where your data goes. ISO 27001 requires you to document and control it.

None of this means you can't use AI. It means you need to choose carefully where your data goes.

AutoBot's data model

AutoBot separates two things that most platforms conflate: the knowledge base and the brain.

The knowledge base is the documents you upload — your patient intake forms, your case files, your customer contracts, your internal codebase. In AutoBot, this data never leaves your machine. The RAG engine (Retrieval-Augmented Generation) indexes your documents locally into ChromaDB, a vector database running on your own hardware. When you ask a question, the relevant chunks are retrieved locally — no external API call has happened yet.

The brain is the LLM that synthesizes the retrieved context into an answer. This is where you have a choice:

Run it locally via Ollama or any OpenAI-compatible server — prompts never leave your network
Route to a cloud model (GPT-4, Claude) — only the synthesized prompt goes out, not your documents

The line is: the brain phones home. Your documents don't.

This is meaningfully different from uploading files to a cloud AI assistant. In AutoBot, a search for "what does our standard NDA say about IP assignment" retrieves the relevant clause locally and sends only the question + retrieved text to the LLM. Your full NDA document never leaves your hardware.

Network isolation in practice

Data model is one layer. Network configuration is another.

AutoBot runs on Docker Compose. The default configuration is suitable for a development environment — it exposes ports on 0.0.0.0, which means anything on your network can reach it. For production in a regulated environment, you need to tighten this.

1. Bind to localhost, not all interfaces

In your docker-compose.override.yml:

services:
  frontend:
    ports:
      - "127.0.0.1:3000:3000"
  backend:
    ports:
      - "127.0.0.1:8000:8000"

This means AutoBot is only reachable from the host machine itself. Put a reverse proxy (nginx, Caddy) in front of it that handles TLS and access control.

2. Internal service network

Keep internal services off the host network entirely:

networks:
  autobot-internal:
    internal: true

services:
  chromadb:
    networks:
      - autobot-internal
  redis:
    networks:
      - autobot-internal
  backend:
    networks:
      - autobot-internal
      - default  # only backend needs external access for LLM calls

ChromaDB and Redis should never be reachable outside the Docker network.

3. Resource limits

One question I keep seeing (shoutout to @clawnewsai.bsky.social for surfacing this): does AutoBot enforce resource limits by default?

Currently no — the deploy.resources stanza in docker-compose.yml is left to the operator. For production, add explicit limits to prevent one runaway process from starving the host:

services:
  backend:
    deploy:
      resources:
        limits:
          cpus: "2.0"
          memory: 4G
        reservations:
          cpus: "0.5"
          memory: 1G

Real-world numbers vary with load. A good starting point for a team of 5-10 users: 4 vCPUs and 8GB RAM for the full stack on a dedicated host.

What goes where: the data flow audit

For compliance documentation, here's exactly what leaves your network in each configuration:

Mode	Documents	Prompts	Answers
Full local (Ollama)	Never	Never	Never
Hybrid (OpenAI/Claude for LLM)	Never	Yes — to LLM provider	Returned from LLM
Cloud-only (no local Ollama)	Never	Yes — to LLM provider	Returned from LLM

In all cases: your documents stay on your hardware. The ChromaDB vector store is local. The retrieval step is local.

If you're running Ollama on the same host, nothing crosses the network boundary at all. This is the right configuration for HIPAA-covered environments until you have a BAA with your LLM provider.

Getting started in a restricted environment

git clone https://github.com/mrveiss/AutoBot-AI.git
cd AutoBot-AI

# Copy and edit the environment file
cp .env.example .env

# For full local operation: install Ollama first
# https://ollama.com/download
ollama pull llama3.2

# Start AutoBot
docker compose up -d

Open http://localhost:3000. Connect Ollama as your LLM provider. Upload your first document.

From that point, nothing has left your machine.

Compliance checklist before production

This is not legal advice. Get a qualified compliance officer to sign off before processing regulated data. But here's the technical baseline:

[ ] Reverse proxy with TLS in front of AutoBot
[ ] Ports bound to 127.0.0.1, not 0.0.0.0
[ ] ChromaDB and Redis on internal Docker network only
[ ] Resource limits set per service
[ ] Ollama running locally if zero data egress is required
[ ] Audit logging enabled on the reverse proxy layer
[ ] Host firewall rules (ufw / firewalld) blocking unexpected inbound
[ ] Regular backups of ChromaDB volume (your knowledge base)
[ ] BAA executed with any cloud LLM provider you route to

The DevOps guide at dev.to/mrveiss/self-hosting-autobot-a-devops-deep-dive covers the reverse proxy and firewall setup in detail.

The overhead question

I keep getting asked: what's the overhead for a small team?

For a team of 5-10: a single machine with 16GB RAM and a modern CPU runs the full stack comfortably in CPU-only mode. GPU is optional — it dramatically accelerates local inference but isn't required. The DevOps guide has sizing tables for different workload profiles.

The operational overhead is similar to running any self-hosted application — you own the uptime, you manage the updates, you back up the data. For regulated industries, that overhead is already priced in. You're not adding new burden; you're moving existing compliance obligations to infrastructure you control.

The bottom line

AutoBot doesn't solve your compliance program. But it removes the data-egress problem from the AI layer entirely.

If you're in a regulated industry and you've been waiting on cloud AI because you can't figure out the data residency question — the answer is to not send the data in the first place.

Your knowledge base stays on your machine. You pick the brain. If you pick a local brain, nothing leaves your network.

That's the architecture. The compliance framework on top is yours to build. But the foundation is solid.

AutoBot is open source at github.com/mrveiss/AutoBot-AI. Full documentation, Docker deployment guides, and community discussions are there. If you're working through a regulated-environment deployment and hit a configuration question, open a discussion — the community has seen most of the edge cases.

Weekly Update: ✨ fix(llc): address LLC API/model gaps (#8479 #8478 #8476 #8

Mārtiņš Veiss — Mon, 25 May 2026 05:00:10 +0000

Weekly Update: ✨ fix(llc): address LLC API/model gaps (#8479 #8478 #8476 #8474 #8462 #8461 #8493)

This week we shipped:

🔧 fix(llc): address LLC API/model gaps (#8479 #8478 #8476 #847
🔧 fix(llc): fix 18 LLC functional bugs from sprint discovery (
🔧 fix(llc): restore missing enums, auth, migrations, SAST, CI

Contributors: +2

→ Full changelog: https://github.com/mrveiss/AutoBot-AI/commits/Dev_new_gui?since=2026-05-18T05:00:06.602657Z
→ Discuss on GitHub: https://github.com/mrveiss/AutoBot-AI/discussions

Inside AutoBot's Frontend: A Developer Walkthrough

Mārtiņš Veiss — Mon, 11 May 2026 11:32:51 +0000

AutoBot is the open-source, self-hosted AI automation platform where your knowledge base never leaves your server — and with a local model, nothing does.

GitHub: mrveiss/AutoBot-AI

What you see when you open AutoBot

AutoBot's chat interface greets you with a familiar two-pane layout: a conversation sidebar on the left and an active chat panel on the right. Behind that simplicity lives a rich UI built from about 40 focused Vue single-file components.

Chat UI

The core chat flow is:

ChatView.vue
  └── ChatInterface.vue
        ├── ChatSidebar.vue        ← conversation list + search
        ├── ChatHeader.vue         ← model selector, settings toggle
        ├── ChatMessages.vue       ← scrolling message feed
        │     └── MessageItem.vue  ← per-message bubble + citations
        ├── ChatInput.vue          ← textarea, attachments, send button
        ├── ChatTabs.vue           ← switch between Chat / Browser / Docs
        └── CitationsDisplay.vue   ← inline source links from RAG

The ChatTabs.vue component is the pivot point: it lets you jump between a raw conversation, an embedded browser session (for web research), and a documentation search sidebar — all within the same view.

Knowledge Base UI

AutoBot's Knowledge Base is where the "your data" part of Your data. Your AI. lives. The KnowledgeView.vue brings together:

KnowledgeBrowser — file-tree style explorer of all ingested documents
KnowledgeSearch — full-text + vector search with KBSearchResultPanel rendering scored results
KnowledgeGraph / KnowledgeGraph3D — D3-powered entity graph so you can see how concepts connect
KnowledgeUpload — drag-and-drop ingestion with real-time vectorization progress (VectorizationProgressModal)
KnowledgeMaintenance — deduplication, cleanup stats, and orphan management

The pipeline inside KnowledgeView fans out to more than 30 sub-components, but each one has a narrow responsibility. If you add a new panel, you're usually only touching one file.

Component architecture in `autobot-frontend/`

autobot-frontend/
├── src/
│   ├── components/       # feature-scoped component trees
│   │   ├── chat/
│   │   ├── knowledge/
│   │   ├── agents/
│   │   ├── browser/
│   │   ├── charts/
│   │   └── base/         # shared primitives (buttons, modals, …)
│   ├── views/            # route-level pages (one per route)
│   ├── stores/           # Pinia stores (useChatStore, useKnowledgeStore, …)
│   ├── composables/      # shared reactive logic
│   ├── design-system/    # tokens.ts — canonical token catalog
│   ├── router/           # Vue Router config
│   └── styles/           # global CSS + Tailwind @theme block
├── cypress/              # end-to-end tests
└── package.json          # Vue 3 + Vite + Tailwind CSS 4 + TypeScript

Tech stack at a glance

Layer	Choice
Framework	Vue 3 (Composition API)
Language	TypeScript
Build	Vite
State	Pinia
Styling	Tailwind CSS 4 (`@theme` tokens)
Testing	Vitest (unit) + Cypress/Playwright (e2e)
Storybook	Component stories live in `src/stories/`

Design tokens

All colors, spacings, and radii flow from src/design-system/tokens.ts. This file is the single source of truth for token names; actual values live in src/assets/tailwind.css under the @theme block.

// tokens.ts (abridged)
export const SEMANTIC_COLORS = [
  { name: 'autobot-primary',   cls: 'bg-autobot-primary text-white' },
  { name: 'autobot-secondary', cls: 'bg-autobot-secondary text-white' },
  { name: 'autobot-success',   cls: 'bg-autobot-success text-white' },
  // …
]

Adding a new brand color means two edits: tailwind.css for the value, tokens.ts to register the name. That's it.

How to contribute to the UI

Get the repo running

git clone https://github.com/mrveiss/AutoBot-AI.git
cd AutoBot-AI/autobot-frontend
npm install
npm run dev

The dev server starts at http://localhost:5173. You don't need a running backend to work on visual components — the Storybook stories in src/stories/ cover most UI primitives in isolation.

Explore Storybook

npm run storybook

DesignTokens.stories.ts gives you the full token palette in one page. If you want to see a component in isolation before wiring it up to real data, stories are the right place to start.

Find good first issues

The fastest path to a first contribution is the good first issue + area: frontend label combination. These are scoped to single components or small style fixes — no need to understand the full stack before opening a PR.

Common entry points:

Accessibility — the ACCESSIBILITY_IMPROVEMENTS.md doc tracks open a11y work across the chat and KB UIs.
Design token gaps — new palette entries or missing dark-mode mappings in tailwind.css.
Storybook coverage — components in src/components/base/ that don't have a story yet.
Unit tests — src/components/**/__tests__/ has gaps; Vitest tests are welcome.

Testing approach

Unit tests (npm run test:unit) — use Vitest + Vue Test Utils. Keep tests in __tests__/ next to the component.
E2E (npm run test:e2e:dev) — Cypress tests live in cypress/. Run against the Vite dev server.
Type-check — npx vue-tsc --noEmit -p tsconfig.app.json. The repo has a tracked baseline of ~248 type errors (legacy debt); PRs should not add errors — see the CI check in .github/workflows/frontend-typecheck-regression.yml.

PR checklist

npm run lint passes
npm run test:unit passes (or new tests added for the changed component)
No new type errors vs. the baseline
Storybook story updated/added if you touched a base/ component

Your data. Your AI.

AutoBot's frontend reflects the same philosophy as the project: everything runs locally, nothing is sent to a third party, and every part of the stack is open for you to inspect, extend, or replace.

If this post helped you find your way around the codebase, the best next step is to open an issue or pick one that's already waiting.

Links

Self-Hosting AutoBot: A DevOps Deep Dive into Docker Compose, Model Sizing, and Production Ops

Mārtiņš Veiss — Mon, 11 May 2026 11:31:40 +0000

You've seen the demos. You want to run AutoBot on your own hardware, your own data, under your own control. Good instinct. Here's the full operational picture — Docker Compose internals, how to match LLM models to your GPU or CPU, and the production habits that keep things stable long-term.

Why Self-Host?

AutoBot's tagline is "Your data. Your AI." That's not marketing copy — it's an architectural choice. When you self-host:

Conversations never leave your network when you run a local model
You choose which models run (open-weight, cloud API, or a mix)
Upgrade timing is yours to control
No per-seat pricing surprises

The trade-off is operational responsibility. This post is about making that trade-off comfortable.

Docker Compose Deep Dive

AutoBot ships with a docker-compose.yml that wires together several services. Let's walk through each layer.

Services Overview

services:
  backend:
    build: ./backend
    ports: ["8000:8000"]
    depends_on: [chromadb, redis]
    environment:
      - OLLAMA_HOST=http://ollama:11434
      - CHROMA_HOST=chromadb
      - REDIS_URL=redis://redis:6379

  frontend:
    build: ./frontend
    ports: ["3000:3000"]
    depends_on: [backend]

  chromadb:
    image: chromadb/chroma:latest
    volumes:
      - chroma_data:/chroma/chroma

  redis:
    image: redis:7-alpine
    volumes:
      - redis_data:/data
    command: redis-server --appendonly yes

  ollama:
    image: ollama/ollama:latest
    volumes:
      - ollama_models:/root/.ollama
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

volumes:
  chroma_data:
  redis_data:
  ollama_models:

What Each Service Does

backend — FastAPI application. Handles chat sessions, RAG retrieval, fleet management. The OLLAMA_HOST env var points it at your local model server; swap this for an OpenAI-compatible URL to use a cloud LLM instead.

frontend — Next.js UI. Talks only to the backend on port 8000. Stateless — you can restart it without losing anything.

chromadb — Vector database for knowledge bases. Your embedded documents live here. The chroma_data volume is critical — back it up.

redis — Session state and task queues. With --appendonly yes, Redis persists to disk. Losing this volume means losing active session context (but not your knowledge bases).

ollama — Local LLM inference server. Holds downloaded model weights in ollama_models. Models are large (4–70 GB each); this volume is expensive to rebuild.

Networking

All services communicate on a default Docker bridge network. The service names (chromadb, redis, ollama) resolve as hostnames inside the network — that's why the backend config uses http://ollama:11434 rather than localhost.

For a production deployment, consider an explicit network definition:

networks:
  autobot_net:
    driver: bridge

services:
  backend:
    networks: [autobot_net]
  # ... same for all services

This lets you add an Nginx reverse proxy or Traefik on the same network without exposing internal ports.

Model Sizing to Hardware

This is where most self-hosting guides go wrong — they talk about VPS pricing instead of the actual constraint: inference throughput vs. memory bandwidth.

The Rule of Thumb

A model running entirely in VRAM is fast. A model that spills to RAM (or worse, disk) is slow. Plan your setup so your primary model fits in VRAM with room for the OS and other processes.

Hardware	VRAM	Practical Model Ceiling
RTX 3060	12 GB	Llama 3 8B (Q4), Mistral 7B
RTX 3090 / 4090	24 GB	Llama 3 70B (Q4 at the edge), Llama 3 8B (full precision)
2× A100 80 GB	160 GB	Llama 3 70B (full), most open-weight frontier models
CPU only (32 GB RAM)	—	Llama 3 8B (Q4, slow) — workable for low-traffic RAG

Local Ollama vs. Cloud LLM Trade-offs

AutoBot supports both. Here's how to think about the choice:

Local Ollama (default)

Zero per-token cost
Private by definition
Latency depends on your hardware
Best for: high-volume internal tools, sensitive data, experimentation

Cloud LLM (OpenAI, Anthropic, etc.)

Pay per token
Faster for large models you can't run locally
Data leaves your network (check your provider's retention policy)
Best for: production apps that need frontier model quality without buying GPUs

The OLLAMA_HOST env var makes switching simple. Point it at https://api.openai.com/v1 (with an OpenAI-compatible wrapper) to route through a cloud provider without touching application code.

Practical Model Recommendations

For a RAG-heavy knowledge base workload (most AutoBot deployments): a quantized 8B model (Llama 3.1 8B Q4_K_M) hits the sweet spot — fast enough for real-time chat, accurate enough for document retrieval, fits comfortably on a single consumer GPU.

For a multi-agent fleet workload: consider running a smaller model (3B–7B) per agent node and reserving a larger model for orchestration decisions. AutoBot's fleet manager is built to handle per-agent model config.

Production Tips

Backups

The three volumes that matter:

# ChromaDB — your knowledge bases
docker run --rm \
  -v autobot_chroma_data:/source \
  -v /backup:/backup \
  alpine tar czf /backup/chroma-$(date +%Y%m%d).tar.gz -C /source .

# Redis — session state
docker exec autobot-redis-1 redis-cli BGSAVE
docker cp autobot-redis-1:/data/dump.rdb /backup/redis-$(date +%Y%m%d).rdb

# Ollama models — large, but painful to re-download
docker run --rm \
  -v autobot_ollama_models:/source \
  -v /backup:/backup \
  alpine tar czf /backup/ollama-$(date +%Y%m%d).tar.gz -C /source .

Run chroma and redis backups daily. Ollama models only change when you pull new ones — back up on change, not on schedule.

Upgrades

# Pull latest images
docker compose pull

# Recreate containers (zero-downtime if you add a load balancer)
docker compose up -d --no-deps --build backend frontend

# Full restart (brief downtime)
docker compose down && docker compose up -d

Pin image tags in production (chromadb/chroma:0.5.3 not latest) so upgrades are deliberate, not automatic.

Monitoring

AutoBot's backend exposes a /health endpoint. Wire it into your monitoring stack:

# Simple cron healthcheck
*/5 * * * * curl -sf http://localhost:8000/health || notify-oncall

For metrics, the backend emits structured logs to stdout. Forward them to Loki, Datadog, or whatever you already use:

  backend:
    logging:
      driver: "json-file"
      options:
        max-size: "50m"
        max-file: "5"

Watch for these signals:

ChromaDB query latency > 2s — index fragmentation or under-resourced container
Redis memory approaching limit — set maxmemory and a sensible eviction policy (allkeys-lru)
Ollama inference time spiking — model being swapped to RAM; consider reducing context length or switching to a smaller quantization

What's Next

Self-hosting is the start, not the finish. Once you're running in production, the interesting work is building knowledge bases, connecting data sources, and wiring up agents for your specific workflows.

If you want to help make AutoBot better at the infrastructure layer, there are open issues tagged for DevOps contributors:

→ Good first issues — DevOps label on AutoBot-AI

If AutoBot is saving you money or time on your infra, consider supporting development:

→ Ko-fi: ko-fi.com/mrveiss

Questions, corrections, or war stories from your own deployment — drop them in the comments.

DEV Community: Mārtiņš Veiss

Weekly Update: ✨ refactor(agents): split memory-monitor into capture vs cur

Weekly Update: ✨ refactor(agents): split memory-monitor into capture vs curation so capture runs on the cheap tier (#14139)

Weekly Update: ✨ test(kb): make the GPU chunker and KB stats tests able to

Weekly Update: ✨ test(kb): make the GPU chunker and KB stats tests able to fail (#13563) (#13613)

Weekly Update: ✨ fix(analytics): exclude test modules from the endpoint sca

Weekly Update: ✨ fix(analytics): exclude test modules from the endpoint scan (#12957) (#12958)

Weekly Update: ✨ fix(llm,npu): openrouter LLMResponse field names + depreca

Weekly Update: ✨ fix(llm,npu): openrouter LLMResponse field names + deprecated pydantic .json() (#10947, #10952) (#10962)

Weekly Update: ✨ feat(ansible): pg_hba supports coexisting app users on one

Weekly Update: ✨ feat(ansible): pg_hba supports coexisting app users on one instance (#10636) (#10638)

Weekly Update: ✨ fix: U7 #9926 leftover discoveries — hook over-block + git

Weekly Update: ✨ fix: U7 #9926 leftover discoveries — hook over-block + git-cliff dropped commits (#10126, #10118) (#10433)

Weekly Update: ✨ feat(secrets): UnifiedSecretsService — envelope CRUD + sha

Weekly Update: ✨ feat(secrets): UnifiedSecretsService — envelope CRUD + sharing (#10111) (#10134)

Weekly Update: ✨ feat(backend): lightweight inference mode — bypass RAG/mem

Weekly Update: ✨ feat(backend): lightweight inference mode — bypass RAG/memory for trivial tier (MVA-1992) (#9160)

Running AI in regulated environments: how AutoBot keeps your documents on-premise

The problem with cloud AI in regulated industries

AutoBot's data model

Network isolation in practice

1. Bind to localhost, not all interfaces

2. Internal service network

3. Resource limits

What goes where: the data flow audit

Getting started in a restricted environment

Compliance checklist before production

The overhead question

The bottom line

Weekly Update: ✨ fix(llc): address LLC API/model gaps (#8479 #8478 #8476 #8

Weekly Update: ✨ fix(llc): address LLC API/model gaps (#8479 #8478 #8476 #8474 #8462 #8461 #8493)

Inside AutoBot's Frontend: A Developer Walkthrough

What you see when you open AutoBot

Chat UI

Knowledge Base UI

Component architecture in autobot-frontend/

Design tokens

How to contribute to the UI

Get the repo running

Explore Storybook

Find good first issues

Testing approach

PR checklist

Your data. Your AI.

Self-Hosting AutoBot: A DevOps Deep Dive into Docker Compose, Model Sizing, and Production Ops

Why Self-Host?

Docker Compose Deep Dive

Services Overview

What Each Service Does

Networking

Model Sizing to Hardware

The Rule of Thumb

Local Ollama vs. Cloud LLM Trade-offs

Practical Model Recommendations

Production Tips

Backups

Upgrades

Monitoring

What's Next

Component architecture in `autobot-frontend/`