ThinkStreamTV — Blog

Category: Ai Agents

  • AI Agents Store: A Self-Hosting Guide for DevOps Teams

    AI Agents Store: A Self-Hosting Guide for DevOps Teams

    Disclosure: This post contains one or more links to providers we have a real, registered affiliate/referral relationship with. We may earn a commission at no extra cost to you if you sign up through them.

    Every week a new “AI agents store” launches promising a marketplace of drop-in autonomous workers for coding, customer support, DevOps automation, and content generation. Before you plug a third-party agent into your infrastructure, you need to understand what these stores actually offer, where the risk lives, and how to run the same capability yourself without handing an unknown vendor access to your servers.

    This guide is written for developers and sysadmins who want to evaluate an AI agents store critically and, in most cases, replace it with a self-hosted setup they fully control.

    What Is an AI Agents Store?

    An AI agents store is a marketplace or registry where you can browse, install, and run pre-built autonomous agents — small programs that combine an LLM with tools (shell access, APIs, file systems, browsers) to complete tasks with minimal human input. Think of it as an app store, except the “apps” can execute code, make network calls, and modify data on your behalf.

    Popular examples of the category include hosted agent marketplaces bundled into SaaS platforms, open-source agent registries on GitHub, and plugin ecosystems tied to specific LLM providers. The common thread: you install a package, grant it credentials or tool access, and it runs autonomously against a goal you define.

    How AI Agent Marketplaces Work

    Most stores follow the same basic flow:

  • A publisher packages an agent definition — system prompt, tool list, and dependency manifest.
  • The store hosts that definition, often with a rating/review system similar to a package registry.
  • You “install” the agent, which usually means pulling a container image, a Python package, or a hosted API endpoint.
  • The agent runs with credentials you provide (API keys, database access, cloud permissions) and reports back through a dashboard or webhook.

    • That last step is where most of the risk concentrates. An agent with shell access and a cloud API key is functionally equivalent to giving a stranger SSH access to a scoped-down account — except the “stranger” is a model whose behavior isn’t fully deterministic.

    Public Store vs Self-Hosted Registry

    There are two fundamentally different models:

  • Public/hosted store — a third party hosts the agent runtime, your data flows through their infrastructure, and you trust their sandboxing and vetting process.
  • Self-hosted registry — you pull agent images or definitions (often from open-source repos) and run them inside your own containers, on your own network, with your own access controls.

    • For teams handling production infrastructure, customer data, or anything covered by a compliance framework, the self-hosted model is the only defensible option. You keep the audit trail, you control egress, and you decide which tools an agent can actually call.

    Why Self-Host Your AI Agents Store

    Running your own agent registry instead of relying on a public marketplace gives you several concrete advantages:

  • Credential isolation — agents never see your root API keys; they get scoped, revocable tokens instead.
  • Network control — you can restrict egress with firewall rules so an agent can’t exfiltrate data to an arbitrary endpoint.
  • Reproducibility — pinned container images mean an agent behaves the same way in staging and production.
  • Auditability — every tool call and shell command an agent makes goes through your own logging pipeline instead of a vendor’s opaque dashboard.
  • Cost control — you pay for compute, not a per-seat SaaS markup on top of the underlying model API.

    • Security Considerations for Self-Hosted Agent Stores

    Self-hosting doesn’t automatically make agents safe — it just moves the responsibility to you. Treat every agent like untrusted code, because functionally it is: the model decides what commands to run, and prompt injection from a webpage, email, or ticket can redirect that behavior. Follow the same hardening checklist you’d apply to any internet-facing service, as outlined in the OWASP Top 10 for LLM Applications:

  • Run each agent in its own container with no access to the Docker socket.
  • Use a non-root user inside the container.
  • Restrict outbound network access to an explicit allowlist.
  • Rotate and scope API keys per agent, not per team.
  • Log every tool invocation to an external, tamper-evident sink.

    • If you haven’t hardened your VPS baseline yet, start with our guide on server security hardening before you deploy any autonomous agent to it.

    Setting Up a Self-Hosted AI Agents Store with Docker

    The cleanest way to run agents on your own infrastructure is a container-per-agent model behind a lightweight orchestration layer. Below is a minimal but production-viable pattern using Docker Compose.

    Start with a directory structure that separates agent definitions from runtime state:

    mkdir -p agents-store/{agents,logs,config}
cd agents-store

    Each agent gets its own Dockerfile so dependencies stay isolated:

    FROM python:3.12-slim

RUN useradd -m agentuser
WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY agent.py .

USER agentuser
ENV PYTHONUNBUFFERED=1

ENTRYPOINT ["python", "agent.py"]

    Define the runtime in a docker-compose.yml so you can scale agents independently and keep resource limits explicit:

    version: "3.9"

services:
  research-agent:
    build: ./agents/research
    restart: unless-stopped
    env_file: ./config/research.env
    networks:
      - agent-net
    deploy:
      resources:
        limits:
          cpus: "0.5"
          memory: 512M
    read_only: true
    tmpfs:
      - /tmp

  devops-agent:
    build: ./agents/devops
    restart: unless-stopped
    env_file: ./config/devops.env
    networks:
      - agent-net
    deploy:
      resources:
        limits:
          cpus: "1.0"
          memory: 1G

networks:
  agent-net:
    driver: bridge
    internal: false

    Note the read_only: true and tmpfs mount on the research agent — that’s a container hardening pattern worth applying to any agent that doesn’t need to persist files to disk. If you’re new to Compose networking and resource limits, our Docker Compose fundamentals article covers the flags used here in more depth.

    Deploying and Managing Agents

    Once your compose file is defined, bring the stack up and verify isolation before granting any real credentials:

    docker compose build
docker compose up -d
docker compose ps

    Check that each agent container can’t reach anything outside its intended scope:

    docker exec -it agents-store-research-agent-1 sh -c "curl -m 3 https://api.internal-service.local"

    If that call succeeds when it shouldn’t, tighten your Docker network or add explicit firewall rules with iptables or a reverse proxy allowlist. Logs from every agent should ship somewhere durable — piping container logs to a centralized collector is non-negotiable once you have more than one or two agents running:

    docker compose logs -f --tail=100 devops-agent >> ./logs/devops-agent.log

    For anything beyond a single-node hobby setup, forward those logs to a proper observability stack rather than flat files.

    Choosing Infrastructure for Your AI Agents Store

    Agent workloads are bursty — mostly idle, then a spike of CPU and memory when a task runs. That makes cloud VPS providers with hourly billing and fast provisioning a better fit than committing to large reserved instances. DigitalOcean Droplets are a solid starting point for a self-hosted agent registry: predictable pricing, straightforward Docker support, and a network firewall you can configure without a full cloud console learning curve.

    If you’re running many small agent containers and want lower baseline costs, Hetzner offers strong price-to-performance ratios on dedicated vCPU instances, which matters once you’re running a dozen agents around the clock instead of a demo.

    Whichever provider you choose, put your agent store behind Cloudflare for DNS, DDoS protection, and a WAF layer in front of any webhook endpoints your agents expose — that’s a cheap insurance policy against a compromised agent turning into an open relay.

    Monitoring and Observability

    An autonomous agent that fails silently is worse than one that fails loudly. Set up uptime and log-based alerting so you know the moment an agent stops reporting or starts erroring on every task. BetterStack gives you uptime monitoring plus log management in one place, which is enough to catch both “the container died” and “the agent is stuck in a retry loop burning API credits” before it becomes a bill you didn’t expect.

    Getting Discovered: SEO for Agent-Related Content

    If you’re publishing documentation or a public catalog for your internal agents store, treat it like any other technical content property. Keyword research tools like SE Ranking help you find what developers are actually searching for around agent tooling, so your docs rank instead of getting buried under marketing pages from hosted competitors.


    Recommended: Ready to put this into practice? SE Ranking is a tool we use for exactly this, and we have a real, disclosed affiliate relationship with them.

    FAQ

    Is it safe to use a public AI agents store for production workloads?
    Generally no, unless the vendor provides clear sandboxing guarantees, SOC 2 or equivalent compliance documentation, and scoped credential support. For anything touching production data, self-hosting gives you far more control over blast radius.

    What’s the minimum server spec for self-hosting a small agents store?
    A 2 vCPU / 4GB RAM VPS is enough to run 3-5 lightweight agents with Docker resource limits in place. Scale up as you add agents or increase concurrency per agent.

    Do I need Kubernetes to run an AI agents store?
    No. Docker Compose is sufficient for most teams running under ~20 agents. Move to Kubernetes only once you need autoscaling, multi-node scheduling, or rolling updates across a fleet.

    How do I stop an agent from making unauthorized network calls?
    Use Docker network isolation combined with an explicit egress allowlist enforced at the firewall or reverse proxy level. Never rely on the agent’s own prompt instructions as a security boundary.

    Can I mix agents from a public store with self-hosted ones?
    You can, but isolate them into separate networks and credential scopes so a compromised third-party agent can’t pivot to your internal agents or infrastructure.

    What happens if an agent’s API key gets leaked?
    If you scoped credentials per agent as recommended above, you revoke and rotate just that one key with minimal blast radius. This is the single biggest reason to avoid sharing one master API key across every agent in your store.

    Final Thoughts

    An AI agents store can be a genuine productivity multiplier, but the convenience of a public marketplace comes with a trust dependency most infrastructure teams shouldn’t accept by default. Containerizing agents yourself, scoping their credentials, and monitoring them like any other production service turns a risky black box into a controllable part of your stack. Start small — one or two self-hosted agents with tight resource limits — and expand only as your logging and access controls keep pace.

    Related articles:

  • Customer Support AI Agent: Self-Hosted Docker Guide

    Customer Support AI Agent: A Self-Hosted Docker Deployment Guide

    Disclosure: This post contains one or more links to providers we have a real, registered affiliate/referral relationship with. We may earn a commission at no extra cost to you if you sign up through them.

    Every SaaS vendor wants to sell you a customer support AI agent at $0.50 per resolved ticket plus a platform fee. If you run infrastructure for a living, that math stops making sense the moment your support volume grows. This guide walks through building and deploying a customer support AI agent yourself, using Docker, an open-source LLM backend, and a retrieval layer over your own documentation — no per-seat licensing required.

    We’ll cover the architecture, the Docker Compose stack, retrieval-augmented generation (RAG) for grounding answers in your actual docs, reverse proxy security, and monitoring — everything you need to run this in production, not just a demo.

    Why Self-Host a Customer Support AI Agent

    Most teams reach for a hosted customer support AI agent because it’s fast to set up. But once you’re past the pilot stage, three problems show up: cost scales linearly with ticket volume, your support data (often full of customer PII) lives on a third party’s servers, and you’re locked into whatever model and prompt behavior the vendor ships that quarter.

    Self-hosting flips all three. You control the model, the data stays on infrastructure you own, and the cost is a fixed VPS bill instead of a per-resolution fee.

    The Case for Self-Hosting

  • Predictable cost: a $40-80/month VPS handles thousands of support interactions instead of scaling per-seat or per-ticket.
  • Data control: support transcripts, account details, and internal docs never leave your network boundary.
  • Model flexibility: swap between Llama 3, Mistral, or a hosted API like OpenAI depending on cost and quality needs.
  • No feature gating: you’re not waiting on a vendor roadmap to add a capability you need today.

    • The tradeoff is operational: you own uptime, security patching, and monitoring. If you’re already comfortable managing Docker in production, this is a small lift.

    Architecture Overview

    A production-grade customer support AI agent has four components:

    1. A frontend/widget or API endpoint that receives customer messages.
    2. An LLM inference layer — either a local model served via Ollama or a hosted API.
    3. A retrieval layer (RAG) that pulls relevant chunks from your knowledge base so answers are grounded in your actual docs rather than the model’s training data.
    4. A reverse proxy and monitoring layer to handle TLS termination and keep the whole thing observable.

    All four run as containers behind a single Docker Compose file, which keeps the deployment reproducible across environments.

    Building the Stack

    We’ll use Ollama for local inference, a lightweight vector store (Chroma) for retrieval, and a small FastAPI service to tie them together. This mirrors patterns we’ve covered in our Docker Compose production guide, so if Compose syntax is new to you, start there first.

    Docker Compose Setup

    Here’s a minimal but production-usable docker-compose.yml:

    version: "3.9"

