Skip to main content

Operations Roadmap

This is deliberately separate from the Roadmap and Detailed Roadmap. Those describe the product - what Yew Search does for the people using it. This page describes the supporting software needed to actually run and understand Yew Search as a service: observing whether the system is healthy, and understanding whether anyone is actually using the marketing/docs sites. None of this is user-facing product functionality.

Observability in the AWS deployment​

Current gap: the observability stack (Loki, Prometheus, Tempo, Grafana - see docs/docs/observability/README.md) is fully built and documented for local development, but is not actually running in the AWS deployment. Production logging is currently disabled (LOGGING_ENABLED=false in the AWS secrets), and tracing/metrics were never wired up there either. This means the AWS-hosted yewsearch.com environment - the one real users would actually hit - currently has no real visibility into its own health.

The application-level support already exists (LOGGING_ENABLED/TRACING_ENABLED/METRICS_ENABLED/LOKI_URL/TEMPO_URL env vars, structured CustomLoggerService output, OTLP tracing). What's missing is the operational side: actually running Loki/Prometheus/Tempo/Grafana (or equivalent managed services) somewhere the AWS-hosted backend can reach, and turning the existing env vars on.

Why this matters independent of the product roadmap: none of the knowledge-engine capabilities (search quality, the MCP server, the conversational assistant) can be responsibly operated without knowing whether the system is actually healthy - a search-quality regression or an MCP server outage should be caught by observability tooling, not by a user complaining first.

Website/docs traffic analytics (Matomo)​

Current gap: there is no visibility into who visits the marketing site or documentation site, or what they're interested in - no analytics of any kind. Matomo (self-hosted, privacy-respecting alternative to Google Analytics - consistent with Yew's own self-hosted-first, privacy-conscious positioning) is the intended tool for this, not yet deployed anywhere.

This is about understanding interest in the product's public-facing surface (does the roadmap's "knowledge engine" positioning actually land with visitors, which docs pages get traction, where people drop off before signing up) - separate from the AWS observability gap above, which is about the running system's health, not visitor behavior.

Open questions, not yet decided​

  • Whether the AWS observability stack should be self-hosted on AWS itself, run on the homelab (consistent with how Elasticsearch and Ollama already work - see Detailed Roadmap), or use a managed third-party service (e.g. Grafana Cloud) instead of self-hosting Loki/Prometheus/Tempo/Grafana at all.
  • Where Matomo would run (homelab vs. AWS) and how it fits into the existing website/docs deployment pipeline.
  • Whether this work is a prerequisite for V2/V3 (operating a multi-tenant SaaS without observability seems clearly wrong) or can continue to be deferred through V1.