|
| 1 | +--- |
| 2 | +title: 'Aetheris 1.4.0 and 1.4.1: faster resource switching, favorites, richer object detail and a maintainability pass' |
| 3 | +description: Aetheris 1.4.0 improves day-to-day Kubernetes browsing with object caching, favorite objects, better status filters, clearer container resource metrics and cleaner Windows packaging. 1.4.1 follows up with Deployment pod states, Service/Ingress detail, and an internal refactor. |
| 4 | +date: 2026-07-11 |
| 5 | +tag: Aetheris |
| 6 | +--- |
| 7 | + |
| 8 | +[Aetheris 1.4.0](https://github.com/luminusOS/aetheris/releases/tag/v1.4.0) |
| 9 | +is out with a release focused on the parts of Kubernetes work that happen over |
| 10 | +and over again: switching between resources, returning to important objects, |
| 11 | +reading container resource usage, and keeping the app predictable across |
| 12 | +platforms. |
| 13 | +([1.4.1](https://github.com/luminusOS/aetheris/releases/tag/v1.4.1), a |
| 14 | +follow-up release that rounds out object detail and cleans up the codebase |
| 15 | +internally, is covered at the end of this post.) |
| 16 | + |
| 17 | +The previous releases shaped the workspace and made the resource table faster. |
| 18 | +This one keeps pushing in that direction. Aetheris now does more to preserve |
| 19 | +context while you move around a cluster, and it gives frequently inspected |
| 20 | +objects a proper place in the interface. |
| 21 | + |
| 22 | +<figure> |
| 23 | + <img src="../../img/aetheris/aetheris-1-4-0-workspace.png" alt="Aetheris 1.4.0 resource browser with cached objects and status/column filters." loading="lazy" /> |
| 24 | + <figcaption>Aetheris 1.4.0's resource browser, with cached object lists and filters.</figcaption> |
| 25 | +</figure> |
| 26 | + |
| 27 | +## Resource lists that feel closer |
| 28 | + |
| 29 | +Aetheris now keeps a small in-memory cache of recently loaded object lists. |
| 30 | +When you move between resources, namespaces or views, the app can immediately |
| 31 | +show the last known objects while it refreshes the live data in the background. |
| 32 | +That makes repeated navigation feel much less like starting over every time. |
| 33 | + |
| 34 | +The cache is scoped by cluster context, resource type and namespace, so cached |
| 35 | +Pods from one namespace do not leak into another view. It is also cleared after |
| 36 | +mutating operations such as creating, applying, scaling, cordoning, draining or |
| 37 | +deleting objects. The intent is simple: keep the interface responsive without |
| 38 | +pretending stale data is authoritative. |
| 39 | + |
| 40 | +Object loading also has a timeout now. If a cluster or API server stalls while |
| 41 | +listing a resource, Aetheris reports the problem instead of leaving the |
| 42 | +workspace in an indefinite loading state. When a cached list exists, the app can |
| 43 | +fall back to it while still surfacing the error. |
| 44 | + |
| 45 | +## Favorites for the objects you keep opening |
| 46 | + |
| 47 | +Some Kubernetes objects become part of your working set: the Deployment you are |
| 48 | +tuning, the Pod you keep inspecting, the Service that anchors a stack, the Node |
| 49 | +you are debugging. Aetheris 1.4.0 adds favorite objects so those targets can be |
| 50 | +kept close. |
| 51 | + |
| 52 | +The detail header now has a favorite action, and the sidebar can switch between |
| 53 | +the regular resource list and saved favorites. Favorites are stored with the |
| 54 | +cluster context, resource identity, namespace and object name, which keeps them |
| 55 | +precise even when different clusters contain objects with similar names. |
| 56 | + |
| 57 | +<figure> |
| 58 | + <img src="../../img/aetheris/aetheris-1-4-0-favorites.png" alt="Aetheris 1.4.0 favorites sidebar and the starred action in the object detail header." loading="lazy" /> |
| 59 | + <figcaption>Favorite objects in the sidebar, and the starred action in the object detail header.</figcaption> |
| 60 | +</figure> |
| 61 | + |
| 62 | +This release also expands the symbolic icon set used by the app. The new icons |
| 63 | +make resource groups and actions easier to scan without turning the interface |
| 64 | +into a wall of text. |
| 65 | + |
| 66 | +## Better status and metrics signal |
| 67 | + |
| 68 | +The status filter now understands `Available` in addition to the existing |
| 69 | +states such as `Ready`, `Unavailable`, `Running`, `Pending` and `Failed`. That |
| 70 | +matters for Deployments that are not fully ready but still have available |
| 71 | +replicas. Instead of collapsing those cases into a less useful state, Aetheris |
| 72 | +can now present partial availability as its own signal. |
| 73 | + |
| 74 | +Container metrics in the object detail view have also been reworked. Pod |
| 75 | +containers now show current usage alongside requests and limits in a compact |
| 76 | +row. CPU and memory are still formatted into human-friendly values, but the |
| 77 | +view is easier to read at a glance and keeps the raw relationship between |
| 78 | +current, request and limit close to the container name. |
| 79 | + |
| 80 | +<figure> |
| 81 | + <img src="../../img/aetheris/aetheris-1-4-0-metrics.png" alt="Aetheris 1.4.0 container CPU and memory usage shown alongside requests and limits." loading="lazy" /> |
| 82 | + <figcaption>Container CPU and memory usage, shown alongside requests and limits.</figcaption> |
| 83 | +</figure> |
| 84 | + |
| 85 | +Behind that UI, Aetheris now reads resource requests and limits from regular, |
| 86 | +init and ephemeral containers. Pod detail loading also fetches summary metrics |
| 87 | +and per-container metrics together, which keeps the detail pane from doing more |
| 88 | +round trips than necessary. |
| 89 | + |
| 90 | +## Cleaner packaging |
| 91 | + |
| 92 | +The Windows build now embeds application resources directly into the executable |
| 93 | +and ships with a dedicated Windows icon. That makes the packaged app feel more |
| 94 | +native on Windows while keeping the release workflow smaller and easier to |
| 95 | +maintain. |
| 96 | + |
| 97 | +This release also removes the experimental OpenConnect integration. Aetheris is |
| 98 | +staying focused on being a native Kubernetes client: kubeconfig, projects, |
| 99 | +resources, YAML, logs, terminals and day-to-day cluster operations. Removing |
| 100 | +the unused VPN layer cuts maintenance surface and keeps the app's boundaries |
| 101 | +clearer. |
| 102 | + |
| 103 | +## 1.4.1: Deployment pod states, Service and Ingress detail |
| 104 | + |
| 105 | +[Aetheris 1.4.1](https://github.com/luminusOS/aetheris/releases/tag/v1.4.1) |
| 106 | +rounds out the object detail pane with information that was previously only |
| 107 | +one `kubectl describe` away. |
| 108 | + |
| 109 | +Opening a Deployment's Pods tab now shows a small styled summary counting its |
| 110 | +Pods by lifecycle phase — Running, Pending, Succeeded, Failed and Unknown — |
| 111 | +before you scroll down to the individual Pod list. It's a quick way to spot a |
| 112 | +Deployment that is stuck rolling out or has Pods crash-looping without reading |
| 113 | +every row. |
| 114 | + |
| 115 | +<figure> |
| 116 | + <img src="../../img/aetheris/aetheris-1-4-1-pod-states.png" alt="Aetheris 1.4.1 Deployment detail with the Pod states summary." loading="lazy" /> |
| 117 | + <figcaption>The Pod states summary on a Deployment's detail pane.</figcaption> |
| 118 | +</figure> |
| 119 | + |
| 120 | +Services and Ingresses also get proper sections in the detail pane now. |
| 121 | +Services show their ports (name, protocol, port, target port and node port |
| 122 | +where set) and their label selector, so you can see at a glance which Pods a |
| 123 | +Service actually routes to. Ingresses show their routing rules — host, path, |
| 124 | +path type, and the backing Service and port each rule points at. |
| 125 | + |
| 126 | +<figure> |
| 127 | + <img src="../../img/aetheris/aetheris-1-4-1-service-ingress.png" alt="Aetheris 1.4.1 Service ports and selectors, and Ingress routing rules, in the object detail pane." loading="lazy" /> |
| 128 | + <figcaption>Service ports/selectors and Ingress routing rules in the object detail pane.</figcaption> |
| 129 | +</figure> |
| 130 | + |
| 131 | +### Under the hood: a maintainability pass |
| 132 | + |
| 133 | +Alongside those features, 1.4.1 includes a purely internal refactor of the |
| 134 | +GTK4/Relm4 application layer, with no behavior change of its own. A handful of |
| 135 | +files had grown into single, multi-thousand-line modules mixing several |
| 136 | +responsibilities at once: message dispatch, application state, widget |
| 137 | +construction, YAML tooling, and streaming/terminal handling. Each of these was |
| 138 | +split into small, single-responsibility modules — the same pattern already |
| 139 | +used elsewhere in the codebase for the object detail view. Message handling, |
| 140 | +for instance, moved from one large dispatcher into one file per message domain |
| 141 | +(clusters, projects, namespaces, the object table, mutations, nodes, logs, |
| 142 | +terminals, port forwarding); application state and window construction were |
| 143 | +split the same way. |
| 144 | + |
| 145 | +That part of the release was verified against the full test suite, linted, |
| 146 | +and smoke-tested by running the app, and exists solely so future features and |
| 147 | +fixes land faster and with smaller, easier-to-review changes. |
| 148 | + |
| 149 | +## Acknowledgements |
| 150 | + |
| 151 | +Aetheris now explicitly credits |
| 152 | +[Seabird](https://github.com/getseabird/seabird), whose work helped inspire the |
| 153 | +project. Aetheris is still its own GNOME-native take on Kubernetes management, |
| 154 | +but it is important to acknowledge the tools and ideas that helped shape it. |
| 155 | + |
| 156 | +If you use Aetheris as a daily Kubernetes workspace, 1.4.0 and 1.4.1 together |
| 157 | +should make the app feel quicker when moving around, clearer when reading |
| 158 | +Deployment, Pod, Service and Ingress details, and more comfortable when you |
| 159 | +keep returning to the same objects. |
0 commit comments