services:
  ollama:
    image: ollama/ollama:latest
    volumes:
      - ollama_data:/root/.ollama
    restart: unless-stopped
    networks:
      - support_net

  chroma:
    image: chromadb/chroma:latest
    volumes:
      - chroma_data:/chroma/chroma
    restart: unless-stopped
    networks:
      - support_net

  support-agent:
    build: ./agent
    environment:
      - OLLAMA_HOST=http://ollama:11434
      - CHROMA_HOST=http://chroma:8000
      - MODEL_NAME=llama3
    depends_on:
      - ollama
      - chroma
    restart: unless-stopped
    networks:
      - support_net

  nginx:
    image: nginx:alpine
    ports:
      - "443:443"
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
      - ./certs:/etc/nginx/certs:ro
    depends_on:
      - support-agent
    restart: unless-stopped
    networks:
      - support_net

volumes:
  ollama_data:
  chroma_data:

networks:
  support_net:
    driver: bridge

    Bring it up with:

    docker compose up -d
docker compose exec ollama ollama pull llama3

    That second command pulls the model weights into the Ollama container. For a support agent, llama3:8b is usually the right balance of speed and quality on a mid-tier VPS; jump to a larger model only if you have GPU access.

    Connecting the LLM Backend

    The support-agent service is a small FastAPI app that does three things: embed the incoming question, retrieve relevant chunks from Chroma, and pass both to the LLM with a grounding prompt.

    from fastapi import FastAPI
from pydantic import BaseModel
import httpx
import chromadb

app = FastAPI()
client = chromadb.HttpClient(host="chroma", port=8000)
collection = client.get_or_create_collection("support_docs")

class Query(BaseModel):
    message: str

@app.post("/chat")
async def chat(query: Query):
    results = collection.query(query_texts=[query.message], n_results=4)
    context = "nn".join(results["documents"][0])

    prompt = (
        f"Answer the customer's question using only the context below. "
        f"If the context doesn't cover it, say you'll escalate to a human.nn"
        f"Context:n{context}nnQuestion: {query.message}"
    )

    async with httpx.AsyncClient(timeout=60) as http_client:
        response = await http_client.post(
            "http://ollama:11434/api/generate",
            json={"model": "llama3", "prompt": prompt, "stream": False},
        )

    return {"answer": response.json()["response"]}

    This is the whole trick behind why a self-hosted customer support AI agent doesn’t hallucinate wildly: the retrieval step forces the model to answer from your actual documentation rather than guessing. Load your help center articles, README files, and FAQ pages into Chroma ahead of time using a simple ingestion script, and re-run it whenever your docs change.

    Securing Your Deployment

    A customer support AI agent handles real customer data, which means it’s a security-sensitive service, not a side project. Treat it accordingly.

    Reverse Proxy and TLS

    Never expose the FastAPI service or Ollama’s API directly to the internet. Put Nginx in front, terminate TLS there, and only proxy the /chat endpoint:

    server {
    listen 443 ssl;
    server_name support.yourdomain.com;

    ssl_certificate     /etc/nginx/certs/fullchain.pem;
    ssl_certificate_key /etc/nginx/certs/privkey.pem;

    location /chat {
        proxy_pass http://support-agent:8000/chat;
        proxy_set_header Host $host;
        limit_req zone=support_limit burst=10 nodelay;
    }
}

    Add a rate-limiting zone (limit_req_zone) in the main Nginx config to prevent abuse — an unauthenticated chat endpoint is a common target for scraping or prompt-injection probing. If you’re new to reverse proxy configuration, our Nginx vs. Traefik comparison covers which tool fits which use case.

    For certificate management, Let’s Encrypt via Certbot handles renewal automatically and costs nothing.

  • Strip PII from logs before they hit disk or a log aggregator.
  • Run the agent containers as non-root users in your Dockerfile.
  • Set explicit resource limits (mem_limit, cpus) so a runaway inference request can’t take down the host.
  • Rotate any API keys used for hosted fallback models on a regular schedule.

    • Monitoring and Uptime

    Once this is customer-facing, you need to know immediately if it goes down. A dropped support widget is a worse customer experience than no widget at all. Pair container-level health checks in Compose with an external uptime monitor so you’re alerted from outside your own network — if your VPS loses connectivity entirely, an internal check won’t catch it.

    healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost:8000/health"]
  interval: 30s
  timeout: 5s
  retries: 3

    We’ve written more on building out this kind of setup in our self-hosted monitoring stack guide, which pairs well with an external service like BetterStack for uptime alerts and incident status pages — worth it for anything customer-facing.

    Scaling Considerations

    A single VPS handles a surprising amount of traffic for a text-based agent, since inference is the bottleneck, not I/O. When you outgrow one box:

  • Move Ollama to a GPU-backed instance and keep the lightweight FastAPI/Chroma services on a standard VM.
  • Separate the vector store onto its own host once your document set exceeds a few thousand chunks.
  • Add a queue (Redis or RabbitMQ) in front of the chat endpoint if you expect burst traffic from marketing campaigns or outages driving support volume up.

    • For the underlying compute, DigitalOcean droplets are a solid starting point for the whole stack, and Hetzner is worth comparing if you want more RAM per dollar for running larger local models. Both support the Docker-based deployment described here without any changes to the Compose file.

    Recommended: Ready to put this into practice? DigitalOcean is a tool we use for exactly this, and we have a real, disclosed affiliate relationship with them.

    FAQ

    Do I need a GPU to run a customer support AI agent locally?
    No. Models in the 7B–8B parameter range (like Llama 3 8B) run acceptably on CPU for low-to-moderate traffic. A GPU becomes worthwhile once you need sub-second response times or want to run larger, more capable models.

    How is this different from just using ChatGPT with a custom prompt?
    A hosted API call to ChatGPT is simpler to start with, but you lose data control and pay per token. This self-hosted setup grounds answers in your own documents via RAG and keeps all customer data on infrastructure you control — important if you handle regulated data.

    Can this fully replace human support agents?
    For tier-1 questions answerable from documentation, yes. Build in an explicit escalation path — the prompt in the example above already instructs the model to say it will escalate rather than guess, which you should route to a human queue or ticketing system.

    How do I keep the knowledge base up to date?
    Re-run your ingestion script into Chroma whenever your docs change. Many teams hook this into a CI/CD pipeline so a merge to the docs repo automatically re-indexes the content.

    Is a self-hosted customer support AI agent FTC or compliance safe?
    Self-hosting doesn’t automatically grant compliance, but it does give you full control over data retention, logging, and access — which makes meeting requirements like GDPR or SOC 2 controls significantly easier than depending on a third-party vendor’s data handling policies.

    What happens if the LLM gives a wrong answer to a customer?
    Build a feedback loop: log every conversation, flag low-confidence or escalated responses, and review them weekly. Treat wrong answers as gaps in your retrieval documents, not just model failures, and update the source docs accordingly.

    Related articles:

  • AI Agent Store: A Practical Guide to Self-Hosting Now

    AI Agent Store: How to Build, Deploy, and Manage Your Own

    Disclosure: This post contains one or more links to providers we have a real, registered affiliate/referral relationship with. We may earn a commission at no extra cost to you if you sign up through them.

    An ai agent store is quickly becoming standard infrastructure for teams running autonomous LLM agents in production. Instead of hardcoding a single agent into an app, a store gives you a catalog: versioned agents, sandboxed execution, access control, and a place for internal teams (or customers) to discover and launch agents on demand. If you already run Docker in production, you have most of the pieces needed to stand one up yourself instead of paying for a hosted marketplace.

    This guide walks through what an ai agent store actually is, how to architect one, and how to deploy, secure, and monitor it on your own infrastructure.

    What Is an AI Agent Store?

    An ai agent store is a catalog-and-runtime system for AI agents — small autonomous or semi-autonomous programs built on top of LLMs that can call tools, hit APIs, read files, and take multi-step actions. The “store” part means agents are packaged, versioned, and installable, similar to a plugin marketplace, but each install typically spins up an isolated runtime rather than just loading a script.

    Most commercial offerings (OpenAI’s GPT store, various agent marketplaces built on top of frameworks like LangChain ) work the same way conceptually: a manifest describes the agent’s capabilities and permissions, a backend enforces sandboxing, and a frontend lets users browse and launch.

    Why Developers Are Building Their Own

    Teams self-host an ai agent store for a few recurring reasons:

  • Data residency — agents that touch customer data can’t always leave your VPC
  • Cost control — per-seat marketplace pricing gets expensive at scale
  • Custom tooling — internal agents need access to internal APIs that public stores can’t reach
  • Compliance — regulated industries need audit logs and access control that generic marketplaces don’t expose

    • If you’re already comfortable with container orchestration, none of this requires new infrastructure paradigms — it’s Docker, a reverse proxy, a database, and a queue.

    AI Agent Store vs. Traditional App Marketplaces

    A normal app store distributes static binaries or containers that run once you install them. An ai agent store distributes behavior — agents that make live LLM calls, hold state across a session, and often need outbound network access to call tools. That changes your security model significantly: you’re not just validating a package checksum, you’re sandboxing an entity that can make arbitrary API calls on your behalf.

    Architecture of a Self-Hosted AI Agent Store

    A minimal but production-viable ai agent store needs five pieces working together.

    Core Components

  • Registry — stores agent manifests, versions, and permission scopes (usually Postgres)
  • Runtime workers — isolated containers that actually execute agent code
  • API gateway — handles auth, rate limiting, and routes requests to the right worker
  • Queue — decouples agent invocation from execution (Redis or RabbitMQ work fine)
  • Frontend/catalog UI — lets users browse, install, and launch agents

    • Here’s a minimal docker-compose.yml that ties the backend pieces together for local development:

    version: "3.9"
services:
  registry-db:
    image: postgres:16
    environment:
      POSTGRES_DB: agent_store
      POSTGRES_USER: agent_admin
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - registry_data:/var/lib/postgresql/data

  queue:
    image: redis:7-alpine
    command: ["redis-server", "--requirepass", "${REDIS_PASSWORD}"]

  gateway:
    image: agentstore/gateway:latest
    environment:
      DATABASE_URL: postgres://agent_admin:${DB_PASSWORD}@registry-db:5432/agent_store
      REDIS_URL: redis://:${REDIS_PASSWORD}@queue:6379
    ports:
      - "8080:8080"
    depends_on:
      - registry-db
      - queue

  worker:
    image: agentstore/worker:latest
    environment:
      REDIS_URL: redis://:${REDIS_PASSWORD}@queue:6379
    deploy:
      replicas: 3
    depends_on:
      - queue

volumes:
  registry_data:

    Each agent runs inside its own worker container with no shared filesystem access to other agents — this is the single most important isolation boundary in the whole design.

    Deploying an AI Agent Store with Docker

    Once the compose file is validated locally, deploying to a VPS is straightforward. If you haven’t containerized services before, our Docker Compose guide covers the basics of services, networks, and volumes in more depth.

    Provision a server, install Docker, and pull the images:

    # On a fresh Ubuntu 22.04+ VPS
curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER
newgrp docker

# Pull and start the stack
docker compose pull
docker compose up -d

# Confirm all services are healthy
docker compose ps

    Check the gateway logs to confirm the registry connected correctly before opening the port to the public internet:

    docker compose logs -f gateway

    For anything beyond a demo, run the worker service with resource limits so a single misbehaving agent can’t exhaust host memory or CPU:

    docker update --memory=512m --cpus=1 $(docker compose ps -q worker)

    Setting Up a Reverse Proxy and TLS

    Never expose the gateway directly. Put a reverse proxy in front of it and terminate TLS there. Caddy is the simplest option because it handles certificate renewal automatically:

    # Caddyfile
