GitOps puts the desired state in Git and lets a controller reconcile it. That is a useful boundary, but it can make the operational question feel indirect: is the source available, is the desired revision applied, and why is one object healthy while another is not?
Vastanex brings the status signals into one read-oriented surface. GitOps is discovery-gated, so the entries appear when the cluster serves the supported Argo CD or Flux resources. The app normalizes the controller signals into plain-language status while keeping the raw values available for investigation.
See the source and controller rows together
The overview is deliberately small enough to scan. In the local fixture it shows an Argo Application named web, a Flux GitRepository named platform, a Flux Kustomization named platform and a Flux HelmRelease named web.
Those rows answer different parts of the same question. The repository row tells you that a source artifact is available. The Kustomization row reports a successful reconciliation signal. The Application row is out of sync and degraded. The HelmRelease row is stalled. Keeping all four visible makes it easier to distinguish “the source is available” from “the declared workload is healthy.”
The wording is not a replacement for the controller’s vocabulary. Raw states such as OutOfSync, Degraded and the controller condition remain near the plain explanation. That gives a new operator a sentence to start with and an experienced operator the exact term to search for in controller documentation.
Open the failed object for its own evidence
Status summaries are useful only when they lead to the evidence behind them. Expand Product details on the failed Argo row. The application keeps its health, sync and operation signals together, including the failed operation message from the fixture.
The source URL in the fixture contains credential-shaped material, but the view redacts it. The visible result keeps the safe repository context without putting a token or query secret in the page. That is the same product boundary used elsewhere: status can be useful without making credentials part of the renderer’s evidence.
The row’s next step is a prompt for investigation, not an automatic sync. Check the controller’s own detail surface, Events or the relevant workload before deciding what to do. The app can show the signal it received; it cannot know the intent behind a change in Git.
Request a controller action deliberately
Sometimes you need to ask a controller to refresh or reconcile after you have understood the status. Vastanex treats that as a separate, guarded action. Allow changes is off by default. The request is also checked against the cluster permissions and presented in a confirmation dialog that describes the boundary.
For Argo CD, the product-specific request writes only the normal refresh annotation. For Flux, it writes the requested-at reconciliation marker. These are API requests to the controller; they are not edits to Git, forced syncs or bulk operations.
The screenshot keeps the Argo dialog open but cancelled. That is intentional: a proof image should show the consequence before a request is sent, while the local fixture stays unchanged. If a real request is confirmed, a success toast means the API request was accepted. It does not mean the controller has reconciled the desired state or that a rollout finished.
What it does not do
Vastanex does not edit Git, bypass a controller, force a sync or claim that a request was reconciled. It does not provide a full Argo CD or Flux replacement, and the supported status surface is bounded to the discovered resource kinds and fields.
The website’s four-row example is a local fixture. The URLs and credential-shaped values are fake, and the absence of a row can simply mean that its CRD is not served. A controller request remains subject to read-only mode, RBAC and confirmation. Investigate the controller and the workload before treating its status as a completed deployment.
Start with the Download page to see the current desktop availability, then compare this controller-aware view with Kubernetes workload relationships or a server-side YAML dry-run.