Skip to content
Spinoza

v1 is live

The Kubernetes BFG.

A Kubernetes IDE with GitOps at its core. One binary for your machine or cluster. Run it locally in a browser tab or desktop app, or serve one cluster to a team in preview cluster mode.

curl -fsSL https://spinoza.tech/install.sh | sh
Verifies sha256 · macOS and Linux1,437 release downloadsCounted from GitHub release assets across 45 releases on 9 September 2026. Package managers and source builds are not counted.Direct downloads
1
binary,UI included
2
local interfaces,browser + desktop
$0
per seat
0
vendor accountsto create

Why the name

Baruch Spinoza, a 17th-century philosopher, was also known for making lenses.

127.0.0.1:34115 · Spinoza · Borg theme

Spinoza cluster overview: Kubernetes version, node and pod tiles, allocatable CPU and memory against live usage, and the newest warning events

Spinoza cluster overview: Kubernetes version, node and pod tiles, allocatable CPU and memory against live usage, and the newest warning events

What it does

Browse, inspect, operate and audit the live cluster.

  • See the cluster first

    Version, node readiness, allocatable capacity against live usage, pods by phase and recent warning events in one overview.

  • Browse every resource type

    Discovery supplies the tables, so CRDs appear without a plugin. Filter on live fields, choose namespaces, add columns from fields or labels, and act on a selection.

  • Inspect and edit the live object

    Metadata, conditions, events and YAML in one drawer. Monaco completes from the cluster's OpenAPI, and changes go back through server-side apply.

  • Operate workloads

    Scale, restart, suspend or trigger a CronJob, cordon a node, or review a drain plan before moving its pods. Protected clusters require their name before destructive work.

  • Work with Helm releases

    Read releases from Helm storage, search configured repositories and OCI registries, install behind a dry run, preview an upgrade as a manifest diff, then roll back or uninstall.

  • Turn findings into a work list

    128 checks cover security, reliability and waste. The view leads with the findings; scope, baselines, muted rules and export sit behind one Configure control. Issues rank live failures and clear as the cluster recovers.

  • Open a shell, logs or a forward

    Exec into a container, add an ephemeral debug container to a distroless image, stream logs, or forward a pod or service to your machine without leaving the view.

  • See metrics and relationships

    Live CPU and memory sit in the tables. Prometheus supplies history, topology draws ownership and routing edges, and Cilium Hubble can supply the traffic graph.

  • Keep several clusters open

    Each open cluster is a tab in one strip, keeping its own state, health and history, with a control beside them to open another. The header names the one you are working in. Opening a cluster says how long it will wait and lets you stop, and if one is already open it asks whether to replace that tab or keep both. Fleet views combine checks, issues, search, Helm releases and GitOps across every open cluster.

  • Notice when a cluster goes quiet

    A banner names the cluster, how long it has been silent and why: timed out, connection refused, certificate not trusted. The rows you already had stay on screen, marked with when they were read, and one control reconnects.

  • Compare what you authored

    Diff one object or a whole resource type across two clusters. Status, managedFields and cluster-assigned spec fields are removed before the comparison.

  • One cluster, shared

    Preview cluster mode serves one cluster to a team from the same binary and Helm chart. Sign in through OIDC or an authenticated proxy; Spinoza applies its roles and Kubernetes RBAC.

Every capability, group by group · local and cluster modes

GitOps

GitOps you can see.

Flux and Argo CD get dedicated views, not a generic custom-resource table. Follow the dependency graph, inspect each controller object, reconcile or suspend Flux resources, and sync or refresh Argo Applications. A Flux-owned Helm release links back to its source instead of offering an upgrade that Flux would revert.

  • Dependency DAG
  • Reconcile / suspend / resume
  • Flux ownership guardrail
  • Argo sync and refresh

The dependency graph, laid out by what manages what. Clicking a node opens it in the inspect drawer.

Spinoza GitOps dependency graph: sources, Kustomizations and HelmReleases with the edges that manage and depend on each other

Cluster sync from the repository, controller health, and every applier and source with its ready count.

Spinoza Flux overview: all systems operational, cluster sync from a GitRepository, controller health, and counts for appliers, sources and image automation
Cluster sync from the repository, controller health, and every applier and source with its ready count.

128 checks decided against the live cluster, not a parsed manifest. Each rule carries its framework label, its severity and the objects that tripped it.

Spinoza cluster checks: 709 findings across 35 workloads, each rule labelled PSS baseline or NSA/CISA, with a severity and a finding count per rule, and one Configure control for scope, baseline and imports
128 checks decided against the live cluster, not a parsed manifest. Each rule carries its framework label, its severity and the objects that tripped it.

A queue of what is broken now, ranked and self-clearing as the cluster recovers.

Spinoza issues view: what is broken in the cluster right now, ranked, with the reason for each failing workload
A queue of what is broken now, ranked and self-clearing as the cluster recovers.

Open the graph around one object and it draws what owns it, what it owns and what configures it. The whole cluster is one click away.

Spinoza topology graph rooted on one Deployment: the namespace that owns it, the ReplicaSet it owns, and the ConfigMap that configures its pods, with the object's own panel open beside it
Open the graph around one object and it draws what owns it, what it owns and what configures it. The whole cluster is one click away.

Two clusters open as tabs, each keeping its own state. The compare panel pairs an object, or a whole kind, against the other one.

Spinoza with two clusters open as tabs, a ConfigMap selected, and the compare panel docked below showing the lines that differ against the second cluster side by side
Two clusters open as tabs, each keeping its own state. The compare panel pairs an object, or a whole kind, against the other one.

Every change Spinoza made, kept per cluster, so you can see what you did and when.

Spinoza history view: a record of the changes Spinoza itself made to the cluster, with what changed and when
Every change Spinoza made, kept per cluster, so you can see what you did and when.

Every release read without a helm binary, with a newer chart flagged beside the one installed.

Spinoza Helm releases read straight from the cluster: chart and app versions, the newest chart available, revision, status and when each was last updated
Every release read without a helm binary, with a newer chart flagged beside the one installed.

Live YAML in Monaco with schema-aware editing, applied server-side from the same drawer.

Spinoza ConfigMap resources table with the inspector open on the object's live YAML in Monaco, with apply, revert and delete
Live YAML in Monaco with schema-aware editing, applied server-side from the same drawer.

Every pod with live CPU, restarts and container health. What narrows the view — scope, filter, columns — sits in one row above every table.

Spinoza pod resources: every pod across all namespaces with its containers, status, restarts, node and live CPU, the filter and column picker in one row above the table
Every pod with live CPU, restarts and container health. What narrows the view — scope, filter, columns — sits in one row above every table.

Ports on the inspect Overview. Forward one to localhost, open it, stop it. Forwards survive navigation.

Spinoza pods table with the inspector open on a running pod: its container port forwarded to a local port with open and stop controls, and the forward listed in the dock below
Ports on the inspect Overview. Forward one to localhost, open it, stop it. Forwards survive navigation.

Drain plans first. It counts what it would evict, leave and block, names the reason for each, and keeps the button disabled until you accept the blocked pods.

Spinoza drain plan for a node: how many pods it would evict, leave in place and block, the reason for each, and the drain button disabled behind a checkbox
Drain plans first. It counts what it would evict, leave and block, names the reason for each, and keeps the button disabled until you accept the blocked pods.

Point it at a whole kind and it pairs every object across both clusters: same, differs with a line count, or present on only one side.

Spinoza comparing every ConfigMap in a namespace across two clusters: a verdict per object with the number of lines that differ
Point it at a whole kind and it pairs every object across both clusters: same, differs with a line count, or present on only one side.

Select a release and its detail docks below as a panel you can drag to any side: values, notes, the rendered manifest, its history, and every object it put in the cluster.

Spinoza Helm releases with one release selected and its detail docked below, listing the ConfigMap and Deployment the chart rendered, alongside upgrade and uninstall
Select a release and its detail docks below as a panel you can drag to any side: values, notes, the rendered manifest, its history, and every object it put in the cluster.

Install it and point it at a cluster.

curl -fsSL https://spinoza.tech/install.sh | sh
macOS, Linux and Windows, on arm64 and amd64. install.sh covers macOS and Linux, install.ps1 covers Windows, and each installs the desktop app too where one is published.Windows, pinned releases and archives