store.yourdomain.com {
    reverse_proxy localhost:8080
    encode gzip
    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
        X-Content-Type-Options "nosniff"
    }
}

    Run it with:

    sudo caddy run --config Caddyfile

    That’s a working, TLS-terminated ai agent store reachable at your domain, with the gateway itself never directly exposed.

    Securing Your AI Agent Store

    The biggest security gap in self-hosted agent platforms isn’t the container boundary — it’s what the agent is allowed to call. An agent with an unrestricted outbound network policy can exfiltrate data or hit internal services it was never meant to reach.

    Authentication and Rate Limiting

    At minimum, enforce:

  • API keys or OAuth tokens scoped per user, not per organization
  • Rate limits per agent, not just per user, since one runaway agent can generate thousands of LLM calls in minutes
  • An egress allowlist per agent manifest, so tool calls can only reach domains explicitly declared
  • Signed manifests, so a worker refuses to run an agent whose code doesn’t match its registered checksum

    • Review the OWASP API Security Top 10 when designing the gateway — broken object-level authorization and excessive data exposure are the two failure modes that show up most often in agent platforms specifically, since agents frequently act on behalf of a user across multiple internal APIs.

    If your store is public-facing, put it behind a WAF and DDoS-mitigating CDN. Cloudflare’s free and Pro tiers cover most of this out of the box, and their Cloudflare proxy layer also gives you bot-fight mode, which matters once your store gets scraped by other agents.

    Monitoring and Scaling

    Once agents are running real traffic, you need visibility into per-agent latency, error rate, and LLM token spend — a single slow tool call can cascade into a queue backlog. Our self-hosted monitoring stack guide walks through wiring up Prometheus and Grafana for container-level metrics.

    For uptime and incident alerting specifically, a hosted monitor is usually less work than running your own. BetterStack combines uptime checks with log management, so you get paged the moment the gateway or a worker pool goes unhealthy, without maintaining a separate alerting pipeline.

    Scaling horizontally is just adding worker replicas:

    docker compose up -d --scale worker=8

    Watch queue depth as your scaling signal — if jobs are piling up faster than workers drain them, add replicas before latency complaints start coming in.

    Choosing Infrastructure: VPS Providers Compared

    An ai agent store is CPU- and memory-bound more than it’s storage-bound, since most of the heavy lifting (the actual model inference) happens against an external LLM API. That makes it a good fit for straightforward compute VPS plans rather than specialized GPU instances.

  • DigitalOcean — simplest managed Kubernetes and droplet setup if your team is already comfortable with their tooling; good docs, predictable pricing
  • Hetzner — best raw price-per-core in Europe, solid choice if latency to US customers isn’t critical
  • BetterStack — not compute, but pairs well with either provider above for monitoring and incident response

    • If you’re just getting started and want managed droplets with one-click Docker images, DigitalOcean removes a lot of the initial provisioning work — their marketplace image comes with Docker and Docker Compose preinstalled, so you can git clone your stack and run docker compose up -d within minutes of provisioning.


    Recommended: Want to explore DigitalOcean yourself? DigitalOcean is a direct vendor link (not an affiliate/tracked link).

    FAQ

    What’s the difference between an AI agent store and an agent framework like LangChain?
    A framework gives you the building blocks to write a single agent. A store is the distribution and runtime layer on top — it catalogs many agents, versions them, and runs each in isolation so users can browse and launch them without touching code.

    Do I need Kubernetes to run an ai agent store?
    No. Docker Compose on a single well-sized VPS handles low-to-moderate traffic fine. Move to Kubernetes or Nomad only once you need multi-node worker scaling or zero-downtime rolling deploys across many hosts.

    How do I stop an agent from making unauthorized API calls?
    Enforce an egress allowlist per agent manifest at the network level (iptables, a sidecar proxy, or Cloudflare Gateway rules), not just at the application layer. Application-layer checks can be bypassed if the agent’s code is compromised; network-level restrictions can’t.

    Can I monetize a self-hosted ai agent store?
    Yes — most self-hosted stores gate access with API keys tied to a billing plan, then meter usage per LLM call or per agent-minute. Stripe metered billing integrates cleanly with the gateway’s request logs for this.

    What database should back the agent registry?
    Postgres is the standard choice — it handles manifest storage, versioning, and permission scopes well, and most agent-store open source projects assume it by default.

    Is it safe to let third parties publish agents to my store?
    Only with mandatory manifest review, signed packages, and strict sandboxing per agent. Treat third-party agent code the same way you’d treat untrusted user-uploaded code — because functionally, that’s what it is.

    Self-hosting an ai agent store is a reasonable weekend project if you already run Docker in production: the hard part isn’t the deployment, it’s getting the sandboxing and egress controls right before you let real agents run against real data.

    Related articles:

  • Agentic AI Tools: A DevOps Guide for 2026

    Agentic AI Tools for DevOps: What They Are and How to Deploy Them Safely

    Disclosure: This post contains one or more links to providers we have a real, registered affiliate/referral relationship with. We may earn a commission at no extra cost to you if you sign up through them.

    Agentic AI tools have moved from research demos to production infrastructure faster than almost any technology in the last decade. If you run a Kubernetes cluster, manage CI/CD pipelines, or maintain a fleet of VPS instances, you’ve probably already been pitched an “AI agent” that promises to write your Terraform, triage your alerts, or patch your dependencies while you sleep. Some of these tools deliver. Many don’t. This guide breaks down what agentic AI tools actually are, which ones are worth your time, and how to run them safely in a real DevOps environment.

    What Makes an AI Tool “Agentic”

    A standard chatbot or code-completion model answers a prompt and stops. An agentic AI tool does something fundamentally different: it plans a sequence of steps, executes actions using external tools (shell commands, APIs, file systems), observes the results, and adjusts its next step based on that feedback — all without a human approving each individual action.

    The Core Loop: Plan, Act, Observe

    Every agentic system, regardless of vendor, implements some variation of the same loop:

  • Plan — the model decomposes a goal into a sequence of subtasks
  • Act — it calls a tool (a shell command, an HTTP request, a database query) to execute one subtask
  • Observe — it reads the output or error from that action
  • Reflect — it decides whether to continue, retry, or change course based on the observation

    • This loop is what separates an agentic tool like Claude Code or Auto-GPT-style frameworks from a static code generator. It’s also what makes them risky in production — an agent that can execute shell commands can also delete a volume, drop a table, or leak a credential if it’s not sandboxed properly.

    Why DevOps Teams Care

    DevOps work is repetitive in a way that maps cleanly onto agent loops: read logs, identify an anomaly, correlate it with a deploy, roll back or patch, verify. Teams are increasingly wiring agentic tools into their CI/CD pipelines to handle exactly this kind of triage, freeing engineers for architecture work instead of firefighting.

    Popular Agentic AI Tools for DevOps Workflows

    The agentic AI space is crowded, but a handful of tools have proven themselves in real infrastructure work rather than staying demo-ware.

  • Claude Code — an agentic coding assistant that can read a repo, run tests, and open pull requests autonomously within permission boundaries you define
  • LangChain / LangGraph — a framework (not a finished product) for building custom agent pipelines with tool-calling, memory, and multi-step planning
  • AutoGPT — one of the earliest open-source autonomous agent frameworks, still useful for simple, bounded automation tasks
  • CrewAI — orchestrates multiple specialized agents (a “crew”) that collaborate on a single goal, useful for splitting infra tasks across role-specific agents
  • n8n with AI nodes — a workflow automation tool that now supports LLM-driven decision nodes, popular for gluing agentic behavior into existing ops pipelines

    • Most teams don’t pick just one. A common pattern is LangGraph or CrewAI for the orchestration layer, with Claude or GPT-based models doing the actual reasoning, and a thin custom wrapper enforcing what commands the agent is allowed to run.

    Evaluating a Tool Before You Adopt It

    Before wiring any agentic tool into production, check three things: does it support a dry-run or plan-only mode, does it log every tool call it makes, and can you restrict its execution environment. If a vendor can’t answer those three questions clearly, don’t put it near production credentials yet.

    Running Agentic AI Tools in Docker Containers

    The single most effective security control for agentic AI tools is containment. An agent that can only see a scratch filesystem and a locked-down network namespace can’t do much damage even if it goes off the rails.

    Here’s a minimal Dockerfile for sandboxing an agent runtime:

    FROM python:3.12-slim

RUN useradd --create-home --shell /bin/bash agent
WORKDIR /home/agent/workspace

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

USER agent
COPY --chown=agent:agent . .

ENTRYPOINT ["python", "run_agent.py"]

    And a docker-compose.yml that pairs the agent with resource limits and a read-only mount for anything it shouldn’t be able to modify:

    version: "3.9"
services:
  agent:
    build: .
    networks:
      - agent-net
    read_only: true
    tmpfs:
      - /tmp
    volumes:
      - ./workspace:/home/agent/workspace:rw
      - ./config:/home/agent/config:ro
    deploy:
      resources:
        limits:
          cpus: "1.0"
          memory: 1g
    environment:
      - AGENT_MAX_STEPS=25
      - AGENT_DRY_RUN=false

networks:
  agent-net:
    driver: bridge
    internal: true

    Setting internal: true on the network means the container has no route to the public internet unless you explicitly proxy it — a useful default for an agent that only needs to talk to your internal API, not fetch arbitrary URLs. Full details on this networking pattern are in Docker’s own network drivers documentation.

    Isolating Credentials from the Agent Process

    Never mount your cloud provider’s full credentials file into an agent container. Instead, issue short-lived, scoped tokens — an IAM role with only the permissions the agent’s task actually requires — and inject them as environment variables with a TTL. If you’re running these workloads on a VPS rather than managed Kubernetes, a provider like DigitalOcean makes it straightforward to spin up an isolated droplet per agent workload, so a compromised or misbehaving agent can’t pivot into unrelated infrastructure.

    Security Considerations for Agentic AI Tools

    The tool-calling capability that makes agentic AI useful is the same capability that makes it dangerous. Treat every agentic AI deployment as if it were a junior engineer with root access and no judgment about blast radius, because functionally, that’s what it is.

    Prompt Injection and Untrusted Input

    If your agent reads content from external sources — GitHub issues, incoming emails, scraped web pages — that content can contain instructions designed to hijack the agent’s next action. This is called prompt injection, and it’s the top real-world risk in agentic deployments today. The OWASP guidance on LLM security covers this in depth and is worth reading before you let an agent process anything from outside your organization.

    Practical mitigations:

  • Never let an agent execute shell commands derived directly from untrusted text without a human-reviewable diff
  • Strip or sandbox any content fetched from the web before it reaches the model’s context
  • Set a hard cap on the number of autonomous steps an agent can take before requiring human confirmation
  • Log every tool call with full arguments, not just a summary, so you can audit after the fact

    • Least Privilege Is Non-Negotiable

    An agent should never hold credentials broader than the single task it’s assigned. If it only needs to restart a service, give it a token scoped to that service, not your whole orchestration API. This is the same principle you’d apply to any service account in a Kubernetes cluster — agentic AI doesn’t change the fundamentals of access control, it just makes the consequences of getting it wrong happen faster and without a human in the loop to notice.

    Monitoring and Observability for Agent Workflows

    You can’t debug an autonomous agent after the fact if you didn’t log its reasoning and actions in the first place. Treat agent activity like any other production traffic: instrument it, alert on it, and keep the retention long enough to investigate an incident days later.

    A few things worth tracking specifically for agentic workloads:

  • Number of tool calls per task, and alerts when a task exceeds its expected step budget
  • Rate of failed or retried actions, which often signals the agent is stuck in a loop
  • Every external network call the agent initiates, correlated with the task that triggered it
  • Token and cost consumption per agent run, since runaway loops burn API budget fast

    • A service like BetterStack works well here since it can ingest structured logs from your agent runtime and alert you the moment an agent’s step count or error rate crosses a threshold, rather than you discovering a stuck loop from an unexpected bill.

    Final Thoughts

    Agentic AI tools are genuinely useful for DevOps work — triage, routine remediation, and repetitive infrastructure tasks are exactly the kind of bounded, observable loops these tools handle well. But “agentic” is also a marketing word, and not every tool wearing it deserves production credentials. Start with heavy containment, least-privilege access, and full logging, and only loosen those constraints once you’ve watched the agent behave correctly under supervision for a while. If you’re building out the surrounding infrastructure, our guide to choosing a VPS for containerized workloads covers the hosting side of this decision in more detail.


    Recommended: Want to explore DigitalOcean yourself? DigitalOcean is a direct vendor link (not an affiliate/tracked link).

    FAQ

    What is the difference between agentic AI and generative AI?
    Generative AI produces a single output — text, code, an image — in response to a prompt and stops there. Agentic AI plans and executes a multi-step sequence of actions autonomously, using tools and observing results, to accomplish a broader goal without step-by-step human input.

    Are agentic AI tools safe to run in production?
    They can be, but only with proper containment: sandboxed execution environments, scoped credentials, step limits, and full audit logging. Running an agent with broad, unscoped access is the primary cause of documented agentic AI incidents.

    Do agentic AI tools need internet access?
    Only if their task requires it. Many DevOps use cases — log triage, internal API calls, config management — work fine on an internal-only Docker network, which meaningfully reduces the attack surface.

    Which agentic AI framework should I start with?
    If you want a ready-made coding agent, Claude Code is a strong starting point. If you need custom orchestration across multiple specialized agents, LangGraph or CrewAI give you more control over the underlying loop.

    How do I prevent prompt injection in an agentic pipeline?
    Sanitize any content pulled from untrusted sources before it enters the model’s context, cap autonomous steps, and require human review before an agent acts on instructions found inside external data like emails or scraped pages.

    What’s a reasonable first production use case for agentic AI in DevOps?
    Log triage and alert correlation is a common starting point — it’s high-volume, well-bounded, and low-risk since the agent’s output is typically a recommendation or draft action rather than an irreversible change.

    Related articles:

  • AI Voice Agents for Customer Service: Self-Hosted Guide

    AI Voice Agents for Customer Service: A Self-Hosted Deployment Guide

    Disclosure: This post contains one or more links to providers we have a real, registered affiliate/referral relationship with. We may earn a commission at no extra cost to you if you sign up through them.

    AI voice agents for customer service have moved past the novelty phase. They now handle tier-1 support calls, appointment scheduling, and order status lookups at a fraction of the cost of a human agent bank. But most of the marketing around this space glosses over the actual infrastructure work: standing up speech-to-text, an LLM orchestration layer, text-to-speech, and telephony integration in a way that’s reliable, observable, and doesn’t leak customer data to five different SaaS vendors.

    This guide is written for developers and sysadmins who need to actually deploy this stack, not just read about it. We’ll cover the architecture, containerize the core components, wire up monitoring, and talk through the tradeoffs between self-hosting and using managed APIs.

    Why Self-Host AI Voice Agents

    Most teams start with a managed platform (Vapi, Retell, Bland) because it’s fast to prototype. The problem shows up at scale: per-minute pricing adds up fast on high call volumes, and you’re locked into whatever latency and uptime your vendor delivers. If you’re running a support desk that handles thousands of calls a day, the economics shift hard toward self-hosting the pipeline on your own cloud infrastructure and only paying per-token for the LLM calls you actually make.

    Self-hosting also matters for compliance. If you’re in healthcare, finance, or anywhere with strict data residency rules, sending raw customer audio to a third-party voice AI platform is a liability. Running the stack yourself means you control where transcripts and recordings live.

    Core Components of a Voice Agent Pipeline

    A production AI voice agent for customer service is really four services chained together:

  • Telephony ingress — SIP trunk or WebRTC gateway that receives the call (Twilio, Telnyx, or a self-hosted Asterisk/FreeSWITCH box)
  • Speech-to-text (STT) — streaming transcription, typically Whisper-based (faster-whisper, whisper.cpp) or a hosted API like Deepgram
  • LLM orchestration — the actual conversation logic, intent detection, and function calling into your CRM or ticketing system
  • Text-to-speech (TTS) — converts the LLM’s response back to audio, using something like Coqui TTS, ElevenLabs, or Piper for a fully local option

    • Each of these can run in its own container, which makes the whole thing easier to scale independently. STT and TTS are GPU-hungry; the orchestration layer usually isn’t.

    Containerizing the Stack with Docker

    Here’s a minimal docker-compose.yml that stands up a local voice agent pipeline using open-source components. This assumes you have an NVIDIA GPU available for the STT/TTS containers.

    version: '3.8'

