Ongrid v0.11.0

Ongrid v0.11.0

Ongrid v0.11.0 introduces reusable batch enrollment for non-Kubernetes devices, first-class device cluster management, and persistent rolling Edge upgrades. It also makes Manager upgrades safer on large data directories, strengthens Kubernetes inventory for large clusters, validates installer-discovered public addresses, and fixes several UI and concurrency issues.

This release turns device installation from a one-command-per-device workflow into a reusable, bounded enrollment flow and adds the fleet lifecycle around it: organize hosts into a device cluster, inspect membership and versions, run guarded rolling upgrades, leave the page while the job continues, and return later to review or retry individual results.

Highlights

Reusable batch enrollment for non-Kubernetes devices

The Devices page can now create a reusable enrollment batch and generate one installation command for multiple Linux hosts.

• A batch can be used as installation-only grouping or can automatically attach newly enrolled devices to a selected device cluster.
• The first non-Kubernetes device cluster can be created directly from the batch-enrollment flow; an existing cluster is not required beforehand.
• Each enrolled host receives its own Edge credential. Devices do not share a long-lived runtime access key.
• Enrollment batches are bounded by expiration and maximum-use limits and can be deleted when no longer needed.
• The enrollment token is shown only when the batch is created. Treat the generated installation command as a secret and distribute it only to intended hosts.
• Existing single-device enrollment and previously registered devices remain compatible.

Important

A device cluster is an Ongrid fleet-management group for non-Kubernetes hosts. It does not turn those hosts into a Kubernetes cluster and does not replace the dedicated Kubernetes management page.

Device cluster management

A new Infrastructure → Clusters area provides a dedicated management surface for non-Kubernetes device groups.

• View cluster member, online/offline, and active enrollment-batch counts from the cluster list.
• Open a cluster by clicking its row and manage members, installation batches, naming, and lifecycle from the detail page.
• Add existing eligible devices manually or let a reusable enrollment batch assign new devices automatically.
• Remove a member without deleting the underlying device.
• Rename a cluster, delete unused enrollment batches, and delete an empty cluster with server-side membership safeguards.
• Device pages now display consistent Host, Kubernetes, and device-cluster labels so ownership is visible without opening another page.

Persistent rolling Edge upgrades

Device clusters can now upgrade their Host Edge agents as a durable background operation instead of a browser-bound bulk request.

• Preflight separates eligible devices from devices that are already current, offline, missing an Edge association, using an unsupported OS or architecture, or blocked by a missing/invalid release artifact.
• Linux amd64 and arm64 devices use architecture-specific packages and SHA-256 verification.
• A single job supports up to 500 devices. The default rollout processes 10 devices per batch with at most 8 concurrent dispatches inside a batch.
• The next batch does not start until the current batch reaches a terminal state, limiting the number of simultaneously disrupted hosts.
• Jobs and per-device results are persisted. Closing the browser, leaving the page, or restarting the Manager does not discard progress.
• Completion requires both a new Edge registration and the target agent version; successfully sending an upgrade command alone is not considered success.
• Upgrade history includes original/target versions, architecture, batch, attempts, state, and failure reason. Failed or timed-out devices can be retried without repeating successful devices.
• The existing Edge package updater continues to use checksum validation, atomic replacement, and automatic rollback on apply failure.

Safer and faster Manager upgrades

Routine upgrades no longer recursively change ownership across accumulated MySQL, Prometheus, Loki, Tempo, and Grafana data.

• The normal path validates and repairs only bind-mount top-level directory metadata before stopping the running stack.
• Large observability data directories no longer cause long recursive chown scans and extended upgrade outages.
• If required permissions cannot be established, the upgrade stops before downtime where possible.
• sudo ./upgrade.sh --repair-permissions remains available as an explicit recovery operation for manually damaged permissions or backups that did not preserve ownership. Because it recursively scans data, it should not be used for routine upgrades.
• Existing .env, TLS certificates, and persisted data remain preserved.

Kubernetes inventory and observability reliability

Kubernetes inventory now uses resource-specific API shapes instead of decoding every workload kind through one shared status model.

• Active CronJobs no longer break an entire workload snapshot, while Job active/failed execution counts remain available.
• Deployment-owned ReplicaSets retain controller UID, revision, and creation metadata and appear as expandable rollout history; standalone ReplicaSets remain visible.
• Workloads, Pods, Nodes, and Events use server-side pagination, keeping requests bounded on clusters with 1,500+ Pods.
• Workload health calculations and stale HPA warning expiry are more accurate.
• Kubernetes telemetry preserves the Manager public URL for TLS origin matching.
• Tempo OTLP/HTTP ingestion checks and Manager-side Tempo query-readiness checks now target their correct protocols and listeners.

Installer, UI, and reliability fixes

