Dashboard

The Layer dashboard is the operator UI that ships in-cluster alongside the gateway, as the layer-dashboard Deployment and Service. This page covers running it: the access it needs, how to reach it, how to gate it, and how to turn it off.

Access it needs

The dashboard is read-mostly and backed by three sources, each with its own grant:

• The gateway API — the same endpoints customers use, plus the Prometheus-compatible metrics proxy at /v2/metrics. Authenticated with a gateway bearer (LAYER_GATEWAY_API_KEY). In deriveFromStore mode this is the default VectorStore credential; in keys mode it is the configured inbound worker key. It does not touch PostgreSQL, Aerospike, or VictoriaMetrics directly — metrics and cost arrive through the gateway proxy and /v2/cost.
• The Kubernetes API — reads hevlayer.com CRDs (VectorStores, Indexes, InfraRules, Pipelines) and the workload objects behind them (pods, deployments/statefulsets, HPAs, KEDA ScaledObjects, nodes) through RBAC bound to its ServiceAccount. dashboard.kubeAccess.enabled grants the read role; with it off the dashboard still runs but the cluster/scaling views show a “kube access not configured” banner. dashboard.writeAccess.enabled adds the operator write role: Index spec patches, Karpenter NodePool disruption, VectorStore and Warehouse create/edit, and namespace-scoped Secret writes for credentials. Set it false for a read-only install.
• Cost data — the cost view reads the gateway cost API. turbopuffer spend is metered from upstream billing counters; AWS spend is read by the gateway from Cost Explorer using the gateway IRSA role. The dashboard does not need direct AWS cost API permissions for the standard cost view. In a Terraform install, still pass dashboard.serviceAccount.roleArn from the layer_dashboard_role_arn output so the dashboard ServiceAccount is annotated with its cluster-specific IRSA role at first boot.

Networking

The dashboard is an operator tool. Reach it over a port-forward rather than exposing it publicly:

kubectl port-forward -n <release-namespace> svc/layer-dashboard 8081:8081

Then open http://localhost:8081. Customer workloads only ever receive the gateway base URL and credentials — never the dashboard.

Basic auth

HTTP Basic auth sits in front of every dashboard route and is required — the dashboard refuses to start without it. Set credentials through the chart:

dashboard:
  basicAuth:
    user: ops
    password: <strong-password>

The chart render fails if either field is blank while the dashboard is enabled.

Disabling the dashboard

The dashboard is optional. Disable it and the Deployment, Service, RBAC, and ingress all skip rendering:

dashboard:
  enabled: false

The gateway and transform runtime run unchanged without it; you lose only the operator UI.

Operational notes

Pipeline queue states

The pipeline overview combines gateway queue counters with the matching Pipeline resources and their operator-managed Deployments and KEDA ScaledObjects. A queue with pending work is presented as:

• PAUSED when every matching Pipeline has spec.paused: true. Its workers are intentionally at zero replicas; pending documents remain queued.
• CRON-GATED when its cron ScaledObject is inactive. The card shows the next UTC window, scaler activity, and managed worker replica counts.
• STALLED when work is pending with no processing or indexing activity and neither an intentional pause nor a closed cron window explains the stop.

Failed-document counts, operator condition messages, and missing or inactive managed workers appear as reason hints on the same card. A growing queue that is still processing remains BACKLOG rather than STALLED.

The data tab is split into indexes, vector store, and warehouse views. Indexes come from /v2/namespaces; vector stores and warehouses come from the gateway’s /v2/vectorstores and /v2/warehouses projections, so the dashboard shows the same credential-safe shape as the CLI and SDKs.

When write access is enabled, the vector store and warehouse panes can create and edit those CRDs. Raw credentials are accepted only in the form submission; the dashboard writes them into Kubernetes Secrets first, then creates or patches the CR. The read views keep showing only Secret references.