services:
  stt:
    image: onerahmet/openai-whisper-asr-webservice:latest-gpu
    environment:
      - ASR_MODEL=base.en
      - ASR_ENGINE=faster_whisper
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    ports:
      - "9000:9000"

  orchestrator:
    build: ./orchestrator
    environment:
      - LLM_API_URL=http://llm:8000
      - STT_URL=http://stt:9000
      - TTS_URL=http://tts:5002
    ports:
      - "8080:8080"
    depends_on:
      - stt
      - tts

  tts:
    image: ghcr.io/coqui-ai/tts
    command: --model_name tts_models/en/vctk/vits
    ports:
      - "5002:5002"

  llm:
    image: ollama/ollama:latest
    volumes:
      - ollama_data:/root/.ollama
    ports:
      - "8000:11434"
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

volumes:
  ollama_data:

    Bring it up with:

    docker compose up -d
docker compose logs -f orchestrator

    The orchestrator service is your own code — it handles the WebSocket stream from the telephony layer, sends audio chunks to stt, feeds the transcript into the LLM with function-calling tools for things like “look up order status” or “schedule callback,” and pipes the response text to tts before streaming audio back to the caller.

    Wiring Up Telephony

    For the telephony leg, Twilio’s Media Streams API is the fastest path to production if you don’t want to run your own SIP infrastructure. It streams raw audio over a WebSocket to your orchestrator in real time, which is exactly what the pipeline above expects.

    A minimal webhook handler in Python looks like this:

    from fastapi import FastAPI, WebSocket
import base64
import json

app = FastAPI()

@app.websocket("/media-stream")
async def media_stream(websocket: WebSocket):
    await websocket.accept()
    async for message in websocket.iter_text():
        data = json.loads(message)
        if data["event"] == "media":
            audio_chunk = base64.b64decode(data["media"]["payload"])
            # forward audio_chunk to your STT service here
            pass

    If you’d rather avoid Twilio’s per-minute fees entirely, FreeSWITCH and Asterisk are both viable for running your own SIP trunk, though you’ll need a VoIP provider for actual PSTN connectivity either way.

    Latency Is the Whole Game

    The single biggest failure mode in AI voice agents for customer service isn’t accuracy — it’s latency. Callers tolerate a 1-2 second pause before a response starts, but anything beyond that feels broken and people hang up or start talking over the agent.

    To hit acceptable latency you need:

  • Streaming STT (partial transcripts as the caller speaks, not wait-for-silence batch transcription)
  • A small, fast LLM for the orchestration layer — a 7B-13B parameter model is usually enough for structured customer service flows, and it’s dramatically faster than routing every turn through a large frontier model
  • Streaming TTS that starts playing audio before the full response is generated
  • Co-locating STT, LLM, and TTS on the same host or same low-latency network to avoid round-trip overhead between services

    • Running these components on a GPU-backed VPS close to your telephony provider’s edge nodes matters more than most people expect. A provider like DigitalOcean with GPU droplets in the right region can shave real milliseconds off your round trip compared to a generic cloud region pick.

    Monitoring and Observability

    Voice agent pipelines fail in ways that are hard to catch with standard uptime checks — a service can be “up” while silently producing garbled transcripts or dead air. You need call-level observability, not just container health checks.

    At minimum, log and alert on:

  • STT confidence scores per call segment
  • End-to-end response latency (time from caller stops speaking to audio starts playing back)
  • LLM function-call failures (e.g., CRM lookup timeouts)
  • Call abandonment rate mid-conversation

    • A tool like BetterStack works well here for aggregating logs across all four containers into one place and alerting when latency or error rates spike, without you having to build a custom dashboard from scratch.

    For deeper infrastructure monitoring on the underlying hosts, see our guide on setting up Prometheus and Grafana on a Docker host — the same setup applies directly to a voice agent stack, you’re just adding custom metrics for call latency and STT confidence alongside standard container metrics.

    Scaling Beyond a Single Host

    Once you’re past a handful of concurrent calls, a single Docker host runs out of GPU capacity fast. The orchestrator service is stateless per-call and scales horizontally without much thought — just run multiple replicas behind a load balancer. STT and TTS are the bottleneck since they need GPU memory per active stream.

    A reasonable scaling pattern:

    # Scale the orchestrator to handle more concurrent calls
docker compose up -d --scale orchestrator=4

# Check GPU utilization to decide if you need another STT/TTS host
nvidia-smi --query-gpu=utilization.gpu,memory.used --format=csv -l 5

    At real scale, teams typically move from docker compose to Kubernetes so they can autoscale STT/TTS pods based on GPU queue depth, and route calls through a message queue rather than direct WebSocket connections to a single orchestrator instance. That’s a bigger architectural jump and worth its own dedicated writeup — for most teams under a few hundred concurrent calls, a well-tuned multi-host Docker Compose setup is enough.

    Bare-metal or dedicated GPU hosts from a provider like Hetzner are worth considering once you’re running sustained GPU load 24/7, since the hourly cost of cloud GPU instances adds up fast compared to a dedicated box you’re not spinning down.

    Security and Data Handling

    Customer service calls often contain PII — names, addresses, account numbers, sometimes payment details if callers aren’t careful about what they say. A few non-negotiables:

  • Encrypt call recordings and transcripts at rest
  • Set a retention policy and actually enforce it with a cron job or lifecycle rule, don’t just document it
  • Redact or mask sensitive data before it hits your LLM context if you’re using any external API for the orchestration layer
  • Run the telephony ingress behind a WAF if it’s exposed to the public internet — Cloudflare covers this well for WebSocket and HTTP traffic without much configuration overhead

    • If you’re routing any part of the pipeline through a third-party LLM API instead of a self-hosted model, read their data retention terms carefully. Some providers train on API traffic by default unless you opt out, which is a non-starter for customer PII.


    Recommended: Want to explore DigitalOcean yourself? DigitalOcean is a direct vendor link (not an affiliate/tracked link).

    FAQ

    Q: Do I need a GPU to run AI voice agents for customer service?
    A: For the STT and TTS components, yes, if you want real-time streaming performance. You can run whisper.cpp on CPU for STT, but latency will be noticeably worse under concurrent load. The LLM orchestration layer can run on CPU if you use a small quantized model, though a GPU is still faster.

    Q: How much does self-hosting save compared to a managed platform like Vapi or Retell?
    A: It depends heavily on call volume. Managed platforms typically charge $0.05-$0.15 per minute. At low volume (a few hundred calls a month) that’s cheaper than running dedicated GPU infrastructure. Past a few thousand calls a month, self-hosting on your own DevOps infrastructure usually wins on cost, but you’re trading dollars for engineering time.

    Q: Can I use ChatGPT or Claude as the LLM in this pipeline?
    A: Yes, via API calls from your orchestrator service. It’s simpler than self-hosting an LLM but adds network latency per turn and per-token cost. For high-volume, low-complexity flows (order status, FAQs), a self-hosted small model is usually faster and cheaper. For complex, open-ended conversations, a frontier model API is worth the tradeoff.

    Q: What’s an acceptable end-to-end latency target?
    A: Aim for under 800ms from when the caller stops speaking to when the agent’s audio starts playing. Above 1.5 seconds, callers start perceiving the agent as broken or start talking over it.

    Q: How do I handle callers who want to speak to a human?
    A: Build explicit intent detection for escalation phrases (“talk to a person,” “human agent”) into your orchestration logic, and have a hard fallback path to transfer the call via your telephony provider’s API rather than relying on the LLM to figure it out contextually every time.

    Q: Is it legal to record and transcribe customer service calls with an AI agent?
    A: Recording laws vary by jurisdiction — some US states require two-party consent. You need an explicit disclosure at the start of the call (“this call may be recorded and is handled by an automated assistant”) regardless of the tech stack, and you should confirm compliance requirements with legal counsel for your specific region before going live.

    Wrapping Up

    AI voice agents for customer service are genuinely useful infrastructure now, not hype, but the deployment reality is closer to running a real-time media pipeline than deploying a simple chatbot. Get the latency budget right, containerize each stage so you can scale independently, and don’t skip observability — silent failures in a voice pipeline are worse than a service just going down, because the caller experience degrades without any alert firing. Start small with a Docker Compose setup like the one above, measure real call latency, and scale the pieces that actually bottleneck under your traffic before reaching for Kubernetes.

    Related articles:

  • AI Real Estate Agents: Self-Hosted Deployment Guide

    AI Real Estate Agents: A Developer’s Guide to Building and Deploying Autonomous Property Bots

    Disclosure: This post contains one or more links to providers we have a real, registered affiliate/referral relationship with. We may earn a commission at no extra cost to you if you sign up through them.

    “AI real estate agent” gets thrown around loosely — sometimes it means a chatbot bolted onto a Zillow clone, sometimes it means a fully autonomous system that qualifies leads, schedules showings, and drafts offer letters without a human in the loop. If you’re a developer or sysadmin tasked with actually building or self-hosting one of these systems — instead of paying $300/month for a SaaS wrapper around GPT-4 — this guide walks through the real architecture: the stack, the deployment, and the operational gotchas nobody puts in the marketing copy.

    We’re not covering “how real estate agents can use ChatGPT.” We’re covering how to stand up your own AI real estate agent service — containerized, monitored, and production-ready — on infrastructure you control.

    What Are AI Real Estate Agents, Really?

    Strip away the marketing and an AI real estate agent is a pipeline with four moving parts:

  • A conversational interface (web widget, SMS, or voice) that captures buyer/seller intent
  • A retrieval layer that pulls relevant listings, comps, or MLS data
  • An LLM that reasons over that data and drafts responses, summaries, or documents
  • A task-execution layer that books calendar slots, sends emails, or updates a CRM

    • None of this requires proprietary tech from a real estate startup. It’s the same retrieval-augmented generation (RAG) pattern used in support bots and internal knowledge assistants, just pointed at property data instead of a knowledge base.

    From Chatbots to Autonomous Agents

    The distinction that matters for architecture is “agent” vs. “assistant.” An assistant answers questions. An agent takes actions — it can call tools (search a listings API, write to a database, send an email) based on its own reasoning about what step comes next. That’s the piece that turns a Q&A bot into something a brokerage will actually pay to have running 24/7 without a human approving every message.

    If you’ve built agent tooling with LangChain or the OpenAI Assistants API, the pattern will feel familiar. Real estate just adds domain-specific tools: MLS/IDX feed lookups, mortgage calculators, and scheduling integrations.

    Why Build This Yourself Instead of Buying SaaS

    Off-the-shelf platforms bundle the LLM, the data, and the hosting into one subscription. That’s fine if you just need a lead-qualification bot. It falls apart when:

  • You need the bot on infrastructure that meets your brokerage’s data-residency or compliance requirements
  • You want to swap the underlying model (say, moving from GPT-4o to a self-hosted Llama model) without a vendor contract
  • You’re integrating the agent into an existing stack — CRM, IDX feed, internal analytics — that the SaaS tool doesn’t support
  • The per-seat or per-lead pricing stops making sense once you’re doing volume

    • For a small brokerage or a solo developer client, self-hosting the stack on a $20/month VPS is often cheaper than a single SaaS seat, and you own the data pipeline outright.

    The Stack: LLM, Vector Search, and Listing Data

    A minimal production stack looks like this:

  • API layer: FastAPI or Express, handling inbound chat/webhook traffic
  • LLM provider: OpenAI, Anthropic, or a self-hosted model behind Ollama
  • Vector store: Postgres with the pgvector extension, or a dedicated store like Qdrant
  • Task queue: Redis or a lightweight cron for follow-up messages and reminders
  • Reverse proxy / TLS: Caddy or Nginx, sitting in front of everything

    • If you haven’t containerized a multi-service app before, our Docker Compose networking guide covers the service-discovery basics you’ll need before wiring these pieces together.

    Building a Minimal AI Real Estate Agent

    Here’s a docker-compose.yml for a bare-bones version: an API service, Postgres with pgvector for listing embeddings, and Redis for task scheduling.

    # docker-compose.yml
