Johannes,
You've written three times now and each time you said something useful.. so let me answer all of it one by one..
First, a bit about me. I'm not someone who sells panels. I've been working with servers, NAS and SAN systems for over 15 years, and I run the same stuff at home. A long stretch of it was ESXi, docker side, vm side, passthrough for unsupported hardware, raid layouts.. on ESXi you can't get software raid, and when you put hardware raid in it doesn't manage it either. Everything ends up cross wired, third party tools come in for backup, and the whole thing turns into more of a tangle with every tool you add. With Proxmox we can do a lot more, including using hardware with no sr-iov support in a shared way, but we get there by reading long guides for a long time..
There's another thing that wears us down on the corporate side. You walk into an architecture someone else built and you have to understand it before you can do any work. That's true even when you know the systems..
You're right about the target audience but a part of it is missing. Someone who finds the community subscription too expensive won't pay for this either, true.. I'm not trying to convince that person anyway. The person I have in mind is different. At some point we hand our systems over to someone and we spend a long time teaching them the job, and during that time mistakes get made on the system, then we're the ones cleaning them up. That's the moment I wrote Atlas for.
That's the answer to the views question too, actually. If you built your own system yourself you're right, the map is already in your head and it adds nothing for you. But there's someone who doesn't have that map.. the architecture you inherited, the new colleague, the person looking at the system at night. These views are for them. Operations done without knowing what's connected to what is where we've lost the most time..
You said it can't be simulated, I agree.. I'm not claiming simulation anyway. Atlas doesn't predict the future, it keeps the way back open. It reads apt's own resolution, there are checks that stop the job before it starts, it won't start if a vzdump is running or a scrub is in progress, and it takes a snapshot first. On the kernel side the new kernel isn't made the permanent default either, it's tried once, and if the machine doesn't come up it goes back to the old one. The decision is still yours. Our own terms say the same thing, that warnings and analyses are decision support and not a guarantee for your environment..
There's a misunderstanding about Apps, let me correct that. That feature installs nothing on the Proxmox host. It sits inside the vm creation wizard, it generates cloud-init user-data, docker and everything on top of it goes inside the guest vm dedicated to that job, the compose file lives on the vm's own disk. So it was built that way because of the same principle you're stating, that it doesn't belong on the host.
On the compose front-end part, my problem isn't writing compose. Bringing up a container at home is easy, in a corporate environment it isn't the same thing.. there it has to be sustainable, manageable, predictable and handover ready. That's why the templates bring the configuration with them. Internal services aren't exposed, only the web ui is published, the machine gets its address from the network, resolves by name so nobody has to memorise an ip, and shows up with the right name on the router. All of this can be done by hand, we did it by hand for years. But when you redo it every time and every person who sets it up does it a little differently, you end up with something nobody wants to take over. That's what I'm working on.
About the source code.. you're right here. In my last message I wrote that the root agent is AGPL and inspectable but I didn't show you anywhere to inspect it, and a sentence like that has no value on its own.
Here's where it stands, the part that runs as root isn't closed. After install it sits under /opt/atlas/agent as plain readable javascript, no minification, no obfuscation. The closed part is the interface and the product logic, and that part never runs as root. Every release is signed with ed25519 and the agent won't apply an update without verifying the signature with an embedded key. But none of that lets you look before you buy, and that's exactly your point.. so I'm putting the agent on github, the preparation is under way. You'll be able to read what runs as root even if you never buy anything.
Let me also explain what I do on the design side.. I follow Samsung One UI and Apple's interface guidelines, and others too. Those people didn't write their rules for nothing. I take those rules and look at my own problem with them, in what order should the user do this job, where should they stop and think, where should they move fast. I put established good practice next to my own flow and work out a path, and for every operation this turns into work that runs from the visual design all the way to the backend. That might also be why the screen feels familiar, I follow established design languages on purpose and today almost every interface that follows those rules looks like the others anyway.
Instead of just claiming it let me give you something you can check in the demo. Go to Storage and try to wipe a disk. You don't get an are you sure, you get the steps that will run in order.. first umount, then the uuid lines being cleaned out of fstab, then wipefs. And it says plainly the data isn't coming back. An interface generator doesn't write that text, someone who has wiped the wrong disk before writes that text. Same logic is in other places, on the updates screen I split packages into three impacts for example, no interruption, restarts a service, needs a reboot. I tried a more detailed classification but it wasn't changing anyone's evening, so I dropped it.
On the AI part let me speak plainly. This project isn't a project handed over to AI. I do get support, true.. the support I get is for discussing architectural decisions and going through long technical research. I don't trust a single model either, I run a few of them together because they contradict each other and that contradiction is useful to me. I'm the one making the decision.
One more thing.. the generation coming up now insists on wiring a system straight to AI and having it do the work, and I don't want that. If it's going to be done at all it should be inside a frame built by experienced hands, that's one of the reasons this product exists. Handing a job like this entirely to AI wouldn't be sensible anyway, if it were possible what would be the point of this product existing, we'd hand over the api, say go do it, and that wouldbe that.
I'm building this project for myself. I opened it up thinking why not. Whether it sells or not I'll keep going, because I need it in my own processes anyway.
Last thing, I'm genuinely curious.. which part exactly looked AI generated to you? I'm asking seriously. If someone else thinks the same thing then I have a design problem and I'd want to know about it.....
