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.
Thank you for the insight, for the initial version I wanted something that laid down the groundwork for defined schemas. I also wanted to make sure that I handled data conversion from yaml -> json object -> yaml correctly.
I love the idea to be able to import helm url's (and possibly edit + rehost), the next features are going to be around naming required/most used fields for simplification and decluttering the node components, and adding in support for helm and kustomize with template variables.
Was there anything else that you noticed that you would like to see or anything that you saw that you enjoyed?
A few years back, I had an idea for a K8s YAML explainer. In the spirit of XSLT transforms on XML, you would run your K8s yaml against an explainer file and generate a document that provided visualizations, interpretative text alongside the define values and an explanation about the field, its purpose, suggestions and some best practices about the field. Used the idea to write my first rust CLI. I was heading towards using it for Helm, but never got to it.
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.
2. To minimalize scrolling around for deployments I want to incorporate a "minimize" feature on nodes so that users can free up space on the graph. (https://github.com/kubenote/KubeForge/issues/6)
3. Interconnectivity is built in but currently only with inline data on nodes. Adding the capability to object refs does make sense. In the future I also want to create generic "string nodes" as a first pass at templating via the node graph. (https://github.com/kubenote/KubeForge/issues/7)
Thank you for kicking the tires and giving me feedback on how to improve!
Did you find the concept refreshing? And what would you like to see in it for it to be something that you would actively use?
After playing with it a bit more it looks nice but has fallen into an uncanny valley of usefulness. It provides a nice looking way to view the structure and a very syntax assisted way to change that structure, but no guidance whatsoever as to what you probably need to do. For example for me to deploy kubeforge I picked a set of 3 yaml files from something else and copied them to a new directory and then it was basically a search and replace to change the names and image file. So I had to really understand the files once and now I'm doing fairly mindless work to reuse them. But with kubeforge I have to deeply understand the details every time and select them from pulldowns - that's actually harder. I know I could have imported those yaml files first, made changes and exported them, but then I'd be going to the fields and changing them one by one, there is no equivalent of global search and replace. Now if I need to do something new/different then kubeforge can make it easier to figure out what options are at any given spot but still provides no guidance - I recently used initContainers for the first time in a project and could have used a "oh you want to set up an initContainer, here are the required elements for that".
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
The color of the fields is not based on right or wrong but based on typing. Green is string, red is boolean, orange is object, purple is array, etc. I can definitely make that more apparent.
https://github.com/kubenote/KubeForge/issues/11
For the fields that exist but aren't feasible for users to interact with, currently I'm puling in the schemas raw. but I do want to create a preferred fields override with commonly edited and changed fields to reduce clutter.
https://github.com/kubenote/KubeForge/issues/13
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.
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.
I have a extended future roadmap, depending on what the community would like to see, but adding in deployment from the ui and cluster management/analytics is also on there. However that goes a bit beyond my current skillset, so I wanted to launch small and build.
Are there any other features that you felt are missing or that you think would complement KubeForge?
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.
you don't need to convert json files to use them with kubernetes. `kubectl` and most tooling in the kubernetes ecosystem supports json both as an input and output format.
Created the issue, there is was a bit of a design flaw preventing me from doing this off the bat, but I do think it is important and would expedite understanding from the demo. Thank you!
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.
Thank you for the insight, for the initial version I wanted something that laid down the groundwork for defined schemas. I also wanted to make sure that I handled data conversion from yaml -> json object -> yaml correctly.
I love the idea to be able to import helm url's (and possibly edit + rehost), the next features are going to be around naming required/most used fields for simplification and decluttering the node components, and adding in support for helm and kustomize with template variables.
Was there anything else that you noticed that you would like to see or anything that you saw that you enjoyed?
A few years back, I had an idea for a K8s YAML explainer. In the spirit of XSLT transforms on XML, you would run your K8s yaml against an explainer file and generate a document that provided visualizations, interpretative text alongside the define values and an explanation about the field, its purpose, suggestions and some best practices about the field. Used the idea to write my first rust CLI. I was heading towards using it for Helm, but never got to it.
An object graph solution perhaps? : https://codesolvent.com/configr/
You can go from data format (yaml,json,xml, property file...etc) to object graph and the reverse.
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.
There is a lot to unpack here! Thank you for the feedback!
1. For the errors on downloading the schema, that is something that I need to bake through and improve. (https://github.com/kubenote/KubeForge/issues/5)
2. To minimalize scrolling around for deployments I want to incorporate a "minimize" feature on nodes so that users can free up space on the graph. (https://github.com/kubenote/KubeForge/issues/6)
3. Interconnectivity is built in but currently only with inline data on nodes. Adding the capability to object refs does make sense. In the future I also want to create generic "string nodes" as a first pass at templating via the node graph. (https://github.com/kubenote/KubeForge/issues/7)
Thank you for kicking the tires and giving me feedback on how to improve! Did you find the concept refreshing? And what would you like to see in it for it to be something that you would actively use?
After playing with it a bit more it looks nice but has fallen into an uncanny valley of usefulness. It provides a nice looking way to view the structure and a very syntax assisted way to change that structure, but no guidance whatsoever as to what you probably need to do. For example for me to deploy kubeforge I picked a set of 3 yaml files from something else and copied them to a new directory and then it was basically a search and replace to change the names and image file. So I had to really understand the files once and now I'm doing fairly mindless work to reuse them. But with kubeforge I have to deeply understand the details every time and select them from pulldowns - that's actually harder. I know I could have imported those yaml files first, made changes and exported them, but then I'd be going to the fields and changing them one by one, there is no equivalent of global search and replace. Now if I need to do something new/different then kubeforge can make it easier to figure out what options are at any given spot but still provides no guidance - I recently used initContainers for the first time in a project and could have used a "oh you want to set up an initContainer, here are the required elements for that".
Would love to take a deeper dive into what you feel would improve your experience.
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
Thank you for that insight, indeed k8s uses pascal case. I have opened an issue to investigate further and resolve. https://github.com/kubenote/KubeForge/issues/10
The color of the fields is not based on right or wrong but based on typing. Green is string, red is boolean, orange is object, purple is array, etc. I can definitely make that more apparent. https://github.com/kubenote/KubeForge/issues/11
As for the empty object, there are a lot of objects are that incomplete that I need to go through and apply manual override definitions for (https://github.com/kubenote/KubeForge/blob/main/src/componen...). Thank you for pointing out the two above. https://github.com/kubenote/KubeForge/issues/12
For the fields that exist but aren't feasible for users to interact with, currently I'm puling in the schemas raw. but I do want to create a preferred fields override with commonly edited and changed fields to reduce clutter. https://github.com/kubenote/KubeForge/issues/13
Thank you for the awesome feedback!
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.
I have a extended future roadmap, depending on what the community would like to see, but adding in deployment from the ui and cluster management/analytics is also on there. However that goes a bit beyond my current skillset, so I wanted to launch small and build.
Are there any other features that you felt are missing or that you think would complement KubeForge?
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.
you don't need to convert json files to use them with kubernetes. `kubectl` and most tooling in the kubernetes ecosystem supports json both as an input and output format.
That's great news to me. Once I get around to using kubernetes or k3s or something, I will most likely use JSON then. Thanks for the heads up.
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".
Thank you! I'll double check the schema objects for metadata node, most likely some issues with how I have it defined.
For the overlapping nodes, I'll also throw an issue for both of those in GH :)
Did you like anything in particular or have a feature in mind that would make this better to you?
--- edit ---
For the metadata node warning, it was stating that the node is created but does not have values inside of it.
--- edit 2 ---
resolved the get.kubefor.ge/latest issue with: https://github.com/kubenote/KubeForge/issues/1 and removed undefined + improved warnings with: https://github.com/kubenote/KubeForge/issues/2
Same behavior when I run the container locally.
Issues with `get.kubefor.ge/latest`:
Manifest does not match provided manifest digest sha256:a4d6b4a9513289be1c1349afff46f7c87a5ac8513cbd8b66de350f26442d14bf
Works with:
ghcr.io/kubenote/kubeforge:latest
get.kubefor.ge@sha256:a4d6b4a9513289be1c1349afff46f7c87a5ac8513cbd8b66de350f26442d14bf
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.
Created the issue, there is was a bit of a design flaw preventing me from doing this off the bat, but I do think it is important and would expedite understanding from the demo. Thank you!
https://github.com/kubenote/KubeForge/issues/4
Please let me know if there are any features you enjoy or if there is something you would like to see added!