version: "3.9"

services:
  agent-api:
    build: ./api
    ports:
      - "8000:8000"
    environment:
      - OPENAI_API_KEY=${OPENAI_API_KEY}
      - DATABASE_URL=postgresql://agent:agent@db:5432/listings
      - REDIS_URL=redis://redis:6379/0
    depends_on:
      - db
      - redis
    restart: unless-stopped

  db:
    image: pgvector/pgvector:pg16
    environment:
      - POSTGRES_USER=agent
      - POSTGRES_PASSWORD=agent
      - POSTGRES_DB=listings
    volumes:
      - pgdata:/var/lib/postgresql/data
    restart: unless-stopped

  redis:
    image: redis:7-alpine
    restart: unless-stopped

volumes:
  pgdata:

    And a minimal FastAPI handler that retrieves relevant listings and asks the LLM to draft a response:

    # api/main.py
from fastapi import FastAPI
from openai import OpenAI
import psycopg2
import os

app = FastAPI()
client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])

def get_relevant_listings(query_embedding, limit=5):
    conn = psycopg2.connect(os.environ["DATABASE_URL"])
    cur = conn.cursor()
    cur.execute(
        """
        SELECT address, price, beds, baths, description
        FROM listings
        ORDER BY embedding <-> %s::vector
        LIMIT %s
        """,
        (query_embedding, limit),
    )
    rows = cur.fetchall()
    cur.close()
    conn.close()
    return rows

@app.post("/chat")
def chat(payload: dict):
    user_message = payload["message"]

    embedding = client.embeddings.create(
        model="text-embedding-3-small",
        input=user_message,
    ).data[0].embedding

    listings = get_relevant_listings(embedding)

    context = "n".join(
        f"{addr} - ${price:,} - {beds}bd/{baths}ba - {desc}"
        for addr, price, beds, baths, desc in listings
    )

    completion = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {"role": "system", "content": "You are a real estate assistant. Only reference listings provided in context."},
            {"role": "user", "content": f"Context:n{context}nnQuestion: {user_message}"},
        ],
    )

    return {"reply": completion.choices[0].message.content}

    This is intentionally minimal — no auth, no rate limiting, no retry logic — but it’s the whole loop: embed the query, retrieve matching listings from pgvector, and let the model reason over real data instead of hallucinating addresses.

    Wiring Up Listing Data and Embeddings

    The retrieval quality depends entirely on how you populate the listings table. In practice you’ll pull from an IDX/MLS feed (via RETS or a vendor API), generate an embedding per listing description with the same model you use at query time, and store it in the embedding column. Re-run this on a schedule — hourly is usually enough — since listings go pending or sell throughout the day and stale data is worse than no data.

    Deploying to Production

    Once the local stack works, deployment is standard container ops:

    1. Push images to a registry (or build directly on the host with docker compose build)
    2. Provision a VPS sized for the workload — 2 vCPU / 4GB RAM is plenty for low-to-moderate traffic
    3. Put Caddy or Nginx in front for automatic TLS
    4. Set up log aggregation and uptime alerting before you announce the bot is live, not after

    For the VPS itself, DigitalOcean droplets are a reasonable default if you want predictable pricing and a straightforward Docker-friendly image — spinning up a droplet with their Docker marketplace image gets you docker compose up in under five minutes. It’s one of the providers we recommend when readers ask where to host small containerized services; see our best cheap VPS providers roundup for other options if your budget or region needs differ.

    Hardening and Monitoring Your Deployment

    An agent that silently goes down mid-conversation with a lead is worse than no agent at all — the prospect just thinks the brokerage ignored them. Treat this like any other customer-facing service:

  • Put the /chat endpoint behind an API key or signed request check, not just network-level firewalling
  • Rate-limit per IP/session to avoid a single abusive user burning your OpenAI budget
  • Log every request/response pair (redacting PII as needed) so you can audit what the agent actually told a prospect
  • Set up uptime and latency monitoring — we run BetterStack for exactly this on client projects, since it alerts on both downtime and slow response regressions before a lead notices

    • Add a health check to compose so orchestration tools (or a simple systemd unit calling docker compose up -d) can restart failed containers automatically:

        healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8000/health"]
      interval: 30s
      timeout: 5s
      retries: 3

    Cost and Model Choice

    Budget for the LLM API bill separately from hosting. A mid-size brokerage running a few hundred conversations a day on gpt-4o-mini will spend far less than one SaaS seat, but it’s usage-based, so add billing alerts on the OpenAI dashboard. If you need to keep everything on-premises for compliance reasons, swapping the OpenAI client calls for a self-hosted Llama 3 model behind Ollama is a config change, not a rewrite — the RAG pipeline around it stays the same.

    Pre-Launch Checklist

    Before you point real traffic at this:

  • Confirm the vector search returns only active, non-expired listings
  • Add a fallback response for when retrieval returns nothing relevant
  • Test the agent’s behavior on adversarial or off-topic input (fair housing compliance matters here — the agent should never make decisions based on protected characteristics)
  • Set up backups for the Postgres volume
  • Load test the /chat endpoint before a marketing push drives a traffic spike


    • Recommended: Want to explore DigitalOcean yourself? DigitalOcean is a direct vendor link (not an affiliate/tracked link).

    FAQ

    Do AI real estate agents replace human agents?
    No, not for anything involving negotiation, legal review, or fair housing–sensitive decisions. They’re best used for lead qualification, listing search, and scheduling — the repetitive front-end work, not the parts requiring licensed judgment.

    What LLM should I use for a real estate chatbot?
    gpt-4o-mini or a comparable small Claude model handles most listing Q&A well at low cost. Reserve larger models for tasks that need more reasoning, like drafting comparative market analyses.

    Is self-hosting an AI agent actually cheaper than SaaS platforms?
    For low-to-moderate volume, yes — a $20-40/month VPS plus usage-based LLM costs typically undercuts per-seat SaaS pricing once you’re past a handful of conversations a day. The break-even shifts if you need a dedicated engineer to maintain it.

    How do I keep the agent from hallucinating fake listings?
    Never let the model answer from its own training data about “typical” properties. Always inject retrieved, real listing data into the prompt and instruct it explicitly to only reference what’s in context — the code example above does exactly this.

    Do I need a vector database, or can I just use keyword search?
    Keyword search works for exact address lookups but fails on natural-language queries like “3 bedroom near downtown under 400k with a yard.” Vector search (via pgvector or a dedicated store) handles semantic matching that keyword search misses.

    Is this legal to deploy without a licensed agent reviewing every message?
    That depends on your jurisdiction and what the agent is authorized to do — check with your broker or legal counsel, especially around fair housing law and any state requirements for licensed review of contract-related communication. This article covers the technical build, not legal compliance.

    Related articles:

  • AI Recruitment Agent: Self-Host One with Docker

    AI Recruitment Agent: Self-Host One with Docker

    Disclosure: This post contains one or more links to providers we have a real, registered affiliate/referral relationship with. We may earn a commission at no extra cost to you if you sign up through them.

    Hiring teams are drowning in resumes, and many are turning to automation to keep up. An AI recruitment agent can screen candidates, draft outreach messages, and schedule interviews without a SaaS subscription lock-in – if you’re willing to self-host it. This guide walks through building and deploying an AI recruitment agent using Docker, so you keep full control over candidate data, model costs, and infrastructure.

    Self-hosting isn’t just about saving on subscription fees. It’s about owning the pipeline: which model handles resume parsing, where candidate PII is stored, and how the agent’s decisions are logged for compliance. This article covers the architecture, the Docker Compose setup, integration patterns, and operational concerns you’ll hit in production.

    Why Self-Host an AI Recruitment Agent

    Commercial applicant tracking systems (ATS) with built-in AI features charge per-seat or per-candidate fees that scale poorly once you’re processing hundreds of applications a month. A self-hosted AI recruitment agent flips that cost model: you pay for compute and, optionally, API calls to a language model provider, but the orchestration layer itself is free and under your control.

    There are also practical reasons beyond cost:

  • Data residency – candidate resumes, contact details, and interview notes stay on infrastructure you control, which matters for GDPR or similar regional privacy regulations.
  • Customization – you can tune scoring criteria, add custom screening questions, or integrate with an internal HR tool without waiting on a vendor roadmap.
  • Vendor independence – if the AI provider changes pricing or terms, you swap the model backend without rebuilding your entire hiring workflow.

    • Common Use Cases

    Most self-hosted recruitment agents handle a mix of these tasks:

  • Parsing incoming resumes (PDF/DOCX) into structured candidate profiles
  • Scoring candidates against a job description using an LLM
  • Drafting personalized outreach or rejection emails
  • Auto-scheduling interviews by checking calendar availability
  • Flagging candidates for human review when confidence is low

    • Architecture of a Self-Hosted AI Recruitment Agent

    A production-grade AI recruitment agent is rarely a single script. It’s typically composed of a few cooperating services: an API layer that receives candidate data, a worker process that calls the LLM and runs scoring logic, a database for candidate records, and optionally a queue for handling bursts of applications.

    Running this as a set of Docker containers gives you clean separation of concerns and makes it straightforward to scale the worker independently of the API. It also means you can restart or update one component (say, the resume parser) without touching the rest of the stack.

    Core Components

    A typical stack includes:

    1. API/orchestrator service – receives webhook events (new application submitted), coordinates the pipeline, and exposes endpoints for the HR team’s dashboard.
    2. LLM worker – calls out to an inference API or a locally-hosted model to score resumes and generate text.
    3. Database – stores candidate profiles, scores, and audit logs. Postgres is a common and reliable choice here.
    4. Object storage or volume – holds uploaded resume files.
    5. Reverse proxy – terminates TLS and routes traffic to the right internal service.

    If you’re new to structuring multi-container automation like this, it’s worth reviewing how workflow orchestration platforms like n8n approach similar problems – see this guide on how to build AI agents with n8n for a comparable event-driven pattern you can borrow from.

    Setting Up the AI Recruitment Agent with Docker Compose

    Docker Compose is the fastest way to get an AI recruitment agent running locally or on a single VPS before you consider anything more complex like Kubernetes. Below is a minimal but realistic compose file covering the API, a worker, and Postgres.

    version: "3.9"

