Skip to main content

Operations & uninstallation

Day-2 operations for a running Octostar deployment, and how to tear an environment down.

Common operations​

# Update an existing installation (see Upgrading for details)
./bin/update-existing.sh --context <context-name>

# Dump logs from the install namespace to a timestamped file
./bin/install.sh --dump-logs --context <context-name>

# Remove the environment
./bin/destroy.sh --context <context-name>

Inspecting the cluster​

# Pod and service status (default namespace: octostar-main)
kubectl get pods -n octostar-main
kubectl get svc  -n octostar-main

# Logs for a workload
kubectl logs -n octostar-main deploy/<deployment>

# Roll-out status during an upgrade
kubectl rollout status deploy/<deployment> -n octostar-main

If you installed them with --install-utils, k9s (interactive cluster view) and stern (multi-pod log tailing) make this much faster:

k9s -n octostar-main
stern -n octostar-main <pod-name-prefix>

Monitoring​

The monitoring stack (Prometheus, Grafana, Loki, optional Tempo) deploys into the platform namespace by default. Grafana ships pre-loaded dashboards for the platform dependencies (ClickHouse, OpenSearch, PostgreSQL, SeaweedFS, Temporal, and the octostar-api). Tune log retention and tracing via the monitoring: block in local-env.yaml (see Configuration).

Uninstalling​

./bin/destroy.sh --context <context-name>

⚠️ Destructive — destroy.sh removes the Octostar deployment from the targeted context. Persistent volumes and their data may be deleted depending on storage class and reclaim policy — back up any data you need first.

Getting help​

  • Check the console output and --dump-logs archive for detailed error messages (re-run with --log-level debug for more verbosity).
  • Contact Octostar support, or file an issue in the relevant repository.