Persistent Logs

Rise exposes deployment logs through its API, frontend, and CLI. Three backends are available, selected by the deployment_logs.type setting:

Backend	What it queries	Historical reach
kubernetes (default)	pods/log on the active Pod	Only while the Pod exists
loki	Grafana Loki via HTTP	As long as Loki retains the lines
cloudwatch	One ECS deployment’s streams in the configured CloudWatch Logs group	As long as CloudWatch retains the events

Regardless of the backend, the Rise API is the only thing clients talk to — Rise enforces project authorization before reading from the backing log store. The backing log service is never exposed to end users.

Kubernetes backend (default)

deployment_logs:
  type: kubernetes

This is the default and requires no extra infrastructure. It streams the Kubernetes pods/log API directly.

Limitations:

• No history past the Pod’s lifetime. When a deployment is rolled, superseded, or its Pod is evicted, its logs vanish. The UI and CLI surface this as “no active deployment pod was found.”
• Backward scrolling is bounded by the kubelet’s per-container log retention. The UI can page back through whatever the kubelet currently holds (typically a few MB per container, controlled by --container-log-max-size), and stops at “End of log stream” once that buffer is exhausted.
• No cross-Pod aggregation. Each Pod’s stream is independent; there is no merged view across replicas (only a single Pod’s lines are returned per request).
• No log volume chart. The chart in the UI requires a metric-style count query that this backend can’t serve; it reports “Log volume charts aren’t supported by the configured log backend.”

For any of the above, switch to a persistent backend.

CloudWatch backend

deployment_logs:
  type: cloudwatch
  retention_hint: 30d

This backend is paired with the ECS deployment controller and uses its AWS configuration and log_group. App task streams begin with {resource_prefix}/{project_uuid}/{deployment_uuid}/; the awslogs driver adds the container name and task ID. Rise merges those streams for tailing, search, level filtering, live follow, and log-volume buckets.

The control-plane identity needs logs:FilterLogEvents and logs:StartLiveTail on that group. retention_hint only improves the empty state shown for an old deployment; CloudWatch’s log-group retention policy is authoritative.

Loki backend

Requires Loki 3.0+ — the volume chart and the server-side ?level= filter both rely on Loki’s detected_level label and come back empty on older versions. Per-line classification has a regex fallback so the unfiltered line list still renders levels even when Loki hasn’t yet classified an entry. See Loki backend for the full picture including the available level vocabulary.

See Loki backend for setup with the bundled Helm subchart, an operator-managed external Loki, label overrides, and bearer-token wiring.