services:
  api:
    build: ./api
    ports:
      - "8080:8080"
    environment:
      - DATABASE_URL=postgresql://agent:agent@db:5432/recruitment
      - LLM_API_KEY=${LLM_API_KEY}
    depends_on:
      - db
    restart: unless-stopped

  worker:
    build: ./worker
    environment:
      - DATABASE_URL=postgresql://agent:agent@db:5432/recruitment
      - LLM_API_KEY=${LLM_API_KEY}
    depends_on:
      - db
    restart: unless-stopped

  db:
    image: postgres:16
    environment:
      - POSTGRES_USER=agent
      - POSTGRES_PASSWORD=agent
      - POSTGRES_DB=recruitment
    volumes:
      - db_data:/var/lib/postgresql/data
    restart: unless-stopped

volumes:
  db_data:

    Bring the stack up with:

    docker compose up -d
docker compose logs -f api

    If you haven’t containerized a Postgres-backed service before, the Postgres Docker Compose setup guide covers persistence, backups, and connection tuning in more depth than we can here.

    Handling Secrets Properly

    Never hardcode your LLM API key or database credentials directly in the compose file or commit them to version control. Use an .env file excluded from git, or better, Docker Compose’s native secrets support for anything touching production. The Docker Compose secrets guide walks through mounting secrets as files rather than environment variables, which reduces the risk of accidental leakage through process listings or logs.

    For managing the various API keys and configuration values an AI recruitment agent needs (LLM provider key, email service credentials, calendar API tokens), also see the Docker Compose environment variables guide for patterns that scale beyond a handful of values.

    Debugging the Worker Pipeline

    When your AI recruitment agent’s scoring worker misbehaves – say, resumes are parsed but never scored – your first stop should be the container logs. The Docker Compose logs debugging guide covers filtering by service, following logs in real time, and correlating timestamps across the API and worker containers, which is essential once you have more than two services running.

    Integrating the LLM Backend

    The core intelligence of an AI recruitment agent comes from the language model doing resume scoring and text generation. You have two broad options: call a hosted model API, or run an open-weight model yourself.

    Calling a hosted API (via HTTP from your worker container) is simpler operationally – no GPU provisioning, no model updates to manage – but it means candidate data leaves your infrastructure for each request, which may conflict with your data residency goals. Self-hosting a model locally (using something like a containerized inference server) keeps data in-house but adds real operational overhead: GPU costs, model updates, and latency tuning.

    Prompt Design for Resume Screening

    Whichever backend you choose, the prompt structure matters more than the model choice for consistent scoring. A reliable AI recruitment agent prompt typically:

  • Provides the job description and required qualifications as structured context
  • Asks for a numeric score plus a short justification, not just a yes/no verdict
  • Explicitly instructs the model to avoid inferring protected characteristics (age, gender, etc.) from resume content
  • Requests output in a fixed JSON schema so your worker can parse it reliably

    • Keeping the prompt template in version control alongside your worker’s code (rather than hardcoded inline) makes it much easier to audit and improve scoring behavior over time – a practice worth adopting from general agent-building guidance like this developer’s guide to creating an AI agent.

    Rate Limits and Retry Logic

    Hosted LLM APIs enforce rate limits, and a burst of applications (say, after a job posting goes live on a popular board) can trigger throttling. Your worker should implement exponential backoff and a dead-letter queue for resumes that fail scoring after repeated retries, rather than silently dropping them. This is a common gap in early recruitment agent prototypes that only gets discovered in production during a hiring surge.

    Deploying and Scaling in Production

    Once your AI recruitment agent works locally, deploying it reliably means thinking about uptime, updates, and where it actually runs.

    Choosing Infrastructure

    A single small VPS is enough to run an AI recruitment agent handling a modest volume of applications – the workload is bursty rather than constantly heavy, since most of the compute-intensive work (the LLM call itself) happens on the provider’s infrastructure, not yours. Providers like DigitalOcean and Hetzner offer VPS tiers well suited to this kind of orchestration workload. If you’re unfamiliar with running production services on a VPS without a managed control plane, the unmanaged VPS hosting guide is a good primer on what you’re responsible for versus what the provider handles.

    Zero-Downtime Updates

    Recruitment pipelines can’t afford to silently drop incoming applications during a deployment. When updating your worker or API image, rebuild and restart services one at a time rather than tearing down the whole stack:

    docker compose build worker
docker compose up -d --no-deps worker

    If you’re regularly rebuilding images during development, the Docker Compose rebuild guide covers when to use --no-deps, cache invalidation gotchas, and how to avoid rebuilding services that haven’t changed.

    Monitoring and Alerting

    An AI recruitment agent that silently stops processing applications is worse than no agent at all, since candidates may believe they’ve applied successfully when nothing happened downstream. At minimum, alert on:

  • Worker queue depth growing without corresponding processing
  • LLM API error rates exceeding a reasonable baseline
  • Database connection failures


    • Recommended: Want to explore DigitalOcean yourself? DigitalOcean is a direct vendor link (not an affiliate/tracked link).

    FAQ

    Do I need a GPU to self-host an AI recruitment agent?
    Not if you’re calling a hosted LLM API for the scoring and text-generation steps – the orchestration containers (API, worker, database) run fine on standard CPU-only VPS instances. A GPU is only necessary if you choose to run the language model itself locally rather than calling out to a provider.

    Can an AI recruitment agent fully replace a human recruiter?
    No. It’s best used to handle repetitive first-pass screening and administrative tasks like scheduling, freeing recruiters to focus on interviews and judgment calls that require context an LLM doesn’t have. Final hiring decisions should always involve human review.

    How do I keep candidate data private when using a hosted LLM API?
    Check the LLM provider’s data retention and training-use policies before sending resume content, and avoid sending unnecessary personal identifiers (full addresses, ID numbers) in prompts. If privacy requirements are strict, self-hosting the model itself, rather than only the orchestration layer, may be worth the added operational cost.

    What’s the difference between building this with Docker Compose versus a workflow tool like n8n?
    Docker Compose gives you full control over each service’s code and behavior, which suits teams comfortable maintaining custom application logic. A visual workflow tool trades some flexibility for faster iteration on the orchestration logic itself – see this n8n vs Make comparison for how these workflow platforms differ if you’re deciding between writing custom services or using a low-code orchestrator.

    Conclusion

    Self-hosting an AI recruitment agent with Docker gives you control over candidate data, scoring logic, and infrastructure costs that commercial ATS platforms typically don’t offer. Start with a minimal Docker Compose stack – API, worker, and database – get resume parsing and scoring working reliably, then layer in production concerns like secrets management, monitoring, and zero-downtime deployments as your hiring volume grows. The architecture scales from a side-project screening a handful of applications to a full pipeline handling continuous inbound hiring traffic, without locking you into a vendor’s pricing model. For deeper reference on container orchestration fundamentals underpinning this setup, see the official Docker documentation and, if you eventually outgrow a single-host Compose deployment, Kubernetes documentation for multi-node scaling patterns.

    Related articles:

  • AI Agent Consulting: A DevOps Buyer’s Guide

    AI Agent Consulting: A DevOps Guide to Evaluating, Deploying, and Securing AI Agents

    Disclosure: This post contains one or more links to providers we have a real, registered affiliate/referral relationship with. We may earn a commission at no extra cost to you if you sign up through them.

    Every team building on top of large language models eventually hits the same wall: the demo works, but production doesn’t. That’s the gap AI agent consulting is supposed to fill. But “AI agent consulting” has become a catch-all term covering everything from a two-week architecture review to a six-month managed build. If you’re a developer or sysadmin evaluating whether to hire outside help or build in-house, you need to know what you’re actually buying before you sign a contract.

    This guide breaks down what AI agent consulting actually involves, how to vet a firm technically, and how to self-host a basic agent stack with Docker so you have a real baseline to compare against any proposal.

    What AI Agent Consulting Actually Involves

    Strip away the marketing language and AI agent consulting engagements usually fall into three buckets: architecture and scoping, implementation, and ongoing operations. A consultant worth paying will be explicit about which of these three you’re buying, because each has a completely different risk profile and price tag.

    Scoping and Architecture Review

    This is the cheapest and often the most valuable engagement type. A good consultant will map your existing infrastructure — your container orchestration setup, your data sources, your auth boundaries — and tell you honestly whether an agent is even the right tool for the problem. Half of the value here is someone saying “you don’t need an autonomous agent, a scheduled cron job with a single LLM call will do this more reliably and for a tenth of the cost.”

    Red flag: if the first deliverable you’re offered is a full build-out rather than a scoping document, the firm is optimizing for billable hours, not your outcome.

    Build vs. Buy: When You Need a Consultant

    You generally need outside help when at least two of the following are true: your team has never deployed an LLM-backed system to production, you have compliance requirements (HIPAA, SOC 2, PCI) that touch the agent’s data flow, or you need the system live in under 8 weeks. If none of those apply, an experienced backend team can usually build a first version faster than onboarding a consultant.

    Self-Hosting AI Agents: A Docker-First Approach

    Before paying anyone, it’s worth standing up a minimal agent yourself so you understand the moving parts a consultant would otherwise abstract away. Below is a bare-bones containerized setup using an open-source agent framework.

    Containerizing an Agent Runtime

    Here’s a minimal Dockerfile for a Python-based agent process using LangChain as the orchestration layer:

    FROM python:3.12-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY agent.py .

ENV PYTHONUNBUFFERED=1

USER 1000:1000

CMD ["python", "agent.py"]

    And the accompanying docker-compose.yml that adds a vector store and a Redis instance for short-term agent memory:

    version: "3.9"
services:
  agent:
    build: .
    restart: unless-stopped
    env_file: .env
    depends_on:
      - redis
      - vectordb
    networks:
      - agent-net

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    volumes:
      - redis-data:/data
    networks:
      - agent-net

  vectordb:
    image: qdrant/qdrant:latest
    restart: unless-stopped
    volumes:
      - qdrant-data:/qdrant/storage
    networks:
      - agent-net

volumes:
  redis-data:
  qdrant-data:

networks:
  agent-net:
    driver: bridge

    Run it with:

    docker compose up -d --build
