The Absurd Premise

Here are the numbers. Three Proxmox bare-metal Dell Optiplex 3070 micro nodes. Nine virtual machines running MicroK8s. Twenty-five Helm charts pulling from 33 upstream chart dependencies. Eighteen ArgoCD Applications orchestrating continuous deployment. Nearly four thousand git commits spanning several years of incremental improvement. And one person keeping it all running.

The service list reads like a mid-size startup's infrastructure: OpenEBS for distributed block storage across nodes, dual NGINX ingress controllers separating public and internal traffic, External Secrets Operator wired to AWS Secrets Manager, Velero for cluster backup, a full observability stack (Prometheus, Grafana, Loki, Tempo, OpenTelemetry Collector and Operator, Thanos for long-term metric retention), Harbor as a private container registry, Nextcloud for file sharing and knowledge management, Argo Workflows for batch processing, Kepler for energy monitoring, Goldpinger for network health, a PostgreSQL operator managing multiple database clusters, and a handful of application workloads on top.

This is not a sensible setup for a single operator. The question was never whether one person could build all of this--homelabbers build ambitious things all the time. The question is whether one person can keep it running without it becoming a second full-time job. Before AI tooling entered the picture, the honest answer was: barely, and with a growing maintenance backlog. Now the answer is: yes, sustainably, with caveats worth being honest about.

The Dependency Treadmill

The foundation of this setup's sustainability is Renovate, a dependency update bot that watches every Chart.yaml and container image reference in the repository. When an upstream project releases a new Helm chart version or container image tag, Renovate opens a pull request automatically. On an average week, that means somewhere between three and ten PRs.

Staying current matters more than most people realize. Security patches are the obvious reason, but the subtler one is migration path preservation. Falling three minor versions behind on a Helm chart is annoying. Falling three major versions behind can mean days of manual migration work, breaking schema changes, and deprecated APIs. Renovate keeps the distance between your running version and the latest version as small as possible, which keeps each individual upgrade trivial.

But there is a failure mode baked into this automation. The happy path looks like this: Renovate opens a PR, CI runs helm lint and helm template to validate syntax, the PR is reviewed and merged, and ArgoCD picks up the new commit and syncs the changes to the cluster. The problem is that linting catches syntax errors, not behavioral changes. A chart can template perfectly and still break your monitoring, change a default that matters, or introduce an incompatibility that only manifests at runtime.

This is exactly what happened in early February 2026. A Renovate PR bumped the OpenTelemetry operator chart from 0.102.0 to 0.105.0. It linted clean. It templated clean. It merged, ArgoCD synced, and within minutes a TargetDown alert fired--the operator's metrics endpoint had gone dark.

The guardrails in the repository--version pins on critical services, ignorePaths for components like the mediaserver stack that are too fragile for automated updates--are scars from previous incidents like this one. They help, but they cannot catch everything. Renovate is a force multiplier, but it requires monitoring to back it up. Automation without observability is just faster failure.

Anatomy of an Upstream Bug

This incident deserves a close look because it illustrates a failure mode that is both common and genuinely difficult to catch, with or without AI tooling.

The Renovate PR upgraded the OpenTelemetry operator Helm chart from version 0.102.0 to 0.105.0, which bumped the operator binary from v0.141.0 to v0.144.0. The chart templated cleanly. No schema changes, no removed fields, no deprecation warnings. ArgoCD synced the new manifests and rolled out the updated operator pod.

The symptom was immediate: the Prometheus up metric for the observability-opentelemetry-operator job dropped to 0, and within fifteen minutes the TargetDown alert fired. Prometheus could no longer scrape the operator's metrics endpoint.

The root cause was a transitive default change buried two levels deep. The operator binary itself--not the Helm chart, but the Go binary packaged inside the container image--introduced a --metrics-secure flag in v0.142.0 that defaults to true. This caused the manager process to serve its metrics endpoint over HTTPS using self-signed certificates, while the Helm chart's ServiceMonitor still told Prometheus to scrape over plain HTTP. Every thirty seconds, Prometheus attempted an HTTP GET, the operator responded with a TLS handshake, and the scrape failed.

What makes this particularly insidious is the gap between the component that changed and the component that configures it. The Helm chart's values.yaml schema had no field for --metrics-secure. The chart's own changelog made no mention of the change. You had to read the operator binary's release notes--a different repository, a different release cadence--to discover that a default had flipped. The upstream maintainer later confirmed in issue #2063 that "secure serving is enabled by default, despite the description in the changelog," and a fix was already in progress in PR #2004.

This is where open source shows its strength--and where it demands responsible stewardship. The upstream issue existed because the project is open and transparent; anyone can read the discussion, confirm the root cause, and verify the fix. But that openness is not free. Maintainers of projects like the OpenTelemetry Helm charts are fielding issues from thousands of downstream consumers, most of whom are running configurations the maintainers have never seen. The least a downstream operator can do is file well-researched issues: include the exact versions, the specific behavior change, the logs that prove the failure mechanism, and ideally a link to the commit that introduced it. AI tooling makes this kind of thorough issue reporting much easier--the same investigation that finds your fix also produces the evidence an upstream maintainer needs to confirm and prioritize the bug. Dumping a vague "it broke after upgrading" on an open-source issue tracker is not contributing to the ecosystem; it is adding to the maintainer's workload. The power of open source requires that its users invest in the quality of their participation.

The fix itself was two lines: pass --metrics-secure=false via the chart's manager.extraArgs field. The investigation to arrive at those two lines was the hard part.

