Repository-backed model
The visual editor and supported artifact generators are traceable to code and automated tests.
Open Source · AGPL-3.0 · Self-hosted
Design Kubernetes namespaces visually. Export YAML or Helm for review.
IzyKube helps small platform teams and Kubernetes consultancies model supported resources on a visual canvas, then generate artifacts they can review and use in their existing Git workflow. It complements kubectl and your delivery tools.
From diagram to artifacts
Generate YAML or a Helm archive for resource types covered by the current model and tests.
Self-hosted integration
Run the application locally and connect it to third-party components such as Kubernetes, MongoDB, and Ollama.
What is present today
Move from a namespace design to artifacts your team can review
Model supported Kubernetes resources visually, generate YAML or Helm, then review and deliver the output with the Git and deployment tools your team already uses. Direct cluster operations and inspection have partial end-to-end verification.
Common split workflow
- Architecture diagrams are maintained separately
- Kubernetes manifests are authored in another tool
- Teams need a shared view of supported resources and their relationships
- Generated artifacts still need normal code review and delivery controls
With IzyKube
- A visual model feeds supported artifact generators
- YAML and Helm export paths have automated tests
- Use exported artifacts in your existing Git review and deployment process
- Implemented, partial, planned, and external items are called out separately
Core features
Implemented and partially verified product paths
The labels below are deliberately scoped. Full status, dependencies, and verification commands are in the evidence matrix.
Visual Namespace Modeler
Design supported workloads and resource relationships on a shared namespace canvas.
YAML and Helm Export
Generate YAML or a Helm archive for resource types covered by the implementation and evidence matrix.
RBAC Modeling
Model Kubernetes access policies and generate manifests for the supported policy paths.
Istio VirtualService
Model supported VirtualService resources and export their manifests; the Istio runtime remains external.
Existing Delivery Workflow
Take generated artifacts into your current Git review and deployment process. IzyKube does not replace that process.
Honest Verification
Cluster apply/delete and inspection paths are partial; comprehensive drift detection is not established.
Evidence and roadmap
Current claims are classified and reproducible
The capability matrix records its audit date and repository baseline. It separates implemented, partial, planned, and external items. Check that baseline before relying on it as a description of the latest code. Comprehensive drift detection and production readiness are not established by the cited tests.
Self-hosted setup
Review the prerequisites before starting
IzyKube is self-hosted. Terraform provisions the local k3s cluster and Docker network. The current Compose setup also expects a generated Kubernetes kubeconfig and pre-existing external MongoDB and Ollama data volumes. A clean Docker host cannot start the stack with docker compose up alone. The README documents the repository's development setup and these limitations.
FAQ
Common questions before adoption
Is IzyKube a hosted SaaS?
No. IzyKube is open-source and self-hostable. You can run it locally or in your own infrastructure.
Does it replace kubectl or Helm?
No. IzyKube complements kubectl, Helm, Git review, and your existing deployment tools by modeling supported resources and generating artifacts.
Who is it for?
IzyKube is aimed first at small platform teams and Kubernetes consultancies that need a visual way to design supported namespace resources and produce reviewable artifacts.
See whether the workflow fits your team
Review the tested scope and setup requirements, then evaluate IzyKube against one real namespace design.