Parseable 3.0 brings a lot of visible product changes, but the release is also about making the platform safer, easier to operate, and better suited to teams already handling logs, metrics, traces, agents, runtimes, and model traffic in one production environment.
For existing users, the first reason to look at 3.0 is security and operational hardening: fixes around API key security, SQL injection protection in list condition expressions, SSRF hardening for alert targets, path traversal protection for local filesystem filters, dataset authorization, and OAuth and OIDC flows, plus dependency and runtime hardening across the backend and Prism UI.
For new users, the release shows where Parseable is heading. The platform is expanding from observability, storage and querying into the workflows around it: agent-aware tooling, MCP access, a command line interface, AI infrastructure integrations, Agent Observability, multi tenancy, APM service maps, Kubernetes operations, and reusable dashboards.
If you already run Parseable, upgrade for the hardening. If you are evaluating it for the first time, this release offers a snapshot of what the platform now covers.
Security first
3.0 tightens several parts of the platform that affect how users authenticate, query, filter, and isolate data.
The release fixes API key security, adds SQL injection protection in list condition expressions, corrects OAuth sync and OIDC redirect behavior, hardens dataset authorization, adds SSRF protection for alert targets, and closes a path traversal gap in the filters API on local filesystem storage. It also adds alert query mode metadata, updates the ingestion and trace endpoints, and fixes OpenTelemetry handling of exemplars and metric fields.
For teams running Parseable in shared or regulated environments, this hardening makes it safer to keep pushing telemetry into the platform. If you are on an older release, 3.0 is the one to move to.
Tools for teams and agents
This release also adds more ways to work with telemetry outside the browser - because a lot of day-to-day investigation happens from terminals, IDEs, coding agents, and MCP clients.
That is where the Parseable MCP Server fits in. With the 3.0 release, Parseable can connect to Claude, Cursor, VS Code, Codex, and other MCP-compatible clients, giving them safe tools to inspect logs, metrics, traces, alerts, schemas, and cluster health. The useful part is that operational questions can move closer to where teams are already working.
For example, if a team needs to understand why checkout latency moved in the last 30 minutes, the MCP client can inspect datasets, understand schemas, run bounded SQL or PromQL, and return a useful trail of evidence. That is a better loop than copying field names between tabs while an incident is still open.
pb, the Parseable command line interface, solves a different part of the workflow. It gives teams a fast way to query, tail, inspect profiles, and automate telemetry workflows from the terminal.
AI infrastructure observability
AI systems rarely fail as one thing. A model call can be healthy while the agent picks the wrong tool, the sandbox times out, the gateway routes to a slower provider, or a workflow retries for ten minutes before returning an answer.
That is why we now think about AI observability as an infrastructure problem, not just an LLM request problem. The ecosystem has layers, and each layer exposes a different kind of evidence.
-
Agent frameworks sit closest to the application intent. Integrations such as Pydantic AI, CrewAI, Mastra, and n8n help teams see agent runs, model calls, tool calls, workflow steps, and failures near the code that made the decision.
-
Sandboxes and runtimes take the next step down, where the work actually runs. Systems like Daytona, Temporal, DBOS, Restate, and Modal give teams visibility into execution, retries, sandbox logs, workflow traces, and runtime metrics.
-
LLMs expose the model path. That includes integrations such as vLLM, Ollama, LiteLLM SDK, OpenAI, and Anthropic. This layer helps answer model-facing questions around latency, errors, tokens, and inference behavior.
-
Gateways sit between applications and model providers. OpenRouter and LiteLLM Gateway are useful when teams want to observe routing, provider latency, model traffic, and gateway-level behavior without instrumenting every application from scratch.
These categories are useful because they tell you where to look. Agent behavior, runtime execution, model calls, and gateway routing all answer different questions. Parseable brings those signals into one place so the investigation can follow the system instead of stopping at the first convenient boundary.
Governance across teams
As more teams send telemetry into the same platform, governance starts with a simple question: who can see, send, query, and operate which data. This becomes more important when one cluster has enough capacity to serve several teams or workspaces, but the boundaries between them still need to stay clear.
Multi tenancy is how Parseable starts to support that model. Admins can govern shared deployments by keeping users, roles, API keys, datasets, dashboards, alerts, and queries scoped to the right tenant. In multi tenant mode, ingestion and API-key based requests use x-p-tenant with x-api-key, and Parseable resolves the user, permissions, dataset access, storage paths, and query schema inside that tenant boundary. That gives platform teams a cleaner way to share infrastructure without turning every workspace into a separate cluster.
Product surfaces
Once the data lands in Parseable, the next question is how teams actually use it. The release improves several product surfaces that users will see directly in Prism.
-
APM service maps help users see how services relate to one another before drilling into traces and errors. When a service is noisy, a map gives you a faster way to understand which services are connected and where to start the investigation. The 3.0 release notes also call out APM and traces moving to service APIs and service map becoming the default option in APM.
-
Agent Observability gives teams a dedicated way to inspect agent activity in Prism. It is built on OpenTelemetry semantic conventions for GenAI, so agent runs can be understood as connected model activity, tool calls, messages, and spans instead of a loose pile of logs. This is useful because agent failures are often sequence problems. Platform teams and application teams can look at the same run and talk about the same model call, tool invocation, span, or failed step.
-
Dashboards give teams reusable starting points for common ecosystems. The parseablehq/dashboards repository now acts as a place for dashboard templates across OpenRouter, Temporal, databases, infrastructure tools, and other integrations. That makes it easier to start with a useful view instead of a blank page.
Kubernetes operations
The product changes are only one side of the release. Parseable 3.0 also improves the Kubernetes side of the story. A lot of observability work starts with installation, storage, collectors, Helm values, annotations, secrets, scrape configs, and one-off YAML that only a few people understand.
The Helm chart changes are the first part of that cleanup. The Parseable Helm Chart 3.1.0 update makes storage choices explicit across standalone, distributed, and Enterprise deployments. Standalone storage now follows the StatefulSet lifecycle, object-store deployments avoid unnecessary data volumes, unsupported storage combinations fail during Helm template rendering, and Enterprise hot-tier cache defaults are clearer.
There is one upgrade note worth calling out. Standalone deployments on older chart versions should not treat this as a simple in-place Helm upgrade, because the standalone storage model now uses StatefulSet volume claim templates and Kubernetes does not mutate those templates cleanly after installation. The safer path is to create a fresh chart 3.2.0 installation, migrate and verify the required data, then move traffic once ingestion, queries, authentication, and retention are working as expected. The storage behavior documentation covers this migration path in more detail.
PAI builds on that Kubernetes path for telemetry collection. It is a Kubernetes operator that uses the OpenTelemetry Operator and OpenTelemetry Collector to collect logs, metrics, traces, and Kubernetes events, with zero manual OpenTelemetry configuration required. Platform teams define a ParseableConfig, and PAI reconciles the collectors, instrumentation resources, runtime detection, datasets, authentication headers, and signal-specific pipelines from there.
The useful part is not that PAI hides OpenTelemetry. It keeps the generated collectors and instrumentation resources inspectable as normal Kubernetes objects. Teams can still use kubectl, check collector logs, review generated resources, and control rollout through namespace and workload selectors. PAI gives them a smaller Parseable-aware control plane for the telemetry wiring they would otherwise maintain by hand.
For platform teams, this makes installation and upgrades less surprising. The chart now better reflects where Parseable data actually lives, whether that is local storage for standalone deployments, object storage for distributed deployments, or hot-tier cache for Enterprise queriers.
What this release adds up to
Security hardening gives older deployments a reason to upgrade now. MCP and pb make Parseable usable from terminals, IDEs, and agent workflows.
The AI infrastructure integrations cover agent frameworks, sandboxes, runtimes, LLMs, and gateways as distinct layers.
Agent Observability, multi tenancy, service maps, dashboards, PAI, and the Helm updates make that data easier to collect, operate, and inspect once it reaches Prism.
Observability data keeps getting more complex, and AI workloads accelerate that. Parseable's answer is still an object storage first, data lake architecture that keeps telemetry compressed in the storage layer you choose, with the product surfaces everything teams need to investigate, govern, and retain operational data.