The Investigation, Step by Step

Here is how the debugging actually unfolded, using Claude Code with MCP (Model Context Protocol) integrations to Grafana, Kubernetes, and Nextcloud. MCP is a protocol that gives AI tools structured access to external systems--instead of copying and pasting from browser tabs, the AI can query Prometheus, read pod logs, and inspect Kubernetes resources directly.

The first step was alert discovery. Through the Grafana MCP integration, Claude Code queried the ALERTS{alertstate="firing"} metric to get a structured view of every firing alert in the cluster. This returned not just the OTel TargetDown alert but also a TempoHighLiveTraces alert and several known-benign alerts (the Watchdog dead man's switch, CPUThrottling on OpenEBS io-engine pods, and openipmi.service failures on Proxmox nodes). Having the full alert landscape immediately distinguished the new problem from background noise.

Next, metric correlation. A Prometheus query for up{job="observability-opentelemetry-operator"} over the previous 24 hours pinpointed the exact moment the metric dropped to zero, which aligned with the Renovate PR merge and subsequent ArgoCD sync. This established causation, not just correlation.

Then, log inspection. Through the Kubernetes MCP integration, Claude Code pulled logs from the operator manager pod and found it repeating every thirty seconds: http: TLS handshake error from <prometheus-ip>: client sent an HTTP request to an HTTPS server. This single log line identified the exact failure mechanism--a protocol mismatch between server and client.

Spec inspection followed. Examining the pod's container spec via Kubernetes MCP revealed the command-line arguments being passed to the operator binary, confirming that --metrics-secure was not explicitly set, meaning the new default of true was in effect. Comparing this with the ServiceMonitor resource confirmed it was configured for plain HTTP scraping.

With the failure mechanism understood, root cause analysis moved to the local filesystem. The upstream Helm chart repository, cloned locally, was searched for references to metrics-secure. The operator's release notes confirmed the flag was introduced in v0.142.0 with a default of true. A GitHub CLI search surfaced the upstream issue and fix PR, confirming this was a known problem with a pending resolution.

The fix was then implemented: two lines added to the observability chart's values.yaml. During the same session, the investigation of firing alerts had revealed that the TempoHighLiveTraces threshold was stale--set at 500 when the actual steady-state baseline had risen to approximately 500, causing the alert to fire continuously. This was corrected by raising the threshold to 800 to provide meaningful headroom. Both changes were validated with helm template and pre-commit run, committed, and pushed as a single PR.

After ArgoCD synced the merged PR, verification via Prometheus MCP confirmed the up metric had returned to 1 and both alerts had cleared. The full investigation was then documented in Nextcloud as a searchable note with the scope, root cause chain, metrics used, and follow-up actions (remove the workaround once the upstream fix is released).

Total wall-clock time: approximately one hour. Estimated time without AI tooling: two to four hours, primarily because the investigation would have involved switching between a browser with Grafana dashboards, a terminal with kubectl, the GitHub web UI for upstream issues, and an editor for the fix--each context switch carrying a cognitive tax. The key insight is that the savings do not come from the AI being "smarter" than the operator. They come from the AI holding context across all of these systems simultaneously, eliminating the serial context-switching that dominates incident response for a single operator.

The Prerequisites That Make This Work

It would be easy to read the previous section and conclude that AI tooling is a silver bullet for infrastructure operations. It is not. The tooling is powerful, but it is powerful in the way a force multiplier is powerful: it multiplies whatever you already have, including zero.

Observability is not optional. Claude Code can query Prometheus only if you have Prometheus. It can correlate metrics with logs only if you are collecting both. The observability stack in this cluster--Prometheus, Grafana, Loki, Tempo, OpenTelemetry Collector, Thanos--is configured across 2,352 lines of Helm values representing months of iterative tuning. Alert rules, recording rules, ServiceMonitor configurations, retention policies, and resource limits have all been hand-tuned to balance signal quality against resource cost. If none of that existed, the AI would have nothing to query and the investigation would not have been possible.

GitOps makes AI-assisted operations safe. Every change Claude Code proposes goes through a pull request. It gets linted by pre-commit hooks, reviewed by a human, and deployed by ArgoCD. The AI cannot kubectl apply directly to the cluster. This is not a limitation--it is the most important safety property of the entire workflow. When an AI suggests a fix, you see the exact diff, you review it in the context of version-controlled history, and you can revert it with a single git operation. Without GitOps, AI-assisted operations would be terrifying rather than empowering.

MCP integrations are the bridge between chat and operations. Without MCP servers for Grafana, Kubernetes, and Nextcloud, Claude Code is a conversational interface that can read and edit local files. Useful, but not transformative for operations work. The MCP integrations are what allow it to query live metrics, inspect running pods, and document findings in a persistent knowledge base. Setting these up is not trivial--the project's integration instructions alone span hundreds of lines of structured guidance covering query generation workflows, discovery patterns, and context-pollution prevention strategies.

Institutional knowledge compounds. The Nextcloud knowledge base now contains 61 investigation notes spanning over a year of operations. Each note includes the scope, symptoms, root cause, resolution, and the exact metrics and queries used. When a new incident occurs, semantic search surfaces past investigations with similar patterns. The OTel investigation drew on the existing understanding that CPUThrottling alerts on OpenEBS io-engine pods are benign--context documented in a previous investigation. Without that documented knowledge, the alert triage step would have taken longer and risked a false lead.

The punchline: AI amplifies existing operational maturity. No monitoring plus AI equals faster hallucinations, not faster resolutions.

Broader Patterns from AI-Assisted Operations

Beyond the OTel incident, several patterns have emerged from months of using AI tooling for cluster operations.

Resource right-sizing becomes data-driven. One of the most tedious tasks in Kubernetes operations is setting appropriate CPU and memory requests and limits. The AI can query actual resource utilization from Prometheus, compare it against the values configured in Helm charts, and suggest adjustments with specific numbers. This turns a task that requires bouncing between Grafana dashboards and YAML files into a single conversation.

Multi-system investigations are where the value concentrates. The most impactful sessions are the ones that cross-cut multiple services and data sources. An alert in one namespace leads to a log entry in another, which correlates with a metric from a third. These investigations are where human context-switching costs are highest and where holding everything in a single conversation context pays off the most.

Incidental discoveries are a real benefit. The Tempo alert threshold fix was not the goal of the investigation--it was discovered incidentally while triaging the full list of firing alerts. A human operator deep in a focused debugging session might have noted the stale alert and filed it away for later. Having an AI that can address both issues in the same session, with the same context, reduces the backlog of "I'll fix that later" items that accumulate in any system.

Iteration is fast but not free. Not every fix lands on the first attempt. Under-documented upstream components, especially those with transitive dependencies or implicit defaults, sometimes require multiple rounds of investigation. The AI accelerates each round, but it does not eliminate them. Honesty about this matters: the tooling is not magic, and setting expectations accordingly prevents disillusionment.

What the Numbers Say (and Don't Say)

The claims above are qualitative. Here is what the git history and investigation records actually show.

The throughput story. Over the past twelve months, Renovate has merged between 80 and 140 pull requests per month--roughly a thousand upstream dependency updates per year. Of those, exactly three resulted in documented incidents requiring investigation: a Loki ruler config regression in December 2025, the OpenEBS etcd subchart label change in February 2026, and the OTel operator metrics flag described above. That is a 99.7% success rate for automated updates. But the 0.3% that fail are disproportionately expensive--each one demands cross-system investigation, upstream research, and careful remediation. The automation's value is not that it eliminates incidents; it is that it compresses the surface area where incidents can hide.

The adoption curve. Claude Code entered the workflow in late October 2025. Usage peaked immediately: 79 co-authored commits in November 2025, covering a burst of proactive work--resource right-sizing across the cluster, Thanos setup for long-term metric retention, and alert rule tuning. By January 2026, that had settled to roughly ten co-authored commits per month, each targeting a specific incident or operational task. The pattern is not "AI does everything now." It is "AI enabled a one-time paydown of accumulated operational debt, and now assists with the incidents that remain."

The honest MTTR picture. It would be satisfying to report a clean before-and-after comparison of mean time to resolution. The data does not support one. Structured investigation notes did not exist before AI tooling was introduced, so there is no documented baseline to compare against. What exists is the resolution timeline for the three Renovate-triggered incidents: the Loki regression was caught and fixed same-day, the OTel incident was investigated in roughly an hour, and the OpenEBS upgrade took two days to detect and four hours to resolve once investigated--requiring significant manual intervention that AI could not shortcut. Three data points do not make a trend. MTTR depends on the nature of the failure, not just the tooling available to investigate it.

The documentation dividend. The most measurable change is not speed--it is the 61 investigation notes that now exist in the knowledge base. Each preserves the exact queries, timestamps, and reasoning chain from an investigation session. This institutional memory is what makes future MTTR improvements possible: when the OTel TargetDown alert fir

ed, the investigation started by triaging it against known-benign alerts like OpenEBS CPUThrottling--context documented months earlier. The next time an upstream dependency breaks something, the investigation starts with context instead of from scratch. The compounding value of this documentation is harder to quantify than a response time metric, but it is arguably more important.

The New Economics of Small Teams

Platform engineering used to have a minimum viable team size. Below a certain threshold of services and complexity, the operational overhead was manageable by one person. Above it, you needed a team--not because the work was intellectually beyond one person, but because the context-switching and interrupt-driven nature of operations work exceeded one person's bandwidth.

AI tooling lowers that threshold. It does not eliminate it, but it meaningfully shifts where the line falls. A cluster with 25 Helm charts and 33 upstream dependencies generates a steady stream of updates, alerts, and subtle breakages--roughly a thousand Renovate-driven updates per year, with only a handful requiring human intervention. The sustainable operations loop now looks like this: Renovate automates dependency updates, ArgoCD automates deployment, the observability stack automates detection, and Claude Code with MCP integrations accelerates investigation and resolution. Each link in the chain reduces the human time required per incident.

What changed is not any single capability but the closing of a loop. Before MCP integrations, the AI could help you write Helm values but could not check whether the change actually worked. Before the observability stack, there was nothing to check against. Before GitOps, there was no safe way to let an AI propose changes. Before Renovate, staying current was itself a full-time job. Each piece existed independently; the economic shift comes from connecting them into a cycle where the output of each stage feeds the next.

The key word is "sustainable," not "effortless." You still need to build the observability stack. You still need to review every pull request. You still need to understand your systems deeply enough to evaluate the AI's suggestions critically. The operational maturity cannot be outsourced. But for a single operator who has already invested in that maturity, AI tooling is the difference between a homelab that slowly drowns in maintenance debt and one that stays current, well-monitored, and--against all reasonable expectations--actually production-grade.

The real unlock is not speed. It is continuity. Context is preserved across investigations, operational patterns are reinforced through documentation, and mean time to resolution stays bounded even as the system grows. For a team of one, that is the margin between sustainable and unsustainable.

The upstream issue referenced in this post is tracked at open-telemetry/opentelemetry-helm-charts#2063, with a fix in PR #2004.

This blog post was written with the help of AI, and reviewed by a Human

The promise is compelling: connect your personal knowledge base to AI assistants while keeping everything within EU borders. No data leaving the continent. Full control over your infrastructure. GDPR compliance by design.

We set out to build exactly this—a private AI stack running on EU-only infrastructure, integrating with Nextcloud for notes, files, and project management. Here's what we learned.

The Infrastructure

Leaf.cloud caught our attention as an EU-only cloud provider running managed Kubernetes via Gardener. They offer a two-week free tier for evaluation, which gave us time to properly test GPU workloads without upfront commitment.

Our test cluster:

• 2 worker nodes running eg1.v100x1.2xlarge

• 8 vCPU, 16GB RAM, 1x Nvidia V100 GPU (16GB VRAM) per node

• Managed Kubernetes with automatic updates and built-in DNS/TLS via Gardener

The pricing is competitive for GPU instances:

For our 2-node V100 cluster: approximately $1,780/month at full utilization.

The Stack

Our architecture connects several components:

flowchart LR
    subgraph leafcloud["☁️ Leaf.cloud (Amsterdam)"]
        subgraph k8s["⎈ Kubernetes Cluster"]
            webui["Open WebUI<br/>(Chat)"] --> ollama["Ollama<br/>(GPU LLM)"]
            webui --> mcp["Nextcloud<br/>MCP Server"]
            alloy["Grafana Alloy<br/>(Telemetry)"]
        end
    end

    subgraph external["External Services"]
        nextcloud["Nextcloud<br/>(Hetzner)"]
        grafana["Grafana Cloud<br/>(Free Tier)"]
    end

    mcp --> nextcloud
    alloy --> grafana

Open WebUI serves as our chat interface, chosen for its MCP client support and clean UI. It connects to Ollama running on the GPU nodes for local model inference.

The Nextcloud MCP Server bridges the gap between LLMs and Nextcloud APIs—exposing Deck boards, Notes, and WebDAV file operations as MCP tools that AI assistants can invoke.

The MCP Server

The Nextcloud MCP Server exposes several Nextcloud apps as MCP tools:

• Deck - Kanban boards for project management

• Notes - Markdown note-taking with categories

• WebDAV - Full file system operations

• Calendar - Event management (available but not enabled in our test)

Deployment is straightforward:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nextcloud-mcp
  namespace: ai
spec:
  replicas: 1
  template:
    spec:
      containers:
        - name: mcp
          image: ghcr.io/cbcoutinho/nextcloud-mcp-server:latest
          command:
            - /app/.venv/bin/nextcloud-mcp-server
            - run
            - --host
            - 0.0.0.0
            - --enable-app
            - deck
            - --enable-app
            - webdav
            - --transport
            - streamable-http
          envFrom:
            - secretRef:
                name: nextcloud-mcp-secret

The server uses streamable HTTP transport, making it accessible to MCP clients over the network.

The Context Overhead Problem

Here's where reality diverges from the ideal. With all tools enabled, the MCP server presents approximately 20,000 tokens of tool definitions to the LLM. This includes detailed schemas for every Deck operation (create board, create card, assign labels, move cards between stacks), every WebDAV operation (list, read, write, copy, move, search), and all Notes functionality.

For cloud LLMs with 100k+ context windows, this overhead is negligible. For local models running on a V100 with 16GB VRAM, it's a significant constraint.

Model Performance Reality

We tested a range of models through Ollama:

Key findings:

1. Small models (7B-14B) struggle with the cognitive load of 60+ tool definitions. They often hallucinate tool names, miss required parameters, or fail to recognize when a tool should be used at all.

2. Larger models (32B+) perform better but still show inconsistency. The V100's 16GB VRAM limits which models we can run effectively—an A100 80GB would significantly expand our options.

3. Cloud LLMs (Claude, Mistral AI) handle the tool definitions without issue. They correctly identify when to use tools, select the right ones, and structure arguments properly.

This isn't a criticism of local models—they're impressive for their size. But MCP's design assumes LLMs can handle large tool catalogs gracefully, which is currently only reliable with frontier models.

MCP Client Limitations

Open WebUI supports MCP connections, but with significant limitations:

1. No MCP Sampling Support - The MCP specification includes a "sampling" feature that lets servers request LLM completions for sub-tasks. Open WebUI doesn't implement this, nor do other MCP clients like claude-code and gemini-cli, meaning the MCP server can only provide tools, not leverage the LLM for intelligent operations.

2. Static Tool Listing - Tools are loaded once when the connection is established. There's no dynamic tool registration based on context or user needs.

3. No Tool Filtering - You can't selectively enable/disable tools per conversation or assistant.

The "App Expert" Workaround

To reduce context overhead and improve reliability, we found success with an App Expert pattern:

Instead of one assistant with all tools, create multiple specialized assistants:

• Deck Expert - Only Deck tools enabled

• Notes Expert - Only Notes tools enabled

• Files Expert - Only WebDAV tools enabled

Each expert has a smaller tool set (~5-8k tokens instead of 20k), which smaller models handle more reliably. Users switch between experts based on their current task.

This works, but it's a workaround for what should be a protocol-level feature. The MCP specification supports dynamic tool sets, but clients need to implement it.

Observability on a Budget

Grafana Cloud's free tier provides:

• 1,500 samples/second ingestion rate

• 15,000 sample burst limit

• Prometheus metrics, Loki logs, and basic dashboards

The challenge: a Kubernetes cluster generates thousands of metrics per scrape. Without filtering, we'd exceed the free tier immediately.

Our solution uses Grafana Alloy with aggressive metric filtering:

prometheus.relabel "cadvisor_filter" {
  # Drop all histogram buckets (huge cardinality)
  rule {
    source_labels = ["__name__"]
    regex = ".*_bucket"
    action = "drop"
  }
  # Keep only essential container metrics
  rule {
    source_labels = ["__name__"]
    regex = "container_(cpu_usage_seconds_total|memory_working_set_bytes|memory_usage_bytes|network_receive_bytes_total|network_transmit_bytes_total|fs_usage_bytes|fs_limit_bytes)|machine_(cpu_cores|memory_bytes)"
    action = "keep"
  }
  # Drop kube-system containers to reduce noise
  rule {
    source_labels = ["namespace"]
    regex = "kube-system"
    action = "drop"
  }
}

We apply similar filtering to node exporter, kubelet, and DCGM (GPU) metrics. The result: comprehensive visibility into what matters while staying within free tier limits.

Key metrics we kept:

• GPU: utilization, memory usage, temperature, power consumption

• Containers: CPU, memory, network I/O for our workloads

• Nodes: CPU, memory, disk, network at the host level

• MCP Server: Request rates and latencies

What the Metrics Revealed

We ran the POC over five working days, with the cluster auto-hibernating overnight and over weekends. This gave us clean data on actual usage patterns versus idle overhead.

Cluster Activity Windows:

Resource Utilization Summary:

MCP Server Performance:

The V100 GPU was genuinely utilized—85% utilization during inference with power draw jumping from 27W idle to 145W. This confirms we weren't just burning GPU hours on CPU-bound work.

The Honest Assessment:

The infrastructure performed well. Zero errors across the five-day POC, sub-500ms API latencies, and efficient auto-hibernation. However, the observability data confirmed what we suspected from qualitative testing: smaller models struggled with MCP tool interactions due to context constraints.

With 20,000+ tokens of tool definitions competing for context space, models in the 7B-14B range frequently:

• Failed to recognize when tools should be invoked

• Hallucinated tool names or parameters

• Lost track of multi-step operations

The 32B models showed improvement but still exhibited inconsistency. The V100's 16GB VRAM ceiling limits us to these smaller models—running a 70B parameter model that might handle the full tool catalog reliably would require an A100 80GB or H100.

Future Investigation:

A follow-up evaluation with an A100 instance ($1.61/hr vs $1.22/hr for the V100) would let us test whether larger models like deepseek-r1:70b or qwen2.5:72b can reliably handle the full MCP tool catalog. The 5x VRAM increase (80GB vs 16GB) opens up model sizes that may cross the threshold from "sometimes works" to "reliably works."

For now, the App Expert pattern (specialized assistants with reduced tool sets) remains the practical path for self-hosted deployments on V100-class hardware.

Lessons Learned

1. MCP Specification vs. Reality

The MCP specification is thoughtful and comprehensive. Client implementations are still catching up. Features like sampling, dynamic tools, and resource subscriptions exist in the spec but are rare in practice.

Recommendation for MCP server developers: Design for the lowest common denominator. Provide fewer, more focused tools rather than comprehensive coverage. Consider offering multiple tool "profiles" that clients can select.

2. Context Reduction Strategies

If you're building MCP servers:

• Minimize tool descriptions - Every token counts for small models

• Consolidate related operations - One manage_card tool with an action parameter beats five separate tools

• Make parameters optional with sensible defaults

• Consider tool "tiers" - Basic tools always available, advanced tools on request

3. GPU Memory is the Constraint

For local LLM deployments, GPU VRAM determines what's possible more than compute. The V100's 16GB limits us to models that fit with room for context. The A100 80GB at only $0.40/hr more would dramatically expand model options.

4. EU Infrastructure is Viable

Leaf.cloud proved capable for this workload. Gardener-based Kubernetes "just works"—automated TLS via cert-manager, DNS management, and straightforward GPU scheduling. The two-week free trial is genuinely useful for evaluation.

Where This Goes Next

The pieces are almost there. We need:

1. Better MCP client implementations - Sampling support, dynamic tools, tool filtering

2. Smarter tool presentation - Lazy-load tool definitions based on conversation context

3. Smaller, more capable models - The gap between 14B and 70B models is closing

4. Quantization improvements - Running larger models in less VRAM

The dream of a private AI assistant that knows your notes, manages your projects, and respects your data sovereignty is achievable today—with the right model and some workarounds. It'll be seamless within a year or two.

Try It Yourself

The stack we tested:

• Leaf.cloud - EU Kubernetes with GPU instances

• Open WebUI - Chat interface with MCP support

• Ollama - Local model serving

• Nextcloud MCP Server - MCP bridge to Nextcloud

• Grafana Alloy - Observability pipeline

Start with cloud LLMs (Claude, Mistral) for reliable tool use, then experiment with local models once your MCP server is working. And if you're building MCP clients or servers—please prioritize the sampling specification. The ecosystem needs it.

Questions or experiences to share? The Nextcloud MCP server is open source and welcomes contributions.

What if your search could understand what you mean, not just what you type?

Meet Astrolabe—a Nextcloud app that brings AI-powered semantic search to your self-hosted cloud. Named after the ancient navigational instrument that helped travelers chart courses by the stars, Astrolabe helps you navigate your personal knowledge by mapping the semantic connections between your documents.

The Astrolabe Metaphor

The astrolabe was one of humanity's most elegant scientific instruments—an analog computer for solving problems related to time and the position of celestial bodies. Its theoretical foundation traces back to Hipparchus of Nicaea (c. 190–120 BCE), who discovered the stereographic projection that allows a three-dimensional celestial sphere to be represented on a flat surface. Later Greek scholars like Theon of Alexandria and his daughter Hypatia refined it into a practical instrument, and during the Islamic Golden Age, astronomers in Baghdad, Damascus, and Cordoba perfected its design and applications.

For nearly two millennia, astrolabes served astronomers, navigators, scholars, and religious officials across the Greek, Byzantine, Islamic, and medieval European worlds. These instruments allowed users to determine time, find celestial positions, calculate daylight hours, identify constellations, and even determine the direction of Mecca for prayer—all without complex calculations. The astrolabe made the vast complexity of the heavens understandable and navigable.

Astrolabe (the app) does the same for your data. Every document, note, and calendar event becomes a point of light in your personal data universe. The app maps their semantic relationships—their meaning, not just their words—and suddenly the connections become visible. Documents cluster by topic, related ideas sit nearby, and you can navigate this landscape as naturally as medieval scholars once read the stars. Where the original astrolabe projected the celestial sphere onto brass, this one projects your knowledge into explorable semantic space.

Semantic Search: Find Meaning, Not Just Keywords

The core feature of Astrolabe is semantic search. Instead of matching exact keywords, it understands the concepts in your query and finds related content.

What this looks like in practice:

This works across multiple Nextcloud apps: Notes, Files (including PDFs with OCR), Deck cards, Calendar events, Contacts, and News/RSS items. One search bar, all your content, understood by meaning.

Hybrid Search: Best of Both Worlds

Sometimes you want exact matches ("PROJ-2024-001"), sometimes you want semantic understanding ("that project from last year about authentication"). Astrolabe's hybrid search combines both approaches:

• Semantic search uses embeddings to find conceptually related content

• BM25 keyword search finds exact matches and important terms

• Reciprocal Rank Fusion (RRF) intelligently merges the results

You can adjust the balance or switch modes entirely depending on your needs.

Astrolabe results appear alongside traditional search in Nextcloud's unified search bar

Visualize Your Data Universe

Beyond search, Astrolabe includes an interactive 3D visualization that shows your documents positioned in semantic space. Similar documents cluster together. Topics form constellations. You can rotate, zoom, and explore.

This isn't just eye candy—it's a practical tool for knowledge discovery:

• Find forgotten connections: Search for your current project and watch as related documents from months ago light up nearby

• Spot topic clusters: See how your notes naturally group by subject

• Explore the unknown: Click on points near your search results to discover content you didn't know was related

The visualization uses Principal Component Analysis (PCA) to project high-dimensional embeddings (768 dimensions) down to 3D space while preserving the relationships between documents. We implemented a lightweight, custom PCA specifically for this—no heavyweight ML libraries required.

Documents cluster by semantic similarity. The query point (red) shows your search, and related documents cluster nearby

Power Your AI Agents

Astrolabe isn't just for humans—it's for your AI assistants too.

The backend runs a Model Context Protocol (MCP) server, which means AI tools like Claude Desktop, Cursor, or custom agents can connect directly to your Nextcloud data. Your AI assistant can:

• Search your notes semantically ("Find everything related to the Kubernetes migration")

• Retrieve document content for context

• Get AI-generated answers with citations from your documents (RAG)

The critical point: your data never leaves your infrastructure. The MCP server runs on your hardware. Your AI assistant sends queries, the server returns results, and you maintain full control. No documents uploaded to third-party services.

Retrieval-Augmented Generation (RAG)

Ask a question, and Astrolabe can retrieve relevant documents and have your AI synthesize an answer—complete with citations:

You: "What were the main issues we had deploying to production last month?"

Astrolabe finds: 3 relevant notes, 2 Deck cards, 1 calendar event

AI generates: "Based on your documents, there were three main issues:
1. Database migration timeout (see Note: 'Prod deploy 2024-01-15')
2. SSL certificate renewal (see Deck card: 'Ops Tasks')
3. Resource limits on the new pods (see Note: 'K8s troubleshooting')

This uses MCP's sampling capability—the server doesn't run its own LLM. Instead, it asks your client's AI to generate the response. You choose the model, you control the costs.

Under the Hood

For the technically curious, here's how Astrolabe works:

Embedding Providers

Astrolabe supports multiple backends for generating semantic embeddings:

• Amazon Bedrock: Enterprise-grade, Titan embeddings

• OpenAI: Direct OpenAI API or compatible endpoints (including GitHub Models)

• Ollama: Self-hosted, privacy-focused, runs entirely on your hardware

The system auto-detects available providers based on environment variables and falls back gracefully. Deploy Ollama on your server for full privacy, or use Bedrock for enterprise scale—same codebase, zero code changes.

Background Indexing

Documents are indexed automatically via webhooks. When you create or edit a note, Nextcloud fires an event, and the MCP server processes it in the background. No manual sync required.

The indexing pipeline:

1. Scanner detects changes via ETags and modification timestamps

2. Queue manages backpressure (up to 10k pending documents)

3. Worker pool processes embeddings concurrently (configurable, default 3 workers)

4. Qdrant stores vectors for fast similarity search

Lightweight by Design

We deliberately avoided heavyweight dependencies:

• Custom PCA: No scikit-learn, just efficient eigendecomposition

• In-process async: No separate message queues or worker processes—just anyio TaskGroups

• Plugin architecture: New apps (Notes, Calendar, etc.) are simple scanner/processor implementations

This means Astrolabe runs comfortably alongside your Nextcloud on modest hardware.

┌──────────────┐     ┌─────────────┐     ┌─────────┐
│   Nextcloud  │────▶│ MCP Server  │────▶│ Qdrant  │
│ (Astrolabe)  │◀────│  (Python)   │◀────│ (Vectors)│
└──────────────┘     └─────────────┘     └─────────┘
       │                    │
       │ OAuth/Token        │ Embeddings
       ▼                    ▼
   ┌────────┐         ┌──────────┐
   │  User  │         │ Ollama/  │
   │Browser │         │ Bedrock  │
   └────────┘         └──────────┘

Getting Started

Requirements

• Nextcloud 31 or 32

• MCP server instance (Docker recommended)

• Vector database (Qdrant, included in Docker setup)

• Embedding provider (Ollama for self-hosted, or cloud options)

Quick Setup

1. Install the Astrolabe app from the Nextcloud App Store (or manually)

2. Start the MCP server (Docker Compose makes this easy):

    docker compose up -d mcp qdrant ollama
   

3. Configure the connection in your Nextcloud config.php:

    'astrolabe' => [
        'mcp_server_url' => 'http://localhost:8000',
    ],
   

4. Authorize access in Settings → Personal → Astrolabe

5. Start searching using Nextcloud's unified search bar

For detailed setup instructions, including OAuth configuration and embedding provider options, see the documentation.

What Can You Index?

Astrolabe currently supports:

Each result shows the document type, relevance score, and a direct link to the source. For large documents, it shows which chunk (section) matched.

Click a result to see the matching chunk in context

Who Is This For?

Researchers and students: Find all notes related to your thesis topic, even when you used different terminology across semesters. Discover connections between papers you read months apart.

Teams and organizations: Surface institutional knowledge that would otherwise stay buried. New team members can search for concepts instead of knowing exactly what to look for.

Developers: Connect your AI coding assistant to your Nextcloud. Give it access to project notes, meeting records, and documentation without copy-pasting context.

Personal knowledge managers: Discover forgotten documents related to your current work. Watch your knowledge base evolve over time through the visualization.

Try It Out

Astrolabe is open source (AGPL) and ready to use. Your data universe has been waiting in the dark—it's time to turn on the lights.

• Install: Nextcloud App Store

• Source: GitHub

• Documentation: Setup Guide

• Issues: Report bugs or request features

Astrolabe is maintained by Chris Coutinho. Contributions welcome.

The Model Context Protocol (MCP) ecosystem continues to grow, and I’m excited to introduce the new Nextcloud MCP server! This server bridges the gap between your development environment and your Nextcloud instance, specifically targeting the powerful Notes app.

What is MCP?

For those unfamiliar, MCP allows AI assistants like Claude Desktop and Cline to interact with local tools and resources securely. It’s becoming the defacto standard of integrating third-party systems into Large Language Models (LLMs). MCP servers enable developers to automate tasks, access data, and integrate various services directly into their AI applications.

Nextcloud Notes Integration

The Nextcloud MCP server leverages the Nextcloud Notes API to provide tools for managing your notes directly from your development environment. This means you can:

• Create new notes: Quickly jot down ideas, code snippets, or task lists without leaving your editor.

• Read existing notes: Access information stored in your Nextcloud Notes.

• Update notes: Modify and add content to your notes programmatically.

• Delete notes: Clean up notes that are no longer needed.

The Nextcloud API client enables using etags to prevent logs updates and conflict resolution

Example Use Cases

Imagine you're debugging a complex issue. You can use the Nextcloud MCP server to:

1. Create a new note titled "Debugging Issue XYZ".

2. Log findings, error messages, and potential solutions directly into the note content.

3. Access this note later from any device using the Nextcloud Notes app or web interface.

Or, perhaps you're planning a new feature:

1. Create a note outlining the feature requirements and tasks.

2. Update the note with progress as you work through the implementation.

Cline can be setup to check the notes before and after completing any task to accumulate knowledge about things that would otherwise have been forgotten.

Conclusion

The Nextcloud MCP server offers a convenient way to integrate note-taking into your development process, keeping your thoughts and project details organized within your trusted Nextcloud environment. We believe this will be a valuable addition for developers using Nextcloud.

For detailed setup instructions and to contribute, please visit the GitHub repository.

KafkaOps - a growing approach to operationalizing Kafka management - encompasses monitoring, triaging, and troubleshooting Kafka workflows. It's become crucial for maintaining the health and performance of Kafka-based systems as they grow in complexity and scale.

In this blog post we will introduce Conduktor Console along with its primary benefits. Next we’ll show you how you can use Conduktor Console locally to develop a simple ksqldb application. Finally, we’ll reflect on how Conduktor Console can be deployed as a shared service within an organization that is looking for a way to tame larger Kafka deployments.

Why Conduktor Console?

Conduktor Console stands out by simplifying complex tasks like schema management, message replay, and access control within an intuitive UI. Unlike alternatives such as Confluent's Control Center or Provectus' KafkaUI, Conduktor Console offers unique capabilities that make it particularly valuable for both development and platform teams.

Let's explore three key features that have driven successful adoption within our team and partner organizations:

1. Seamless Schema Management

Schema management is crucial for maintaining data consistency, but it can become complex as systems evolve. Conduktor Console excels here by providing:

• Integration with both AWS Glue and Confluent schema registries

• Visual interface for managing schema compatibility

• Simplified subject management across multiple registry types

One notable limitation: While Conduktor supports Azure Event Hubs through its Kafka protocol compatibility, it doesn't integrate with Azure's Schema Registry. This means teams using Azure Event Hubs won't be able to leverage schema-related features within Conduktor Console.

2. Powerful Message Replay Capabilities

Message replay is perhaps Conduktor's most immediately valuable feature for developers. It enables:

• Testing new code against production-like data

• Reproducing specific scenarios for debugging

• Simulating message flows without affecting production systems

This capability is particularly powerful for development teams working on new features or investigating production issues, as it allows them to work with realistic data in a controlled environment.

3. Enterprise-Grade Access Control

For platform teams, Conduktor's granular access control (available in the Enterprise Tier) provides:

• Streamlined permissions management

• Self-service access for developers

• Enhanced security through role-based controls

• Single Sign-On (SSO) integration for seamless authentication

While credential management remains a challenge for many IT departments, Conduktor's approach enables platform teams to focus on enabling self-service while maintaining security controls.

Implementing Conduktor Console in Your Workflow

Conduktor publishes a number of docker images to Docker Hub that can be deployed to local container environments. In the following example, we’re going to build on a recent version of the Confluent Community docker-compose.yml file by adding the Conduktor Console and it’s dependencies.

In addition to the Apache Kafka broker, Schema Registry, and ksqldb server, we’re also including a Kafka Connect container that will be used to generate example data. For this example we’ll leverage the Confluent Datagen Source Connector to generate random data for us to experiment with. For a list of predefined Datagen configurations, please see the examples from the kafka-connect-datagen GitHub repository.

Local Development Setup

Conduktor publishes Docker images on Docker Hub, making it easy to deploy in local container environments. Here's how to get started:

1. Pull the latest Conduktor Console image from Docker Hub

2. Create a docker-compose.yml file, building on the Confluent Community version

3. Add Conduktor Console and its dependencies to the composition

4. Launch your local Kafka environment with Conduktor Console

After spinning up the Docker Compose environment, you can navigate to the Conduktor Console which will be available at http://localhost:8080. The username/password for Conduktor Console are defined in the docker-compose.yml file above as the environmental variables CDK_ADMIN_EMAIL and CDK_ADMIN_PASSWORD - please update or override the values when deploying this docker compose environment into an insecure environment.

After configuring the Kafka cluster, associated Schema Registry, Kafka Connect workers, as well as the ksqldb server, we can start executing ksqldb statements in Conduktor Console, and perform stream processing jobs. The following shows a push query emit the total revenue generated for various item types within a window session. To learn more about ksqldb windowing options, please see the documentation on Time and Windows.

Enterprise Deployment

For larger organizations, deploying Conduktor Console as a shared service can significantly enhance Kafka operations:

1. Centralized Management: Streamline workflows and reduce latency by having a single point of control

2. Consistent Monitoring: Ensure uniform monitoring and management across all Kafka clusters

3. Enhanced Collaboration: Enable teams to work together more effectively on Kafka-based projects

For AWS users, Conduktor Console's integration with services like MSK and Glue Schema Registry further enhances its functionality. Leveraging AWS IAM roles and policies facilitates secure, credential-less authentication, simplifying user management and reducing security risks.

Deploying in a Shared Environment

Centralizing Kafka management tools within your infrastructure can greatly enhance operational efficiency. By streamlining workflows and reducing latency, teams can collaborate more effectively and resolve issues faster. This centralized approach ensures consistent monitoring and management of Kafka clusters, leading to improved performance and reliability.

Additional requirements such as networking and security may restrict which resources Conduktor Console could access while deployed locally. For this reason, organizations may want to host Conduktor Console on their own infrastructure. For our team’s internal use, we took extensive inspiration from the documentation on Deployment on AWS based on ECS and RDS. This can expanded upon to include SSL certificates via ACM and route requests via a custom domain registered in Route53.

For organizations using AWS Managed Streaming for Apache Kafka (MSK), Conduktor Console's natively supports using IAM roles to authenticate with MSK and the Glue Schema Registry. AWS IAM roles and policies facilitate secure, credential-less authentication, simplifying user management and reducing the risk of credential exposure via long-lived API keys.

Conclusion

Conduktor Console represents a significant leap forward in Kafka management, addressing the real-world challenges of operating Kafka at scale. By simplifying complex operations, enabling self-service capabilities, and providing robust security features, it allows teams to focus on building and maintaining robust streaming applications rather than wrestling with operational complexities.

Whether you're a platform team managing multiple clusters or a development team building Kafka-based applications, Conduktor Console provides the features and workflows needed to work effectively with Apache Kafka in a modern enterprise environment.

We encourage you to explore Conduktor Console for your Kafka operations. Start with a local setup to experience its benefits firsthand, and consider how it might enhance your team's productivity and your organization's Kafka management at scale.