docker compose logs -f agent

    This gets you a working agent loop with persistent memory in under ten minutes. It is not production-grade — there’s no rate limiting, no secrets management, and no observability — but it’s enough to have an informed conversation with any consultant who claims their stack is uniquely complex.

    Vetting an AI Agent Consulting Firm

    Once you know what a baseline build looks like, you can ask sharper questions during vendor calls. Most AI agent consulting firms will happily talk about the model they use; fewer will talk about the boring infrastructure decisions that determine whether the thing stays up.

    Technical Due Diligence Checklist

    Use this list on every call before signing a statement of work:

  • Ask which orchestration framework they use and why (LangChain, LlamaIndex, a custom loop) — vague answers are a warning sign
  • Ask how they handle prompt injection and untrusted tool inputs, referencing something like the OWASP Top 10 for LLM Applications
  • Ask who owns the deployed infrastructure after the engagement ends — you, or them
  • Ask for a sample incident: what happens when the agent calls a tool with bad arguments in production
  • Ask how costs scale with token usage and request volume, not just a flat monthly retainer
  • Ask whether they’ll hand over Infrastructure-as-Code (Terraform, Compose files, Helm charts) or leave you with a black box

    • If a firm can’t answer the incident question with a specific example, they haven’t run one of these in production yet.

    Production Infrastructure for AI Agents

    Whether you hire a consultant or build in-house, the underlying infrastructure decisions are the same. This is the part of AI agent consulting engagements that most often gets glossed over in the sales pitch.

    Hosting and Scaling Considerations

    Agent workloads are bursty and I/O-bound — most of the wall-clock time is spent waiting on model API calls, not CPU. A single mid-tier VPS from a provider like DigitalOcean or Hetzner can comfortably run dozens of concurrent agent sessions if you’re not self-hosting the model itself. Reserve GPU instances only if you’re running your own inference — for API-based agents (OpenAI, Anthropic, etc.), a $20/month droplet is usually plenty to start.

    Monitoring and Observability

    Agents fail silently more often than traditional services — a bad tool call doesn’t always throw an exception, it just produces a wrong answer. Wire up structured logging around every tool invocation and every model call, and pipe it into an uptime and log monitoring service like BetterStack so you get paged when the agent’s tool-call error rate spikes rather than discovering it from a user complaint. Our self-hosted monitoring stack guide covers a similar setup for containerized services if you’d rather run your own.

    Locking Down the Agent’s Attack Surface

    Any agent with tool access is effectively a remote code execution surface if you’re not careful. At minimum:

  • Run the agent process as a non-root container user, as shown in the Dockerfile above
  • Put the agent behind a reverse proxy with rate limiting and bot protection, such as Cloudflare
  • Never give the agent direct database credentials — proxy through a read-only API with scoped permissions
  • Sanitize and allowlist any shell or file-system tools the agent can call

    • Our Linux server hardening checklist applies directly to the VPS hosting your agent, and it’s worth running through before you go live regardless of who built the system.

    What AI Agent Consulting Costs vs. Building In-House

    Pricing in this space varies wildly, but as a rough benchmark: a scoping-only engagement typically runs $5,000–$15,000 for a 2–4 week review. A full build with a small consulting team runs $30,000–$150,000+ depending on scope, and ongoing managed operations are usually billed as a monthly retainer on top of infrastructure and model API costs. Compare that against the Docker setup above, which an experienced backend engineer can extend into a real production system in 3-6 weeks of focused work. The consulting premium buys you speed and risk transfer — it doesn’t buy you infrastructure you couldn’t have built yourself with the checklist above.


    Recommended: Want to explore DigitalOcean yourself? DigitalOcean is a direct vendor link (not an affiliate/tracked link).

    FAQ

    Is AI agent consulting worth it for a small team?
    Usually only for the scoping phase. A short paid architecture review from an experienced consultant can save months of wrong turns, but a full build-out retainer is often overkill for teams under 10 engineers who already run Docker in production.

    What’s the difference between an AI agent and a chatbot?
    A chatbot responds to messages. An agent plans multi-step actions, calls external tools or APIs, and often maintains state across a task — which is exactly why it needs more careful infrastructure and security review than a simple chat interface.

    Can I self-host an AI agent without using a paid model API?
    Yes, using an open-weights model served through something like Ollama or vLLM, but you’ll need a GPU-backed host and you should expect materially lower quality on complex reasoning tasks compared to frontier hosted models.

    How do I know if an AI agent consulting firm is legitimate?
    Ask for a reference client, ask for a sample of their Infrastructure-as-Code, and ask specifically how they handle a failed tool call in production. Vague answers to any of these are a red flag.

    Do I need Kubernetes to run an AI agent in production?
    No. A single VPS running Docker Compose, as shown above, handles the vast majority of agent workloads. Kubernetes only becomes worthwhile once you have multiple agents, multiple teams, or genuine autoscaling requirements.

    What ongoing costs should I expect after the consulting engagement ends?
    Token/API usage, hosting, monitoring, and a maintenance budget for prompt and tool updates as the underlying model changes — budget at least 10-15% of the original build cost annually for upkeep.

    AI agent consulting can genuinely save time when you’re inexperienced with production LLM systems or facing a compliance-heavy deployment. But most of the value a consultant provides is one good architecture review plus infrastructure you could stand up yourself with a weekend and the Docker Compose file above. Vet the firm on specifics, not vibes, and you’ll come out ahead either way.

    Related articles:

  • AI Recruitment Agents: Self-Hosted Deployment Guide

    AI Recruitment Agents: Self-Hosted Deployment Guide

    Disclosure: This post contains one or more links to providers we have a real, registered affiliate/referral relationship with. We may earn a commission at no extra cost to you if you sign up through them.

    AI recruitment agents are automated systems that screen resumes, schedule interviews, and communicate with candidates using language models and workflow orchestration. This guide walks through deploying AI recruitment agents on your own infrastructure, covering architecture, containerization, self-hosted orchestration, and security considerations for teams that want full control over candidate data instead of relying on a third-party SaaS platform.

    Self-hosting AI recruitment agents gives HR and engineering teams direct ownership of applicant data, predictable infrastructure costs, and the flexibility to integrate with internal applicant tracking systems (ATS). This article assumes basic familiarity with Docker and Linux server administration.

    Why Self-Host AI Recruitment Agents

    Most commercial recruitment automation tools run in a shared multi-tenant cloud, which means candidate resumes, interview transcripts, and personal data pass through a vendor’s infrastructure. For companies in regulated industries, or those simply cautious about data residency, self-hosting AI recruitment agents removes that dependency.

    A self-hosted deployment also lets you swap the underlying language model, adjust scoring logic, and connect directly to internal systems (Slack, an ATS, a calendar server) without waiting on a vendor’s integration roadmap. The tradeoff is operational responsibility: you own uptime, patching, and scaling.

    Core Components of an AI Recruitment Agent Stack

    A typical self-hosted AI recruitment agent system is composed of a handful of independent services:

  • A workflow orchestrator that sequences steps (resume parsing, scoring, scheduling, notification)
  • A language model endpoint, either self-hosted or accessed via API
  • A resume/document parser
  • A database for candidate records and pipeline state
  • A calendar/email integration layer for interview scheduling
  • A web UI or chat interface for recruiters to review agent output

    • Keeping these as separate containers rather than one monolithic script makes the system easier to debug, scale, and replace piece by piece as your needs change.

    Data Flow Through the Agent Pipeline

    When a candidate submits an application, the pipeline typically follows this sequence: ingestion (resume upload or email parsing), extraction (turning a PDF or DOCX into structured text), evaluation (the AI recruitment agent scores the candidate against job requirements), and action (scheduling an interview, sending a rejection, or flagging for human review). Each stage should be logged independently so a human recruiter can audit any decision the agent made.

    Choosing an Orchestration Layer for AI Recruitment Agents

    You don’t need to write custom orchestration code from scratch. Workflow automation tools designed for connecting APIs and running conditional logic are a natural fit for AI recruitment agents, since most of the “agent” behavior is really a sequence of API calls with decision points in between.

    If you’re already using a self-hosted automation platform, you can build the recruitment pipeline as a series of workflows: one triggered by new resume uploads, one for scoring and shortlisting, and one for scheduling. If you’re evaluating tools, our guide on how to build AI agents with n8n covers the fundamentals of chaining LLM calls with conditional branches, which applies directly to recruitment scoring logic. For a broader comparison of orchestration options, see n8n vs Make.

    Self-Hosting the Orchestrator

    Running your orchestrator on your own VPS keeps workflow logic, credentials, and candidate data on infrastructure you control. If you’re setting this up for the first time, our n8n self-hosted installation guide walks through the Docker setup, and the n8n template guide is useful once you’re ready to adapt pre-built workflows for resume scoring or interview scheduling. Budget-conscious teams comparing hosted vs. self-hosted costs may also want to review n8n cloud pricing before committing to either path.

    Containerizing the AI Recruitment Agent Stack

    Docker Compose is a practical way to define and run the multiple services an AI recruitment agent pipeline needs: the orchestrator, a vector or relational database for candidate records, and any parsing microservices.

    A minimal docker-compose.yml for a self-hosted AI recruitment agent stack might look like this:

    version: "3.8"
services:
  orchestrator:
    image: n8nio/n8n:latest
    restart: unless-stopped
    ports:
      - "5678:5678"
    environment:
      - N8N_HOST=recruit.example.com
      - N8N_PROTOCOL=https
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=db
    depends_on:
      - db
    volumes:
      - n8n_data:/home/node/.n8n

  db:
    image: postgres:16
    restart: unless-stopped
    environment:
      - POSTGRES_USER=recruit
      - POSTGRES_PASSWORD_FILE=/run/secrets/db_password
      - POSTGRES_DB=recruitment
    secrets:
      - db_password
    volumes:
      - pg_data:/var/lib/postgresql/data

secrets:
  db_password:
    file: ./secrets/db_password.txt

volumes:
  n8n_data:
  pg_data:

    This setup keeps the database credential out of plain environment variables using Docker secrets. For a deeper walkthrough of secrets handling in this pattern, see our Docker Compose secrets guide. If you need more detail on setting up Postgres specifically as the candidate-record database, the Postgres Docker Compose guide covers volumes, backups, and connection tuning.

    Managing Environment Configuration

    AI recruitment agents typically need several environment-specific values: API keys for the language model provider, SMTP credentials for candidate emails, and calendar integration tokens. Keep these in a .env file excluded from version control, and reference our Docker Compose env guide for patterns on variable precedence and per-environment overrides (staging vs. production).

    Rebuilding and Iterating on Agent Logic

    As you refine scoring prompts or add new pipeline stages, you’ll frequently rebuild the orchestrator or parsing service images. The Docker Compose rebuild guide covers when docker compose up --build is necessary versus when a simple restart suffices, which matters when you’re iterating quickly on agent behavior during initial rollout.

    Integrating the Language Model

    Most AI recruitment agents rely on a large language model to read resumes, compare them against a job description, and generate a fit score or summary. You have two broad options: call a hosted LLM API, or self-host an open-weight model.

    Self-hosting a model gives you full control over data handling but requires GPU resources and ongoing maintenance. Calling a hosted API is simpler operationally but means resume text leaves your infrastructure for inference. Many teams start with a hosted API behind their self-hosted orchestrator, then migrate to a self-hosted model once volume and privacy requirements justify the added complexity.

    Regardless of which approach you choose, log every prompt and response pair associated with a candidate decision. This is essential both for debugging inconsistent scoring and for being able to explain, after the fact, why an AI recruitment agent ranked one candidate above another.

    Prompt Design for Fair, Consistent Screening

    The prompt you send to the model has an outsized effect on the consistency of your AI recruitment agent’s output. A few practical guidelines:

  • Provide the job description and the candidate’s resume text as separate, clearly labeled inputs
  • Ask for structured output (JSON with specific fields) rather than free-form prose, so downstream steps can parse it reliably
  • Avoid asking the model to infer protected characteristics (age, gender, ethnicity) even indirectly
  • Include a confidence or “needs human review” flag in the output so borderline cases are routed to a recruiter rather than auto-rejected

    • Storing and Caching Candidate Data

    Candidate records, resumes, and interview notes should live in a persistent, backed-up datastore rather than ephemeral container storage. A relational database like Postgres works well for structured pipeline state (candidate status, scores, timestamps).

    If your AI recruitment agent pipeline needs a fast cache layer for deduplicating resume submissions or rate-limiting API calls to the language model, Redis is a common addition. Our Redis Docker Compose guide shows how to add a Redis service alongside your existing stack with appropriate persistence settings.

    Choosing Between a Dockerfile and Compose for Custom Services

    If you’re building a custom resume-parsing microservice rather than using an off-the-shelf image, you’ll need to decide how much of the setup belongs in a Dockerfile versus your Compose file. Our Dockerfile vs Docker Compose comparison explains the division of responsibility: the Dockerfile defines how a single service is built, while Compose defines how multiple services run together.

    Deploying to a VPS

    Once your AI recruitment agent stack is containerized, deploying it to a VPS is largely a matter of provisioning a server, installing Docker, and running docker compose up -d. Because recruitment data is sensitive, choose a provider and region that satisfies your organization’s data residency requirements, and enable disk encryption where the provider supports it.

    For teams that want full root access and predictable pricing without the overhead of a managed platform, an unmanaged VPS is a reasonable fit for this workload — see our unmanaged VPS hosting guide for the tradeoffs versus managed hosting. Providers like DigitalOcean, Hetzner, and Vultr all offer VPS tiers suitable for running an AI recruitment agent stack of this size; pick based on region availability and your existing infrastructure relationships.

    Sizing the Server

    An AI recruitment agent stack that calls an external LLM API doesn’t need GPU resources — a standard 2-4 vCPU, 4-8GB RAM VPS is typically sufficient for the orchestrator, database, and parsing services at moderate application volume. If you later self-host the language model itself, you’ll need to size separately for GPU inference, which is a materially different hosting decision.

    Monitoring, Debugging, and Logging

    Once live, an AI recruitment agent pipeline needs the same operational discipline as any other production service. Container logs are your first line of debugging when a candidate’s application gets stuck mid-pipeline or a scoring step fails silently.

    # Tail logs for the orchestrator service
