I just saw this and created a quick deployment to my k3s installation. I created deployment.yaml, service.yaml, and ingress.yaml. I've got a few things already set up like wildcard DNS, cert-manager, and homepage so I've got a few extras in these files and kubeforge is already showing up in my homepage and deployed with https.
I ran into errors when I tried to download the schema, but then it suddenly started working, not sure why.
My first impression is that even with a high resolution laptop screen you're going to end up doing a lot of zooming in and out even for trivial deployments.
I imported the directory where I created those 3 yaml files and now have 3 connected boxes for the ingress, two for the deployment, and three for the service, but no interconnections between those three groups. It would be nice if the labels were cross connected between those groups, even better if when you were creating those groups from scratch you could specify the labels on one side then draw the edge connecting them and the label would get filled in on the other side and even get updated when one side changes. For example if I created a deployment with app.kubernetes.io/name of kubeforge and then was able to create the service object and link the edge and have that label connect.
I must not be following the UX for this tool
1. click configmap in the sidebar
1. observe configmap dialog in the layout
Also observe that the "kind" is "Configmap" but the Kubernetes resource is ConfigMap, as one can see here https://kubernetes.io/docs/reference/generated/kubernetes-ap...
Your tool does the same thing for CronJob being erroneously written as Cronjob so it is a systemic problem
1. expand "data" chevron
1. be sad because nothing else is possible
1. ok, so type "true" into the "immutable" field. It doesn't seem to turn the red icon green. Type "my dog is snoopy". Nothing else changes
Be aware that, yes, there are "status" responses on a bunch of the objects, but to the very best of my knowledge one can never set a "status" because the user doesn't control the status rather reality controls the status, otherwise I'd cheerfully always set my Pods to never CLBO :-P
Looking half the way there to fulfill my wishlist for a perfect kubernetes tool. Showing resources as a graph is a big plus but I'd like to also see:
1. Minimizing nodes into just a name, to get a view of just relationships between resources 2. Auto-organizing the graph. You're already warning about overlapping nodes, might as well give me a way to automatically fix it. 3. Reading existing resources from a cluster
3, in particular, is kind of a whole other type of tool, to view/debug existing infra, instead of creating it, but the UI has the right shape to do that extremely well, too.
I agree with other comments that adding a default example to the demo would be nice. I imported this manifest, and it worked pretty well: https://github.com/kubernetes/examples/blob/master/guestbook...
Looks pretty neat. Would be nice if you could point it at a cluster to view deployed applications somehow to see what is defined and what _could_ be defined, but aren't.
Maybe we should just use JSON files and convert them to YAML files before usage. No mistake of indentation possible and also does not allow "programming" inside the configuration shenanigans.
Well done!
Having user-challenges with kubefor.ge.
Clicked "Deployment" and then tried "Create metadata node" but it errors:
Missing config in qA_PQ-QAe8tznselScKge Node qA_PQ-QAe8tznselScKge has no values configured.
And:
Overlapping Nodes Node "deployment" overlaps with "undefined".
This is the generator demo of k8s I made before. https://k8s-generator.vercel.app/
Open with a demo deployment, let the user import over that. Right now you've got a cold-start problem.
Right now, requiring users to understand every field in a deployment manifest feels unnecessarily complex. Since Kubernetes YAML is already quite straightforward to copy, paste, and modify from examples, the added cognitive load of deciphering each field may not provide proportional value—especially when the same manifests can be generated more efficiently.
What would be far more valuable is a feature that lets users import a Helm chart URL directly into the UI, then visualize and interact with the chart’s values in an intuitive way—no need to dig through documentation. Being able to explore, modify, and export the values in a user-friendly interface would save significant time and reduce friction, especially when working with complex or unfamiliar charts.
In short: instead of manually parsing YAML or hunting through Helm docs, a visual, interactive view of Helm values—especially when tied to a chart URL—would be a game-changer for productivity and usability.