• Public-address discovery rejects HTTP error pages and non-IPv4 response bodies instead of persisting them as ONGRID_PUBLIC_URL. Explicitly configured public URLs are validated before install and before an upgrade stops the old stack, with the validated outbound-interface address retained as fallback (#246).
• The device action menu measures available viewport space, opens above the trigger when appropriate, and remains scrollable and reachable on short screens (#254, closes #198).
• The in-memory chat-session test repository returns snapshots instead of shared pointers, eliminating a scheduling-dependent race in CI (#258).
• Core checkout, Go, Node, Helm, and Buf workflow actions were updated to maintained runtime generations (#259).

Compatibility and operational notes

• Upgrading from v0.10.2 does not require a manual database migration. New tables and fields are applied through the existing GORM AutoMigrate path.
• Existing Edge APIs, single-device enrollment, registered devices, Kubernetes management, and the previous synchronous bulk-upgrade API remain compatible.
• Cluster rolling upgrade currently targets online Linux Host Edge devices on amd64 and arm64. Ineligible devices are reported during preflight and are not sent an upgrade command.
• Manager installation remains Docker Compose only. Ubuntu 22.04+, Debian 12+, and RHEL/Rocky 9 are supported; Docker 24.0+ and Docker Compose v2 are required.
• Manager Compose recreation causes a short service interruption. Device-cluster rolling upgrades also briefly disconnect each Edge as its batch is processed.
• Kubernetes users should continue to use the cluster-specific Helm upgrade command generated by the Ongrid Kubernetes page. Helm 3.14+ is required for the generated command.

The v0.11.0 Kubernetes Chart is published at:

oci://helm.cnb.cool/ongridio/ongrid-edge

To inspect the Chart:

helm show chart oci://helm.cnb.cool/ongridio/ongrid-edge --version 0.11.0

Fresh installation

AMD64

wget https://github.com/ongridio/ongrid/releases/download/v0.11.0/ongrid-v0.11.0-linux-amd64.tar.xz
wget https://github.com/ongridio/ongrid/releases/download/v0.11.0/ongrid-v0.11.0-linux-amd64.tar.xz.sha256
sha256sum -c ongrid-v0.11.0-linux-amd64.tar.xz.sha256
tar -xf ongrid-v0.11.0-linux-amd64.tar.xz
cd ongrid-v0.11.0-linux-amd64
sudo ./install.sh

ARM64

wget https://github.com/ongridio/ongrid/releases/download/v0.11.0/ongrid-v0.11.0-linux-arm64.tar.xz
wget https://github.com/ongridio/ongrid/releases/download/v0.11.0/ongrid-v0.11.0-linux-arm64.tar.xz.sha256
sha256sum -c ongrid-v0.11.0-linux-arm64.tar.xz.sha256
tar -xf ongrid-v0.11.0-linux-arm64.tar.xz
cd ongrid-v0.11.0-linux-arm64
sudo ./install.sh

Upgrade

Manager

Download and extract the v0.11.0 package matching the target architecture, then run:

cd ongrid-v0.11.0-linux-<arch>
sudo ./upgrade.sh

The upgrade script validates and pulls all required images before stopping the current stack, preserves .env, certificates, and data, updates the Compose configuration, starts v0.11.0, and waits for /healthz.

Do not add --repair-permissions unless ownership was manually damaged, restored from an incompatible backup, or directed by troubleshooting guidance.

Kubernetes Edge

After upgrading the Manager, open the Kubernetes cluster page and run its generated one-command Helm upgrade in the target cluster. Verify the Controller, Telemetry Gateway, Metrics Scraper, kube-state-metrics, and Node Edge workloads are Ready after Helm completes.

Release artifacts

Artifact	Version / digest
Manager image	docker.cnb.cool/ongridio/ongrid:v0.11.0
Web image	docker.cnb.cool/ongridio/ongrid/ongrid-web:v0.11.0
Kubernetes Edge image	docker.cnb.cool/ongridio/ongrid-edge:v0.11.0
Kubernetes Helm Chart	oci://helm.cnb.cool/ongridio/ongrid-edge version 0.11.0
AMD64 package	4145b8a288d6635882f69085d22df591dd8a8ae8b88d377119ff3aa8ec8628e3
ARM64 package	84239e6fe5ce01236c8f7269272acd996388b020f6d5844971d6ff89e7c3086c

The release also includes checksum files and latest.json metadata for automated download discovery.

What's Changed

Device enrollment and fleet management

• #255 Add bounded reusable Edge enrollment batches, independent per-host credentials, batch-only grouping, and optional device-cluster assignment.
• #257 Add device cluster list/detail management, membership lifecycle, persistent rolling upgrades, progress history, retry, and Manager-restart recovery.

Kubernetes and observability

• #250 Normalize Kubernetes workload schemas, add bounded resource pagination and Deployment rollout history, correct health/warning behavior, and separate Tempo ingest from query probes.

Installation and upgrade safety

• #246 Validate discovered and configured public addresses before persisting or using them.
• #252 Remove routine recursive ownership scans and add an explicit permission-repair recovery mode. Closes #248.

UI and reliability

• #254 Keep the device action menu inside the viewport. Closes #198.
• #258 Remove the shared-pointer data race from in-memory chat-session tests.

Documentation, CI, and release

• #245 Update multilingual installation links for the preceding v0.10.2 release; no v0.11.0 runtime behavior change.
• #259 Update core GitHub Actions to maintained runtime generations.
• #260 Prepare the v0.11.0 release version.

Full Changelog: v0.10.2...v0.11.0