docker compose logs -f orchestrator

# Check recent logs for the database container only
docker compose logs --tail=100 db

# Stop the stack cleanly during maintenance
docker compose down

    For a deeper reference on filtering, following, and interpreting container logs across a multi-service stack like this one, see our Docker Compose logs guide, and for safely stopping and restarting the stack during upgrades, the Docker Compose down guide covers the difference between down and stop and when volumes get removed.

    Beyond container-level logs, track pipeline-level metrics: how many candidates enter each stage, average time-to-decision, and how often the agent flags a case for human review versus auto-deciding. These metrics tell you whether your AI recruitment agent is actually reducing recruiter workload or just adding a new step to babysit.

    Auditability and Explainability

    Because hiring decisions carry legal and ethical weight, every action your AI recruitment agent takes should be traceable back to the input that produced it. Store the exact resume text, job description, prompt, and model response used for each scoring decision. This lets a human reviewer reconstruct why a candidate was ranked, rejected, or advanced, and is essential if a decision is ever challenged or audited.

    Security and Compliance Considerations

    Candidate data is personal data, and in many jurisdictions that means specific legal obligations around storage, retention, and consent. A self-hosted deployment puts these obligations squarely on your team rather than a vendor, so plan for them explicitly:

  • Encrypt data at rest for the database volume and encrypt traffic in transit with TLS
  • Define a retention policy and actually delete candidate data once it expires, rather than accumulating it indefinitely
  • Restrict access to the orchestrator UI and database to authorized recruiters and admins only
  • Keep an audit log of who accessed or modified a candidate record and when
  • Review the language model provider’s data handling terms if you’re calling an external API, since resume content will pass through their infrastructure

    • Refer to official cloud security guidance such as Docker’s security documentation when hardening your container runtime, and consult the OWASP resources relevant to your application layer if you’re building custom parsing or scoring microservices rather than relying entirely on off-the-shelf components.


    Recommended: Want to explore DigitalOcean yourself? DigitalOcean is a direct vendor link (not an affiliate/tracked link).

    FAQ

    Do AI recruitment agents replace human recruiters?
    No. A well-designed AI recruitment agent handles repetitive screening and scheduling tasks, but final hiring decisions should remain with a human recruiter or hiring manager, especially for borderline or flagged candidates.

    Is self-hosting AI recruitment agents more expensive than using a SaaS platform?
    It depends on volume and existing infrastructure. Self-hosting shifts cost from a per-seat SaaS subscription to server and (optionally) LLM API usage costs, which can be cheaper at scale but requires more engineering time to maintain.

    What language model should I use for an AI recruitment agent?
    There isn’t a single correct choice — it depends on your budget, data privacy requirements, and whether you need self-hosted inference. Many teams start with a hosted API and re-evaluate once volume or privacy needs justify running an open-weight model themselves.

    How do I keep an AI recruitment agent from introducing bias into hiring?
    Design prompts that avoid inferring protected characteristics, log every decision with its inputs for auditability, route low-confidence scores to human review, and periodically review a sample of the agent’s decisions against human judgment.

    Conclusion

    Self-hosting AI recruitment agents is a practical option for teams that want direct control over candidate data, infrastructure cost, and integration flexibility. The core building blocks — a workflow orchestrator, a language model integration, structured candidate storage, and solid logging — can all run comfortably in a Docker Compose stack on a modestly sized VPS. The operational tradeoff is that your team now owns uptime, security, and compliance directly, so plan monitoring, backups, and data retention policies from day one rather than retrofitting them after your AI recruitment agent pipeline is already handling live candidates.

    Related articles:

  • Customer Service AI Agents: Self-Hosted Deployment Guide

    Customer Service AI Agents: A DevOps Guide to Self-Hosted Deployment

    Disclosure: This post contains one or more links to providers we have a real, registered affiliate/referral relationship with. We may earn a commission at no extra cost to you if you sign up through them.

    Every SaaS vendor wants to sell you a hosted customer service AI agent subscription billed per seat, per conversation, or per token. If you run infrastructure for a living, that pricing model probably makes you flinch. This guide covers what it actually takes to run customer service AI agents on your own servers — the container stack, the networking, the monitoring, and the security tradeoffs nobody puts in the marketing copy.

    This is written for developers and sysadmins who already run Docker in production and want a customer-facing AI agent that doesn’t leak conversation data to a third party by default.

    Why Self-Host Customer Service AI Agents

    Hosted customer service AI agent platforms are fast to set up, but you trade away control over three things: data residency, latency, and cost predictability. If your support volume scales past a few thousand conversations a month, the per-conversation pricing on most hosted platforms starts to hurt.

    The Case for Self-Hosting

    Self-hosting isn’t about avoiding vendors entirely — you’ll still likely call an LLM API unless you’re running a local model. The point is owning the orchestration layer:

  • Full control over conversation logs and PII retention policies
  • No per-seat or per-resolution billing surprises
  • Ability to swap the underlying LLM provider without re-platforming
  • Custom routing logic (escalate to human, trigger a refund workflow, pull order status from your own database)
  • Easier compliance with GDPR/CCPA when logs never leave infrastructure you control

    • The tradeoff is operational overhead: you own uptime, scaling, and patching. If your team already runs Docker and Kubernetes for other services, this is a manageable addition, not a new discipline.

    Architecture Overview

    A production-grade self-hosted customer service AI agent stack typically has five components:

    1. A frontend widget or chat API endpoint
    2. An orchestration service (handles conversation state, tool calls, retrieval)
    3. A vector database for knowledge-base retrieval (RAG)
    4. A connection to an LLM — either a hosted API or a self-hosted model server
    5. A logging/observability layer for auditing and QA

    Each of these runs as its own container, which makes the whole thing reproducible and easy to move between cloud providers.

    Building the Stack with Docker

    Here’s a minimal docker-compose.yml that stands up an orchestration service, a Postgres-backed vector store using pgvector, and Redis for session state:

    version: "3.9"
services:
  agent-orchestrator:
    build: ./orchestrator
    ports:
      - "8080:8080"
    environment:
      - LLM_API_KEY=${LLM_API_KEY}
      - VECTOR_DB_URL=postgresql://agent:agent@vector-db:5432/agentdb
      - REDIS_URL=redis://session-store:6379
    depends_on:
      - vector-db
      - session-store
    restart: unless-stopped

  vector-db:
    image: ankane/pgvector:latest
    environment:
      - POSTGRES_USER=agent
      - POSTGRES_PASSWORD=agent
      - POSTGRES_DB=agentdb
    volumes:
      - vector_data:/var/lib/postgresql/data

  session-store:
    image: redis:7-alpine
    volumes:
      - redis_data:/data

volumes:
  vector_data:
  redis_data:

    The orchestrator is your own service — usually a lightweight Python app using something like LangChain or a hand-rolled loop that calls the LLM API, checks the vector store for relevant docs, and decides whether to answer directly or hand off to a human. A minimal Python handler looks like this:

    from fastapi import FastAPI, Request
import httpx

app = FastAPI()

@app.post("/chat")
async def chat(request: Request):
    body = await request.json()
    message = body["message"]
    session_id = body["session_id"]

    context = await retrieve_context(message)
    response = await call_llm(message, context)

    if response.confidence < 0.6:
        return {"action": "escalate_to_human", "session_id": session_id}

    return {"action": "reply", "text": response.text}

    Bring this up locally with:

    docker compose up -d
docker compose logs -f agent-orchestrator

    If you’re new to multi-container setups, our Docker Compose guide for beginners covers the fundamentals of service dependencies and volumes used above.

    Deploying to Production

    Choosing Infrastructure

    Customer service AI agents are latency-sensitive — a slow response feels broken to a user mid-conversation. Pick infrastructure based on where your customers actually are, not where it’s cheapest to spin up a box.

    For most small-to-mid teams, a couple of solid options:

  • DigitalOcean droplets with managed Kubernetes if you want a simple, well-documented path to container orchestration
  • Hetzner dedicated or cloud servers if you need raw compute per dollar, especially for running your own vector database or a self-hosted model

    • Both work well behind a reverse proxy like Traefik or Nginx, and both support the Docker Compose stack above with minimal changes. If you’re running the orchestrator plus a vector database plus Redis, a 4 vCPU / 8GB instance is a reasonable starting point — scale the vector database vertically first since it’s usually the bottleneck under concurrent load.

    Networking and TLS

    Don’t expose the chat API without TLS. A basic Nginx reverse proxy config in front of the orchestrator:

    server {
    listen 443 ssl;
    server_name support.yourdomain.com;

    ssl_certificate /etc/letsencrypt/live/support.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/support.yourdomain.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $host;
    }
}

    Pair this with Cloudflare in front of your origin for DDoS protection and edge caching of static widget assets — customer service traffic tends to spike unpredictably (a bad product release, an outage, a viral complaint), and edge protection absorbs that better than scaling your origin reactively.

    Monitoring and Logging

    A customer service AI agent that silently fails is worse than one that’s slow — customers get wrong answers with no visible error. You need application-level monitoring, not just container uptime checks.

    At minimum, track:

  • Response latency per conversation turn
  • Escalation rate (how often the agent hands off to a human)
  • LLM API error rate and rate-limit hits
  • Vector store query latency

    • BetterStack works well here since it combines uptime monitoring with log aggregation, so you can alert on both “the container is down” and “escalation rate just spiked 300% in the last hour,” which is often the earlier warning sign of a real problem. Ship logs from the orchestrator container using a simple driver:

    docker run -d 
  --log-driver=syslog 
  --log-opt syslog-address=udp://logs.betterstack.com:514 
  --name agent-orchestrator 
  your-org/agent-orchestrator:latest

    Alerting on Escalation Spikes

    Set an alert threshold on escalation rate specifically. A sudden jump usually means either the knowledge base is stale (a product changed and the agent doesn’t know) or the LLM provider is degraded. Catching this in minutes instead of finding out from angry tickets is the whole point of running your own observability stack.

    Security Considerations

    Customer service conversations often contain PII — order numbers, emails, sometimes payment details users paste in by mistake. Treat the conversation logs like any other sensitive customer data store.

  • Encrypt data at rest for both the vector database and Redis session store
  • Redact or hash PII before it’s sent to a third-party LLM API if your compliance posture requires it
  • Rotate API keys for the LLM provider and store them in a secrets manager, not in docker-compose.yml directly
  • Set conversation log retention limits and actually enforce deletion — don’t just document the policy

    • If you’re self-hosting the LLM itself instead of calling an external API, review our Linux server hardening checklist before exposing any inference endpoint publicly — model servers are a newer attack surface and often shipped with permissive defaults.

    Recommended: Ready to put this into practice? DigitalOcean is a tool we use for exactly this, and we have a real, disclosed affiliate relationship with them.

    FAQ

    Do I need a GPU to self-host customer service AI agents?
    Not if you’re calling a hosted LLM API (OpenAI, Anthropic, etc.) for the actual language model and only self-hosting the orchestration layer. You only need GPU infrastructure if you’re also self-hosting the underlying model itself, which adds significant operational complexity.

    How is this different from just using a chatbot builder?
    Most no-code chatbot builders don’t give you control over the retrieval pipeline, escalation logic, or where conversation data is stored. Self-hosting the orchestration layer means you own that logic and can integrate directly with your own database, ticketing system, or CRM.

    What’s a realistic team size to maintain this?
    One DevOps engineer can maintain this stack alongside other responsibilities once it’s deployed, assuming you already run Docker in production. Initial setup and integration with your knowledge base is the bulk of the effort.

    Can this replace human support entirely?
    No, and it shouldn’t try to. The escalation path to a human agent is a core part of the architecture, not an afterthought. Confidence-based handoff keeps the agent from confidently giving wrong answers.

    How do I keep the knowledge base current?
    Automate re-indexing of your vector database whenever your docs, help center, or product changelog updates. A stale knowledge base is the most common cause of bad AI agent responses in production.

    Is it cheaper than a hosted platform long-term?
    Usually yes past a certain volume threshold, since you’re paying infrastructure costs plus LLM API usage instead of a per-resolution markup. Below a few thousand conversations a month, a hosted platform may still be cheaper once you account for engineering time.

    Self-hosting customer service AI agents isn’t the right call for every team, but if you already run containerized infrastructure, it gives you control over cost, data, and behavior that hosted platforms can’t match. Start small — one orchestrator container, one knowledge base, a clear escalation path — and scale the stack as conversation volume grows.

    Related articles: