Skip to main content

FAQ

Frequently asked questions about KubeVision.

What Kubernetes versions are supported?​

KubeVision requires Kubernetes 1.24 or later. The minimum version is set by the use of server-side apply and the stable apps/v1 API group. Most features work on any 1.24+ cluster; some features (e.g., dry-run diff via --dry-run=server) require a live API Server connection and may behave differently on very old patch releases.

Can I use KubeVision with managed Kubernetes services?​

Yes. KubeVision works with any cluster reachable via a standard kubeconfig or API token:

ProviderNotes
Amazon EKSUse aws eks update-kubeconfig to generate credentials
Google GKEUse gcloud container clusters get-credentials
Azure AKSUse az aks get-credentials
DigitalOcean DOKSUse doctl kubernetes cluster kubeconfig save
On-prem / bare metalAny cluster with a valid kubeconfig

How many clusters can KubeVision manage at once?​

There is no hard limit enforced in the code. KubeVision has been tested with 10+ clusters registered simultaneously. Each cluster gets its own Informer cache and WebSocket feed. Beyond 10–15 clusters, memory usage increases proportionally — plan for approximately 50–150 MB of extra memory per active cluster depending on resource count.

Is KubeVision production-ready?​

Yes, when deployed with PostgreSQL as the database backend. The SQLite default is intended for local development and single-user evaluation only.

Deployment modeSuitable for
SQLiteLocal dev, demos, single user
PostgreSQLProduction, multi-user, HA setups

For production deployments, also configure: a strong jwtSecret, TLS termination (ingress or load balancer), external PostgreSQL with backups, and 2FA enforcement for admin accounts.

Does KubeVision modify my cluster resources automatically?​

No. KubeVision never modifies cluster state without an explicit user action (clicking Apply, Delete, Scale, etc.). The backend does not run any background jobs that write to the cluster. Read-only operations (listing, watching, log streaming) generate no writes.

note

The one exception is the Informer cache, which opens a long-lived watch connection to the API Server. This is read-only and standard practice for Kubernetes controllers and dashboards alike.

What about Kubernetes RBAC? Does KubeVision respect it?​

KubeVision has two separate access control layers:

  1. KubeVision RBAC — Controls who can log in and what they can see within the dashboard (users, roles, cluster/namespace assignments).
  2. Kubernetes RBAC — The ServiceAccount or credentials used by the KubeVision backend to communicate with the cluster must have appropriate Kubernetes RBAC permissions.

KubeVision ships with a sample ClusterRole manifest in deploy/rbac.yaml that grants the minimum permissions needed for full dashboard functionality. You can scope it down further for read-only deployments.

How do I back up KubeVision?​

Two things need to be backed up:

1. The KubeVision database (user accounts, cluster registrations, audit log)
2. The kubeconfig files stored in the database (or on disk if using file-based import)

For PostgreSQL:

# Dump the database
pg_dump -U kubevision kubevision_db > kubevision_backup_$(date +%Y%m%d).sql

For SQLite (dev):

sqlite3 kubevision.db ".backup kubevision_backup_$(date +%Y%m%d).db"

Cluster kubeconfigs are stored encrypted in the database. A database backup is sufficient to restore all cluster connections.

Can I use SSO or OIDC for login?​

Yes. Administrators can configure standard OAuth or OIDC providers alongside local JWT login, TOTP, directory accounts, and passkeys. OIDC discovery uses the provider issuer; standard OAuth integrations can specify authorization, token, and user-info endpoints explicitly. See Authentication Providers.

Is there a hosted SaaS version of KubeVision?​

No. KubeVision is self-hosted only. There is no cloud-hosted version, no phone-home telemetry, and no license keys. The project is fully open source under the MIT License.

How does KubeVision perform with large clusters?​

KubeVision uses Kubernetes Informer caches to serve list and get requests. After the initial sync, all reads are served from in-process memory — no API Server calls are made for routine listing operations.

Cluster sizeBehavior
< 500 resources per typeFull informer sync at startup, instant queries
500 – 5,000 resourcesInformer cache holds all resources; startup sync takes a few seconds
> 5,000 resourcesConsider namespace-scoped informers (configurable) to limit memory

In benchmarks on a cluster with 3,000 pods across 50 namespaces, list-pods API calls return in under 5 ms from cache.

Still Have Questions?​