Using Sextant

Using Sextant

Contents: Resource tables · Saved views, favourites and workspaces · Command palette · Details · Related objects and the map · Changing things · The YAML editor · Change preview · Rollout history and rollback · Logs · Logs of several pods · Shells and the terminal · Shell on a node · Panes, snippets and broadcast · Debug containers · Copying files · Port forwarding · Metrics · Storage · Right-sizing · Cost · Problems and notifications · Security posture · Upgrade readiness · All clusters · Change timeline · Cleanup · Autoscaling · Network connectivity · Events · Gateway API · cert-manager and certificates · Permissions (RBAC) · Helm · Flux · Argo CD · Cluster icons and colors · Managing your kubeconfig · AI agents

Resource tables

The Sections tree on the left has a section per group of kinds:

Section	Contents
Cluster	Overview: nodes, pods and workloads by state, current CPU and memory, last-hour charts, warnings. Problems: everything that is red in the cluster on one page (see [[Problems and notifications
Nodes	Nodes
Workloads	Pods, Deployments, Daemon Sets, Stateful Sets, Replica Sets, Jobs, Cron Jobs, Right-sizing (see Right-sizing)
Config	Config Maps, Secrets, Resource Quotas, Limit Ranges, HPA, Pod Disruption Budgets, Priority Classes, TLS Certificates (the TLS Secrets of the namespaces in view by expiry)
Network	Services, Endpoints, Ingresses, Ingress Classes, Network Policies, Port Forwarding
Gateway API	Gateway Classes, Gateways, HTTP, GRPC, TLS, TCP and UDP Routes, Reference Grants, Backend TLS Policies, Policies, Request check; shown only when the cluster serves the Gateway API (see [[Gateway API
Storage	Persistent Volume Claims, Persistent Volumes, Storage Classes
Namespaces	Namespaces
Events	Events of the selected namespaces
Helm	Charts and Releases
Access Control	Service Accounts, Roles, Cluster Roles, Role Bindings, Cluster Role Bindings, Permissions (who can do what; see [[RBAC: who can do what
cert-manager	Certificates, Certificate Requests, Issuers, Cluster Issuers, Orders, Challenges; shown only when cert-manager is installed (see [[cert-manager and certificates
Trivy	Trivy Operator's reports (vulnerabilities, configuration audits, exposed secrets, RBAC and infrastructure assessments, compliance, SBOMs); shown only when Trivy Operator is installed (see [[Security posture
Flux, Argo CD	Their kinds, shown only when the tool is installed in the cluster (Sextant can install a missing one: see [[Installing Flux and Argo CD
Custom Resources	Every CRD of the cluster, with its resources

Tables update live through Kubernetes watches, so a pod that restarts or a deployment that rolls out changes in front of you, and they stay smooth with thousands of rows. Sextant handles clusters where you can list only some namespaces: it shows what you may see and says where permission is missing.

• Namespaces: the selector at the top right filters by one or several namespaces ("All namespaces" by default).
• Search: type a name, a namespace, or a label such as app=web.
• Sort: click a column header.
• Columns come from the kind; for custom resources they come from the CRD's additionalPrinterColumns. CPU and memory columns appear in the pod and node tables when metrics are available (see Metrics).
• Row actions: the ⋮ button on a row opens the actions for that kind. Tick rows to act on several at once (for example delete).

Custom resources, including ones installed after you connected (Flux, Argo CD, any operator), show up without reconnecting.

Saved views, favourites and workspaces

Set a table up — namespaces, search, Only problems, a label selector, sort, the columns shown (the Columns menu in the header) — and press Save view in its header to keep it under a name, for this cluster or for all clusters. Saved views and pinned objects (Pin to favourites in any object's actions) appear above the sections and in the command palette. A workspace ("prod", "staging") shows only its clusters in the rail; switching it never connects or disconnects anything. Export… and Import… move them to another computer: clusters are named by kubeconfig path and context only, and credentials, tokens and extensions are never exported. See Views and workspaces.

Command palette

Press Ctrl+K (Cmd+K on macOS) anywhere to open the command palette. Inside a text field, a terminal or the YAML editor, Ctrl+K belongs to them, so there use Ctrl+Shift+K (Cmd+Shift+K). Press the shortcut again or Esc to close it.

• Saved views and Favourites: your views and pins (of the open cluster, or of the workspace's clusters when none is open).
• Go to: sections and pages of the open cluster (for example pods, problems, port forwarding), Settings tabs, and other clusters (switch to a connected one, or connect it).
• Find objects by name: start typing and the palette lists matching objects of the open cluster, grouped by kind. It searches the common kinds (pods, workloads, jobs, services, ingresses, config maps, secrets, nodes, namespaces, volume claims, Gateways and HTTPRoutes, Flux and Argo CD objects) and the kind of the table you have open. To search another kind, start with its name or short name: cm web, deploy api, crd: (a colon works too). Search all kinds searches every kind the cluster has. Kinds you may not list are skipped.
• Act on an object: Enter opens its details; Tab lists its actions (Logs, Shell, Restart, Delete…), and running one asks the same confirmation as the button would. Shift+Tab goes back.

The palette reads only names, namespaces and labels, never specs or Secret values, and only after you type the first character. Recent choices are offered first.

Details

Click an object to open the details panel on the right: metadata (labels, annotations, owners), fields specific to the kind (a pod's containers, a service's ports, a node's capacity, an ingress's rules...), conditions, events and the YAML. References are links: from a pod to its owner, node, service account and volumes, and from a node, a service or a volume back. Pods with several containers show one container at a time, init containers first and marked, and their requests and limits next to current usage.

Every object also has a Related tab: what would break if it were deleted, and the objects it uses and that use it (see Related objects and the map).

At the top of the panel are the actions for the object: Logs, Shell (on a pod, or on a node: see Shell on a node), Port forward…, Edit, Delete and whatever else applies (Scale, Restart, Cordon, Drain, Trigger, Suspend).

Secrets show their keys but not their values. A value is read from the cluster only when you press Show next to a key, and hidden again with Hide. The same applies to the YAML view of a Secret. Sextant does not keep Secret values in the table or in the watch.

A TLS Secret also shows its Certificate: names, issuer, validity and days left, key, fingerprint and chain, read by Sextant's backend without the private key ever reaching the window (see cert-manager and certificates).

Related objects and the map

The Related tab in every object's details starts with If it is deleted: what would be deleted with it, what would create it again, and what would fail ("3 pods mount it: restarted or new ones will fail to start", "1 route sends traffic to it"). Below are the related objects one hop both ways, grouped ("Owned by", "Mounted by", "Selects", "Sends traffic to"…), each coloured by health; open one, or expand it to follow the chain further.

Cluster → Map draws the objects of up to three namespaces of the namespace filter, from routes and Ingresses through Services, workloads and pods to their configuration and claims, coloured like the Problems page; large groups such as "42 pods" expand on a click. See Resource map.

Changing things

Action	Where	Notes
Edit	Details panel, row menu	Opens the object's YAML in a dock tab. Save checks for conflicts: if someone changed the object after you opened it, nothing is saved and you can Reload to get the current version. Preview changes shows what the API server would store first (see Change preview).
Create resource	+ in the dock's bar	Paste or type YAML; several objects can be separated by ---. Apply uses server-side apply and lists what was applied. Preview changes shows what each document would do first.
Delete	Details panel, row menu, several rows	Asks for confirmation and names what will be deleted.
Scale	Deployments, Stateful Sets, Replica Sets	Sets the replica count.
Restart	Deployments, Stateful Sets, Daemon Sets	Rollout restart.
Roll back…	Deployments, Stateful Sets, Daemon Sets	Goes back to an earlier revision of the pod template, like kubectl rollout undo. See Rollout history and rollback.
Cordon / Uncordon	Nodes	Marks the node unschedulable, or schedulable again.
Drain	Nodes	Shows a preview first: pods to evict, pods without a controller, pods with emptyDir data and DaemonSet pods that stay. Pods without a controller and with emptyDir data are touched only if you tick force and delete emptyDir data. Behaves like kubectl drain.
Trigger now, Suspend / Resume	Cron Jobs	Starts a Job from the CronJob's template; pauses or resumes the schedule.

Changes made through Sextant are marked with the field manager sextant.

The YAML editor

In Edit and Create resource the editor knows each kind's fields from the cluster's own schema: it completes field names and allowed values (Ctrl+Space), underlines unknown fields, wrong types, missing required fields and values that are not allowed, shows a field's documentation on hover, and F1 opens Explain, like kubectl explain. It works for custom resources too, and stays a plain editor when the cluster publishes no schema. See YAML editor.

Change preview

Preview changes in the editor, in Create resource and in the Helm Edit values and Install dialogs shows what the API server would store, next to the live object, from a server-side dry run: defaults, admission webhooks and validation included, nothing changed. Each object is marked New, Changed, Unchanged or Refused; Secret values are never shown, only which keys would change. For Helm the release's current manifest is compared with the one Helm would apply. A cluster can ask for the preview before every such change (Preview changes before applying in its settings, on by default for clusters named like production). See Safe apply.

Rollout history and rollback

Deployments, Stateful Sets and Daemon Sets have a History tab in their details:

• Rollout: whether the rollout is Complete, Progressing, Paused or Stuck (with the reason Kubernetes gives), and how many replicas are updated, ready and available.
• Revisions: each revision with its number, when it was created, its change cause (the kubernetes.io/change-cause annotation) and its images; the current one is marked. Sextant reads them from the ReplicaSets (Deployments) or ControllerRevisions (Stateful Sets, Daemon Sets) the workload owns, as kubectl does.
• Compare: tick two revisions to see their pod templates side by side, with the differences highlighted.
• Roll back to revision N: opens a confirmation that shows the current template next to the one you are going back to. Roll back… in the action bar and the row menu does the same and offers the revision before the current one first.

A rollback changes exactly what kubectl rollout undo --to-revision=N changes: the pod template (and, for a Deployment, the annotations kubectl copies from the ReplicaSet). The pods are then replaced as for any update, and the result gets a new revision number. A paused Deployment has to be resumed first; when the chosen revision already matches what runs, there is nothing to change and Sextant says so. Revisions Kubernetes already pruned (revisionHistoryLimit) are not listed.

Logs

Press Logs on a pod (or on a workload, then choose a pod) to open a tab in the dock. The toolbar has the container choice (init containers are marked), Follow, Timestamps, Previous container (the log of the container before its last restart), Wrap lines, Save to a file and Reconnect. The search box highlights matches and jumps between them. Streaming starts immediately; Sextant keeps the newest 100,000 lines in a tab and tells you if older ones were dropped.

Logs of several pods

One tab can follow the logs of many pods at once, each line prefixed with its pod and container in a colour that stays the same for that pod:

• All pods of a workload or a Service: the Logs block in the details of a Deployment, Stateful Set, Daemon Set, Replica Set, Job or Service has Logs of all pods; Logs on a workload also offers All pods next to the list of pods. Pods that appear later (a rollout, a scale-up) are picked up, deleted ones are marked "pod gone", and a restarted container gets a new stream.
• Selected pods: tick several pods in the Pods table and press Logs. Several workloads ticked open one merged tab each.
• Another label selector: a tab opened for a workload or a Service has a Selector field; change it to any selector of that namespace, such as app=web,tier!=cache, and press Enter.

The tab has a list of pods and containers to tick (at most 20 streams run at once; the others wait, and the tab says how many), a Filter with an optional Regex, Parse JSON with a Level filter (for example "WARN and above") for structured logs, and the usual Timestamps, Previous container, Wrap lines and Save. The newest 100,000 lines of all pods together are kept.

Shells and the terminal

• Shell on a pod opens an interactive terminal in a container (you choose the container if there are several). Sextant tries bash and falls back to sh.
• Terminal in the dock's bar opens a local terminal on your computer: your $SHELL on Linux and macOS, PowerShell on Windows. kubectl in it already points at the selected cluster, because Sextant gives the shell a private single-context kubeconfig. If your shell profile exports its own KUBECONFIG, it can win; check with kubectl config current-context before changing anything.

Terminal tabs end when you disconnect the cluster or close the window.

Shell on a node

Shell on a node (in the details of a node, or in the ⋮ menu of its row in the Nodes table) opens a shell on the node itself, as Lens does. It works by running a temporary privileged pod on that node, so Sextant asks first: "Sextant will create a privileged pod on node in kube-system. It is deleted when you close the shell." Press Open to go on. The shell opens in a dock tab titled "Node: "; its shell is the node's bash, or sh if the node has no bash. Reconnect in that tab asks again and makes a new pod.

What Sextant creates in the cluster:

• one pod named sextant-node-shell-<node>-<random> in the kube-system namespace, pinned to the node (nodeName), tolerating every taint, with hostPID, hostNetwork and a privileged container. Its first process enters the node's namespaces (nsenter -t 1 …), and the shell you get joins them, so you see the node's processes, network and file system. It does not mount a service account token.
• the labels app.kubernetes.io/managed-by=sextant and sextant.dev/node-shell=true, plus sextant.dev/session (one value per run of Sextant) and sextant.dev/owner (a hash of your OS user name and the computer's name, so the names themselves never reach the cluster).
• an activeDeadlineSeconds of 8 hours, so the cluster ends the pod by itself even if Sextant cannot.

Permissions. You need to be allowed to create pods in kube-system, and the namespace must admit privileged pods: a cluster whose Pod Security admission enforces baseline or restricted there refuses them (see Troubleshooting). The pod uses the image set in Settings → Terminal → Node shell image (default busybox:stable; it must contain nsenter).

When the pod goes away. Sextant deletes it when you close the tab, disconnect the cluster or quit Sextant (quitting waits a few seconds for the deletions to be answered). A shell closed while its pod is still starting leaves nothing behind either. As a safety net, whenever you connect a cluster Sextant deletes node shell pods of your user left over from earlier runs (for example after a crash), and anyone's node shell pods older than 8 hours; a colleague's live shell is never touched. Only pods in kube-system carrying both Sextant labels are ever deleted.

If the pod does not become Running within 60 seconds (the image cannot be pulled, the node is full), Sextant deletes it and shows the reason from the pod's events.

AI agents never get a node shell. The MCP server cannot open one, and it refuses to run commands in a node shell pod whatever the cluster's access rules say. See MCP server.

Panes, snippets and broadcast

• Split right / Split down in a terminal tab's bar opens another shell beside the current one — the same kind, a local terminal, a container, a node or a debug container — up to 8 panes per tab. Ctrl+Shift+Arrow moves between panes; drag the divider to resize. Each pane is its own shell.
• Snippets types a saved command into the focused pane: Insert without Enter, Run with it. {{namespace}}, {{pod}}, {{container}}, {{cluster}} and {{context}} are filled from the pane and quoted for its shell.
• Broadcast… sends what you type to several panes you tick (at least two). Your first keystroke asks for a confirmation, and what you typed before confirming is not sent anywhere; panes of other clusters are listed apart.

See Terminal.

Debug containers

Many images have no shell (distroless, scratch), and a container that crashes on start cannot be entered at all. Debug starts a debug container with a shell and tools next to it, as kubectl debug does. It is in the header of each container in a pod's details, and in the toolbar of a container's shell tab.

The dialog asks:

• Image: busybox:stable (default) or nicolaka/netshoot:latest (network tools), or any image you type. Use this image by default remembers it.
• Container to debug: the debug container sees this container's processes (shared process namespace), so ps shows them and /proc/<pid>/root reaches its files. None shares nothing.
• Where:
  • An ephemeral container in this pod: added to the running pod. It needs permission to update pods/ephemeralcontainers. Kubernetes never removes an ephemeral container: when you close the tab Sextant ends its shell, but the container stays in the pod (stopped) until the pod is deleted. Starting another one adds another; Reconnect asks first.
  • A copy of the pod: Sextant creates <pod>-debug-<random> in the same namespace with the same containers plus the debug container, and Command of the container in the copy can replace the debugged container's command, for example sleep infinity to keep a crashing container alive. The copy has none of the original's labels, so no Service sends it traffic and no controller adopts it; its probes are removed, and it may land on another node.

The shell opens in a dock tab ("Debug: " or "Debug copy: "). Nothing is created before Start.

When the copy goes away. Sextant deletes it when you close the tab, disconnect the cluster or quit Sextant. As a safety net it has an 8-hour deadline, and starting a new copy in a namespace first deletes your copies left there by earlier runs (for example after a crash) and anyone's older than 8 hours; a colleague's live copy is never touched. Copies carry the labels app.kubernetes.io/managed-by=sextant and sextant.dev/debug-copy=true, plus sextant.dev/debug-session and sextant.dev/debug-owner (a hash of your OS user and computer, not the names).

If the image cannot be pulled or the container does not run within 2 minutes, Sextant shows the reason (and deletes a copy). AI agents and extensions cannot start debug containers, and an agent cannot run commands in a debug copy whatever its rules say (see MCP server).

Copying files to and from a container

Files (next to Debug in a running container's header, and in its shell tab) copies files like kubectl cp. It runs tar in the container, so the container needs tar; if it has none, Sextant says so (a debug container or another image is the way out).

• Download: type a path in the container and press Download…. Sextant checks what it is first. A file is saved as it is; a folder is saved as a .tar.gz archive (Sextant never unpacks it on your computer); a symbolic link is not followed: download the path it points to. Choose where to save it. The file appears under its name only when the download has finished; until then it is a hidden .sextant-download-….part file in the same folder, and a cancelled or failed download leaves nothing behind and does not touch an existing file.
• Upload: Choose file…, type the full path in the container (its folder must exist) and press Upload. Sextant asks first, because this changes the running container and replaces a file already there. A cancelled or failed upload can leave a partly written file in the container.

Both show progress (bytes, and a percentage when the size is known) and can be cancelled. A transfer stops when you disconnect the cluster or quit Sextant. Only regular files are uploaded, one at a time. AI agents and extensions cannot copy files.

Port forwarding

Port forward… on a pod or service opens a dialog: choose the port to forward and a local port (a random free one, or a specific one). Active forwards are listed on the Port Forwarding page (under Network) with Open in browser and Stop, and in the details of the object. Forwards listen only on 127.0.0.1, and they stop when you disconnect the cluster or quit Sextant. If the local port is taken, Sextant says so and offers a free one.

Metrics

• Current CPU and memory come from metrics-server, or from Prometheus when metrics-server is not there, and show in the pod and node tables and in details, next to requests and limits.
• Last-hour charts (CPU, memory, pods, disk) in the cluster overview and in details come from Prometheus.

Sextant finds Prometheus in the cluster automatically. If yours is somewhere else, or you want a particular source for the current values, set it in the cluster's settings (see Settings). Without any source, metrics columns show n/a and a hint to open the cluster settings.

Storage

The Persistent Volume Claims table has a Usage column, and claims and pods show how full each volume is (space and inodes), from the kubelets or Prometheus. Disk almost full can warn you on the Problems page and by notification (off until you turn it on). With the snapshot CRDs or Velero installed, the Volume Snapshots and Velero sections explain their objects, and Create snapshot…, Restore to a new PVC…, Back up namespace… and Restore from this backup… create one new object each after you review it — never changing an existing one. See Storage.

Right-sizing

Workloads → Right-sizing compares each container's requests and limits with its usage over the last day or 7 days from Prometheus and suggests new values, with findings such as CPU over-provisioned, Memory near limit or OOMKilled recently; Copy resources YAML copies the suggestion. Deployments, Stateful Sets, Daemon Sets and pods show the same in their details. Nothing is changed in the cluster. See Right-sizing.

Cost

With OpenCost or Kubecost in the cluster, Cluster → Cost shows what each namespace, workload, Pod, node or label value cost over the last 24 hours, 7 or 30 days, split by resource, with the idle cost; Deployments, Stateful Sets and Daemon Sets show their cost, a monthly estimate and the estimated savings of their right-sizing recommendation. Read-only, through the API server; Sextant does not install either product. See Cost.

Problems and notifications

The Problems page in the Cluster section lists everything that is red in the cluster, and Sextant can tell you with a desktop notification when something starts to fail. Notifications can be turned off completely, per kind of problem, per cluster or for an hour. See Problems and notifications.

Security posture

Cluster → Security checks the workloads of the namespaces you choose against the Pod Security Standards (Baseline and Restricted), with the field that fails, its value and a fix to copy, and says what each namespace's Pod Security labels would reject. Workloads and pods have a Security section in their details; with Trivy Operator installed, the Trivy section and Image scans (Trivy) show its reports. Baseline violations can be turned on as a problem category. See Security posture.

Upgrade readiness

Cluster → Upgrade readiness lists, for a target Kubernetes version, the deprecated and removed API versions your objects, Helm releases, Argo CD applications and Flux Kustomizations still use, the deprecated versions the cluster still serves, and version skew problems, and copies the report as Markdown or CSV. See Upgrade readiness.

All clusters

All clusters at the top of the cluster rail shows up to 10 clusters on one page: a health card each, pods, workloads and Warning events across them, and Find by name in all of them. It connects a cluster only when you click Connect. See All clusters.

Change timeline

Cluster → Timeline lists what changed in the chosen namespaces — field by field, when, and which program made it (its field manager) — with the problems and Warning events that began soon after each change; every object has a Changes tab with its own. Sextant records changes of the objects its open views watch, without extra watches; what happened before it was running comes from what the cluster keeps (field managers, rollout revisions, Helm revisions) and is marked Partial. Secret values are never recorded, and the timeline is kept between restarts only if you tick Keep between restarts. See Change timeline.

Cleanup

Cluster → Cleanup lists objects that look unused or left over — claims no Pod mounts, Released volumes, Services without endpoints, old ReplicaSets, finished Pods and Jobs, empty namespaces, and, only if you turn them on, ConfigMaps and Secrets nothing refers to — with the reason and what deleting each would touch. Delete selected lists every object, checks each one again right before deleting it and deletes it only if it is still the object you confirmed. When in doubt, an object is not offered; the page explains what it never offers and why. See Cleanup.

Autoscaling

A HorizontalPodAutoscaler's details explain its Scaling decision: each metric against its target and the replicas it asks for by the controller's formula, what holds it (tolerance, maxReplicas, a behavior policy, stabilization, a missing metric or request), in plain words. A Pending pod gets Why the Pod is not scheduled (the scheduler's message, a check against each node, and what Karpenter or Cluster Autoscaler did); nodes, NodePools and NodeClaims show Karpenter's and Cluster Autoscaler's decisions; KEDA and Karpenter get sidebar sections when installed. See Autoscaling.

Network connectivity

Network → Connectivity answers "can this pod reach that pod (or Service, or address) on this port?" from the cluster's NetworkPolicies and Cilium and Calico policies, with the policy and rule that decide each side, a DNS check and a per-namespace policy map. What the objects cannot decide is Unknown, never Allowed. Policies have an In plain words section and pods a Network policies section. See Connectivity.

Events

The Events page lists events of the selected namespaces with type, reason, message, involved object, source, count and last-seen time, and has a search box. Each object's details panel also shows its own events.

Gateway API

When the cluster serves the Gateway API, a Gateway API section lists Gateway classes, Gateways, routes, ReferenceGrants and policies, with a problem counter and an Only problems filter. Details explain broken listeners and routes in plain words and offer the ReferenceGrant a cross-namespace reference needs; a Gateway has a Topology tab; Request check shows where a request would go and why. Services, TLS Secrets and policy targets show the Gateways and routes that use them. See Gateway API.

cert-manager and certificates

When cert-manager is installed, a cert-manager section lists Certificates, Certificate Requests, Issuers, Cluster Issuers, Orders and Challenges with their readiness explained in plain words, and the details show the issuance chain Certificate → Certificate Request → Order → Challenge. Any TLS Secret shows its certificate, and Config → TLS Certificates lists the TLS Secrets of the namespaces in view, the soonest to expire first. How many days ahead a certificate counts as expiring is a setting (14 by default). See cert-manager and certificates.

Permissions (RBAC)

Access Control → Permissions shows what a user, group or service account may do (a verbs × resources matrix that names the binding and rule behind every cell), who can do a given action, and Can I, answered by the API server for you. Roles, bindings and service accounts explain their rules and grants in their details. See RBAC: who can do what.

Helm

Sextant reads Helm releases straight from the cluster, so you can look at them without Helm installed. Changing them uses the helm program (see Installation and Settings → Helm).

• Releases (under Helm): name, namespace, chart, version, app version, status, updated. Open a release to see its Values, Manifest, Notes and History. Values and manifest are hidden until you press the eye button, because they may contain secrets.
• Edit values upgrades the release with new values (Preview changes shows what would change first, see Change preview); Roll back returns to an earlier revision; Uninstall removes the release and everything it created. Uninstall asks you to type the release name.
• Charts (under Helm): add chart repositories (with an optional user name and password), update them, search charts, read a chart's default values and Install it into a namespace with your values.

Flux

When Flux is installed, a Flux section lists its sources (Git, OCI and Helm repositories, Helm charts, buckets), Kustomizations, Helm Releases, image automation objects and notification objects, all through the Kubernetes API (no flux CLI needed). Details show readiness, the revision, the source, the objects a Kustomization applied, and who uses a source.

Actions: Reconcile now, Reconcile with source (reconciles the source first, then the object), Suspend and Resume.

Flux is not in the cluster? Right-click the cluster and choose Install Flux…: see Installing Flux and Argo CD.

Argo CD

When Argo CD is installed, an Argo CD section lists Applications, ApplicationSets and AppProjects. An Application's details show sync status and health, source, destination, sync policy, the tree of its resources (managed objects and what they own, as links) and the sync history.

Actions: Sync… (revision, prune, dry run), Refresh, Hard refresh, Terminate… (stop a running sync), Diff and Open Argo CD UI (opens the Argo CD web interface in your browser through a port forward).

Diff shows, per resource, what Argo CD would apply next to what is in the cluster. It needs a session in Argo CD's API, which Sextant opens through a port forward to argocd-server. Sextant looks for credentials in this order: the login you saved, the admin password in argocd-initial-admin-secret, an API token in a Secret labelled app.kubernetes.io/part-of=argocd with a token key, and finally asks you for a user and password or an API token. Remember on this computer saves the login in your system keychain. Single sign-on through the browser is not supported. Argo CD passwords and tokens stay in Sextant's backend and are not logged; Secret values in the diff are hidden.

Argo CD is not in the cluster? Right-click the cluster and choose Install Argo CD…: see Installing Flux and Argo CD; Sextant then signs in with the initial admin secret by itself.

Cluster icons and colors

Each cluster has an icon and a color in the cluster rail. The default is a color with the initials of the cluster name. In the cluster's settings (right-click the cluster → Settings, or Change icon…) you can set a display name, a color label, one or two letters or an emoji, or a picture (PNG, JPEG, SVG or WebP, up to 5 MB). Reset icon returns to the initials. The button at the bottom of the rail widens it to show cluster names.

Managing your kubeconfig

Right-click a cluster for Rename context…, Set default namespace…, Duplicate with namespace… and Delete context…; Settings → Clusters → Kubeconfig has Merge files…. Each change is previewed, written only after you confirm, with a backup of the file and an atomic write, and only to files you allowed with Allow Sextant to edit (Sextant's own files always). A badge on a cluster's icon warns when its client certificate or token expires soon. See Kubeconfig management.

AI agents

Sextant can serve your clusters to AI agents such as Claude Code, Claude Desktop and Cursor, with permissions you set per cluster. See MCP server. The server runs only while Sextant does; to keep it running with the window closed, turn on Settings → Window → Closing the window keeps Sextant in the tray (see Settings).

Next: Settings, Troubleshooting.