While I like the layout and having a good UI for managing virtual machines this project lacks any security features at all.
Most notably, if you just set the auth cookie to "authenticated" you will have access to spin up as many VMs you like on any flint instance in the wild (08-09-2025).
As such this is an incredibly unsafe project to use. Probably because of the vibe coding :(
The problem is vibe coding AND negligence. Good software practices like testing, code review, documentation are bound to catch the LLM-isms.
No offense on the author, the project specifically calls out that it's a "young" project in the footer, so I personally wouldn't expect it to be quite up to spec yet.
I like the sound of it, especially the compact single-file executable with minimal dependency. Forgive me for my ignorance, I may not fit the target user profile - I'm not familiar with KVM, and have only occasionally used QEMU. I read briefly about Cloud Init when setting up Multipass for creating new Ubuntu VMs.
Can this tool `flint` replace some uses of Docker? I'm curious if I can use it for local development purpose, or for running stuff in production like isolating applications.
flint launch [image-name]
Launch a new VM with smart defaults. Supports launching from images or templates.
Is there a registry of images, like OS versions? Or maybe it's more decentralized than that. It also sounds related to OCI (Open Container Initiative) format that Podman supports, and qcow2 images for QEMU.
Could you give a brief summary of what this tool enables, for a potential user who doesn't know much about KVM?
Quick summary of the technology is that there is two software parts for virtualization, the hypervisor and the virtual machine monitor.
First is the hypervisor that uses the hardware virtualization features of your cpu to emulate hardware interrupts and virtual memory paging. This part is usually buint into the operating system kernel and one will be prefered per operating system. Common ones are Hyper-V on Windows, Virtualization.Framework on Mac and KVM on Linux
With the kernel handling the low level virtualization you need a Virtual Machine Monitor to handle the higher level details. The VMM will manage what vm image mounted and how the packets in and out of the vm are routed. Some example of VMMs are QEMU, VirtualBox and libVirt.
Flint, the app being shown is a vibe coded web app wrapper around libVirt. On the bright side this app should be safe to use but it also does not do much beyond launching pre made virtual machines. As a developer the work you need to do is provide an Linux distribution (Ubuntu, etc), a container manager (Kubernetes, Docker) and launch your own containers or pre made ones from the internet (Dev Containers).
Docker products are a maze of naming confusion. If comparing to Docker Desktop (which exists for Linux too) then it's related since that's also a virtual machine system.
The readme keeps using the word “manage” but what does it actually do? Does it create and start new VMs? Using dockerfiles? On the local host or other hosts? I don’t understand WTF this thing does.
For clarity:
Hypr Pte. Ltd. (UEN 202520273N), AS211747 HYPR-NET, is an infra-focused startup working on microVMs, virtualization, and novel approaches to infrastructure. We are independently managed and only active in the infrastructure space; other accounts or projects are unrelated.
Infuze was ours but has since been shut down so we can focus fully on our own architecture. There has never been any scam, nor anything remotely related to one.
The Show HN post about the lightweight VM manager is unrelated to any cloud business. It started as a quick personal tool and unexpectedly resonated with people, so I iterated on it the same day. It’s just a minimal Go wrapper around libvirt, not connected to our core work.
While I am using cockpit every time I need to remotely manage the machines, I couldn't get it to log me in via something other than user's login/password, which are not that safe, and it listens to 0.0.0.0 by default too.
So I have to ssh into machine, start cockpit service, use it, and then stop the cockpit.socket once I finish.
Would be great to have something which has its own users/passwords (to have strong password in bitwarden) and doesn't listen to 0.0.0.0 by default. If it's also lightweight – even better!
Yes but if there's going to be something lightweight and correct-by-default I'd prefer that, mostly because I have many machines to manage and a team of people to educate. I'd like default to be good instead of wasting time and risking.
Can you explain a bit more? The user passwords are inherently not strong enough so I disable all ssh via password and only use private keys (id_ed25519). If cockpit allowed me to use one I'd be ok, but if they don't – I at least want some scary auto-generated password only for cockpit, not the system user's one (which is often very weak).
Yes but if there's going to be something lightweight and correct-by-default I'd prefer that, mostly because I have many machines to manage and a team of people to educate. I'd like default to be good instead of wasting time and risking.
For something as simple as this, is next.js even worth it?
There is something to be said for it because LLM's having been trained on its structure, but I'm having decent success stripping out all dependencies except tsc.
Hey, thanks for sharing. As someone who uses QEMU via rudimentary shell scripts, this looks interesting.
Unfortunately, I'm reluctant to trust a 26KLOC vibe-coded app[1] for something like this, so I'll pass.
But if a polished React/Next.js app, with a CLI, HTTP/WebSocket API, authentication, and libvirt integration, truly took you a couple of hours to produce, and it solves your problem, that's a commendable achievement. I'm not sure if I should be praising you or the LLM, but it's notable nonetheless.
It seems to me that in use cases like this, reliability and stability is so much more important than a nice lightweight UI.
This project advertises a small single binary but that’s really a feature of Go, and the small size is a feature of the fact that this is a rushed vibecoded app.
A typical HomeLab user (mentioned in this project as one of the primary audiences) is probably using something like Proxmox because it’s exactly it’s been around for years and years, it’s developed by a professional team, it’s relatively easy to use, and it’s feature-rich.
I do think that there's appeal in a single-binary tool that implements the core features of something like Proxmox. Proxmox is a complex project that requires dedicating an entire machine to it.
I'm not familiar with Kimchi or Cockpit, but OP's claims sound reasonable. There are/were other even simpler tools like the similarly named flintlock, Incus, Lima, plain virsh, and many others. But most of them don't have a web UI, which matters to some users.
However, besides this being vibecoded, what is fishy to me is that this project is coming from an account that 2.5 months ago was promoting their own cloud hosting project[1], with some fantastic claims, and suspiciously LLM-like replies. And yet today the web site of the project fails to load because of a TLS error.
If you look even deeper into it, a second new account "supitsj" shows up in the comments, seemingly representing the same service, which seems to be the same account that created a tutorial[2] for them. The "jlucus" GitHub account claims to be a "Jesse D. Lucus" from Oakland, CA, whose links and website are full of crypto/web3/betting scams, and AI-generated slop. The account is also part of a non-existent "hypr-technologies" org, which seems to be a company registered in Singapore[3], which does have its own AS[4]. On its website it says that Infuze is "retired", and now they're focused on a new project called "Raiin".
I'm not sure if these people are legit, scammers, or AI bots, but this whole thing stinks to high heaven. They're now flooding HN as well, as this isn't the first time I've seen Show HN posts with similar projects.
AI-blocking AI tools are becoming increasingly necessary. What a time to be alive.
Maybe this was a homegrown tool for managing VMs in their infuze platform and they decided to open source it? Speculation of course, as is your guesswork here too. Would be nice to hear a response from the OP.
> Maybe this was a homegrown tool for managing VMs in their infuze platform and they decided to open source it?
That would be the charitable interpretation, but there's no doubt that this was vibecoded[1]. Their claim was that they came up with this in a "couple of hours" when they needed it, not that they released something that was previously proprietary.
As for my second comment: none of it was speculative. The accounts and links are there, you can see for yourself. I obviously can't prove that this in particular is a scam, but it certainly doesn't put the project in good light when its authors are part of scam circles.
I'm running Proxmox in my homelab. Although it's based on Debian, it doesn't lend itself to running tasks other than Proxmox itself. I, for one, would appreciate a KVM manager with web UI (Portainer for KVM, if you may) - but I'm reluctant to run something so vibe-coded.
Besides your spamming concern (which isn’t really that big of a deal) are you concerned this could be malicious? That’s my concern. How would they inject their malicious code besides the obvious of in the installer (main/install.sh) script?
I can't really say what their intentions are. It could be an elaborate scam to get people to sign up for cloud hosting, and then disappear, as their original project did.
They're also distributing binaries that can't be guaranteed to have come from these sources. So even if the AI slop has no malicious code, they could still be injecting it from somewhere else.
I don't know, and frankly, don't care. I would just caution people to not trust projects showcased by random accounts, since assholes have much more powerful tools at their disposal now.
It'd be cool to see a nice UI (like this) atop something a little better built out & defined like systemd-nspawn. Like Quadlet for containers, Nspawn for VMs is a nice base with tons of great capabilities & very standard management patterns. There's nice .nspawn files and drop ins, where config lies, and (semi) standard paths for mounts and machines. Having that stable standard base would raise my interest & confidence a lot.
This recent guide covers a ton of nitty gritty, down to baking your own vm images & doing everything by hand. But by half way through, it builda to using the nice machinectl cli that is the real meat of the experience. https://quantum5.ca/2025/03/22/whirlwind-tour-of-systemd-nsp...
Most notably, if you just set the auth cookie to "authenticated" you will have access to spin up as many VMs you like on any flint instance in the wild (08-09-2025).
As such this is an incredibly unsafe project to use. Probably because of the vibe coding :(
The problem is vibe coding AND negligence. Good software practices like testing, code review, documentation are bound to catch the LLM-isms.
No offense on the author, the project specifically calls out that it's a "young" project in the footer, so I personally wouldn't expect it to be quite up to spec yet.
What is KVM? - https://www.redhat.com/en/topics/virtualization/what-is-KVM
Can this tool `flint` replace some uses of Docker? I'm curious if I can use it for local development purpose, or for running stuff in production like isolating applications.
Is there a registry of images, like OS versions? Or maybe it's more decentralized than that. It also sounds related to OCI (Open Container Initiative) format that Podman supports, and qcow2 images for QEMU.Could you give a brief summary of what this tool enables, for a potential user who doesn't know much about KVM?
First is the hypervisor that uses the hardware virtualization features of your cpu to emulate hardware interrupts and virtual memory paging. This part is usually buint into the operating system kernel and one will be prefered per operating system. Common ones are Hyper-V on Windows, Virtualization.Framework on Mac and KVM on Linux
With the kernel handling the low level virtualization you need a Virtual Machine Monitor to handle the higher level details. The VMM will manage what vm image mounted and how the packets in and out of the vm are routed. Some example of VMMs are QEMU, VirtualBox and libVirt.
Flint, the app being shown is a vibe coded web app wrapper around libVirt. On the bright side this app should be safe to use but it also does not do much beyond launching pre made virtual machines. As a developer the work you need to do is provide an Linux distribution (Ubuntu, etc), a container manager (Kubernetes, Docker) and launch your own containers or pre made ones from the internet (Dev Containers).
# List your VMs
flint vm list --all
# Launch a new Ubuntu VM named 'web-01'
flint launch ubuntu-24.04 --name web-01
# SSH directly into your new VM
flint ssh web-01
# Create a template from your configured VM
flint snapshot create web-01 --tag baseline-setup
# Launch a clone from your new template
flint launch --from web-01 --name web-02
Infuze was ours but has since been shut down so we can focus fully on our own architecture. There has never been any scam, nor anything remotely related to one.
The Show HN post about the lightweight VM manager is unrelated to any cloud business. It started as a quick personal tool and unexpectedly resonated with people, so I iterated on it the same day. It’s just a minimal Go wrapper around libvirt, not connected to our core work.
So I have to ssh into machine, start cockpit service, use it, and then stop the cockpit.socket once I finish.
Would be great to have something which has its own users/passwords (to have strong password in bitwarden) and doesn't listen to 0.0.0.0 by default. If it's also lightweight – even better!
> Configure Cockpit to listen only loopback/127.0.0.1[1]:
[Socket]
ListenStream= #This remove 0.0.0.0:9090 bind based on the docs
ListenStream=127.0.0.1:9090
> Execute in your machine a port forward with SSH[2]:
ssh -N -L 9090:127.0.0.1:9090 host@ip
> Then you can open localhost:9090 in your browser securely only using SSH (that is already part of your actual workflow).
[1]: https://cockpit-project.org/guide/latest/listen
[2]: https://coder.com/docs/code-server/guide#port-forwarding-via...
You could also have a more strict password policy but I don't know that I'd ever want to expose something like cockpit to the raw Internet.
There is something to be said for it because LLM's having been trained on its structure, but I'm having decent success stripping out all dependencies except tsc.
Tart VM is interesting but still have the same issue.
Unfortunately, I'm reluctant to trust a 26KLOC vibe-coded app[1] for something like this, so I'll pass.
But if a polished React/Next.js app, with a CLI, HTTP/WebSocket API, authentication, and libvirt integration, truly took you a couple of hours to produce, and it solves your problem, that's a commendable achievement. I'm not sure if I should be praising you or the LLM, but it's notable nonetheless.
[1]: https://github.com/ccheshirecat/flint/commit/eb90847db9da56c...
This project advertises a small single binary but that’s really a feature of Go, and the small size is a feature of the fact that this is a rushed vibecoded app.
A typical HomeLab user (mentioned in this project as one of the primary audiences) is probably using something like Proxmox because it’s exactly it’s been around for years and years, it’s developed by a professional team, it’s relatively easy to use, and it’s feature-rich.
And oh, by the way, Proxmox is free as in beer.
I'm not familiar with Kimchi or Cockpit, but OP's claims sound reasonable. There are/were other even simpler tools like the similarly named flintlock, Incus, Lima, plain virsh, and many others. But most of them don't have a web UI, which matters to some users.
However, besides this being vibecoded, what is fishy to me is that this project is coming from an account that 2.5 months ago was promoting their own cloud hosting project[1], with some fantastic claims, and suspiciously LLM-like replies. And yet today the web site of the project fails to load because of a TLS error.
If you look even deeper into it, a second new account "supitsj" shows up in the comments, seemingly representing the same service, which seems to be the same account that created a tutorial[2] for them. The "jlucus" GitHub account claims to be a "Jesse D. Lucus" from Oakland, CA, whose links and website are full of crypto/web3/betting scams, and AI-generated slop. The account is also part of a non-existent "hypr-technologies" org, which seems to be a company registered in Singapore[3], which does have its own AS[4]. On its website it says that Infuze is "retired", and now they're focused on a new project called "Raiin".
I'm not sure if these people are legit, scammers, or AI bots, but this whole thing stinks to high heaven. They're now flooding HN as well, as this isn't the first time I've seen Show HN posts with similar projects.
AI-blocking AI tools are becoming increasingly necessary. What a time to be alive.
[1]: https://news.ycombinator.com/item?id=44382949
[2]: https://github.com/jlucus/infuze-tutorial
[3]: https://www.scam.sg/companies/53503711B/hypr-technologies
[4]: https://ipinfo.io/AS211747
That would be the charitable interpretation, but there's no doubt that this was vibecoded[1]. Their claim was that they came up with this in a "couple of hours" when they needed it, not that they released something that was previously proprietary.
As for my second comment: none of it was speculative. The accounts and links are there, you can see for yourself. I obviously can't prove that this in particular is a scam, but it certainly doesn't put the project in good light when its authors are part of scam circles.
[1]: https://github.com/ccheshirecat/flint/blob/b49a90bc984f12857...
They're also distributing binaries that can't be guaranteed to have come from these sources. So even if the AI slop has no malicious code, they could still be injecting it from somewhere else.
I don't know, and frankly, don't care. I would just caution people to not trust projects showcased by random accounts, since assholes have much more powerful tools at their disposal now.
This recent guide covers a ton of nitty gritty, down to baking your own vm images & doing everything by hand. But by half way through, it builda to using the nice machinectl cli that is the real meat of the experience. https://quantum5.ca/2025/03/22/whirlwind-tour-of-systemd-nsp...