Most active commenters
  • ccheshirecat(7)
  • mdaniel(4)

Show HN: I built a cloud on my own ASN w real 1:1 compute to fight the cartels

(infuze.cloud)
10 points ccheshirecat | 14 comments | 25 Jun 25 23:58 UTC | HN request time: 1.05s | source | bottom

Sup HN I'm MX, a solo founder building Infuze Cloud, launching as a beta today. I started this project because I was tired of a long list of reasons why the cartels are ridiculous that I shall not dwell on for too long here because I had to rewrite this twice cause of hitting the character limit

So I decided to try building something I’d want to use. The whole stack is built custom from the ground up with no external dependencies or costs to third parties apart from hardware and IP space.

What Infuze is:

Raw, dedicated performance: 1 vCPU = 1 physical thread. No overcommit. I cap my nodes allocations at the physical hardware limit with some overhead.

Pricing based on what you use: It's set at $10/m for 4gb/1vcpu/50gb but can be provisioned for min 1hour(3 cents). Discounts on wallet top up's to prevent pressure to get unneeded resources(even the minimum top up starts at 10% discount so its actually $8+ a month goes down to $7.50 with larger top up's.

Runs on our own hardware(leased) and autonomous system: We operate our own Intel Xeon Platinum 8280 servers and BGP-routed IP space (AS211747).

KVM based with storage NVMe gen4 with ZFS

Stack:

It's built on mostly open source technology!

Proxmox for virtualization, Knot for master authorative and outsourced for anycast slaves, custom Go microservices for most of the automation needed by the frontend(open sourcing some of them soon!). FRR for BGP. Networking is standard bridged networking that's routed from leased IP space that I'm announcing with FRR. Mail using maddy. Prometheus/node exporter for metrics, grafana for panels. The LLM chatbot is using AnythingLLM with openrouter but that was mostly like a FOMO thing lol tbh I don't expect anyone to use it much(because i dont) but if it helps someone then that's great. Support/ticketing is custom, with the Next.js frontend, billing is Stripe. Each VM gets a public IPv4 and a /64 subnet routed to it, no NAT or SNAT.

If you guys have any questions or want to discuss more on the stack that I didn't mention I'm very open to sharing, discussing, and learning about new ways to optimize my stack. I'm still very new to all this and learning as I go along so any insight is appreciated! I'm working on something more experimental(custom firecracker fork that directly boots ELF+IVSHMEM apps from memory with a unikernel or initramfs), which I hope to bring to the public soon, but lacked funding to keep moving forward so I decided to start this as a learning experience and first venture into the industry, with a more mature stack that's reliable and battle tested enough for public use.

Who it's for:

Developers who prefer using linux with root access, via SSH, etc.

People who want to pay for something closer to real infra costs. Compute isn't expensive and the tech isn't difficult. We shouldn't be forced to pay an amount that a monopoly feels they deserve.

This isn't for those that engage in yaml-therapy or love contributing to the charitable foundation for wooden figureheads, but I've got something lined up for you guys too! ;)

This is the first public beta, and while most things are battle-tested, I expect a few bumps. I’ll be around all day to answer any questions, fix bugs quickly, and learn from the feedback.

For the benchmark nerds I spun up a quick little site for fun with v0 because I was finding endless things to tinker with and feed my impostor syndrome to delay launching this but I've dragged it long enough https://bench.infuze.cloud

You can get a free dollar voucher there and run a benchmark for fun, I wanted to do a larger amount but realized that my hourly billing is gonna be a magnet for abuse and being entirely self funded that's probably not a good idea, but I'm prepared to pivot fast(and strike back, to those even considering it -_-)

Thanks for reading, and I’d love to hear any feedback, ideas, and critique. Appreciate you all.

1. mtmail ◴[26 Jun 25 00:32 UTC] No.44383121[source]▶
The pricing page tries to sell that the pricing is easier to understand, no hidden fees etc. Then has to explain the top-up discounts multiple times. I'd remove the whole discounts, it's distracting.

"Wallet" sounds like crypto to me. Maybe it isn't but it's not clear enough "add money to your account" might be sufficient.

The "See The Difference" table. Is it really that different? The header lists a different amount of memory as the table cells. The price difference is about 20% (40 vs 48). Where's the 80% savings from the homepage.

"Perfect Resource Balance - 1:4:50:2000 ratio ensures all resources saturate equally." Sorry, I have no idea what the numbers mean.

replies(1): >>44414058 #
2. mdaniel ◴[26 Jun 25 01:30 UTC] No.44383428[source]▶
Because I have been curious about this for so long, and you said "It's built on mostly open source technology" I figured now's my chance to ask:

Why roll your own control plane when OpenStack ships with so many batteries included, and (arguably important) doesn't require someone making a vanity SDK to interact with your vanity cloud?

replies(1): >>44414075 #
3. mdaniel ◴[26 Jun 25 01:30 UTC] No.44383437[source]▶
Related to the API part, I was browsing and noticed that https://infuze.cloud/docs/api#/Virtual%20Machines/post_vms references templateVMID but https://infuze.cloud/docs/api#/Templates/get_templates shows only "get" so is the template just for quick-start scenarios or users could [eventually] create their own?
replies(1): >>44414065 #
4. mdaniel ◴[26 Jun 25 01:38 UTC] No.44383473[source]▶
For your consideration, having <https://infuze.cloud/help/vm-creation-management#:~:text=inf...> without the ability for the user to influence the cloud-init of those newly launched instances is practically worthless

A middle ground may be for you to add just the webhook feature <https://docs.cloud-init.io/en/latest/reference/yaml_examples...> so folks could react to newly launched instances and provision them "from outside" or, of course, https://docs.cloud-init.io/en/latest/reference/modules.html#...

replies(1): >>44413778 #
5. baobun ◴[26 Jun 25 05:18 UTC] No.44384381[source]▶
Why not have a non-cartel non-third-party payment method, too? Please support Bitcoin/Monero payments.
replies(1): >>44414086 #
6. trod1234 ◴[26 Jun 25 21:53 UTC] No.44391854[source]▶
Interesting project.

Do you have any plans to blog about your experience on things like the setting up of your own ASN?

Are you planning, or already have rolled RPKI, monitoring, or other methods so your traffic doesn't get attacked (i.e. common BGP issues).

By "cartels", I assume your meaning is the monopolies in the industry space, but word choice is highly associated with South America illegal organizations. I understand you hit the cap which is probably why you didn't clarify but it was a clunker.

replies(1): >>44413794 #
7. ccheshirecat ◴[29 Jun 25 15:14 UTC] No.44413778[source]▶
That's an excellent point, and you were 100% right. It was a major gap in our initial MVP. Your feedback (and similar comments) pushed us to prioritize this immediately. I'm happy to say we've already shipped full user-data and vendor-data support for cloud-init. You can now pass it in directly via the web UI during VM creation, or via our CLI/API. We wanted to make sure it was properly implemented before announcing it widely, but you called it out perfectly. Thanks for the push, this kind of feedback is exactly what we need to make the platform genuinely useful.
8. ccheshirecat ◴[29 Jun 25 15:17 UTC] No.44413794[source]▶
Thanks, I appreciate the kind words and the great questions. Blogging about the ASN/Network Journey: Absolutely. The process of getting an ASN, IP space, and setting up peering at IXs as a solo bootstrapped entity was a wild ride. for sure I've thought a lot about blogging, if not for sharing the journey then because the insights I've gained along the way has ingrained in myself some lessons or well some would call it opinions, that I feel a need to share. So yes I am plannng to do it but it's not especially my nature. Network Security (RPKI, etc.): Yes, security is critical. We've already implemented RPKI for our announced prefixes to prevent route hijacking. We're also using BGP Flowspec with our upstreams for DDoS mitigation and are continuously monitoring our network for any anomalies. It's a constant process, but the foundation is there. "Cartels" Wording: Fair callout on the word choice. You're right, it's a bit of a clunker. I hit the character limit and was trying to be punchy. The intent was to capture the feeling of being locked into a few dominant players with opaque pricing and oversubscribed resources, but I can see how it lands poorly. Point taken, will be more careful with the copy. Thanks for the feedback.
9. ccheshirecat ◴[29 Jun 25 15:52 UTC] No.44414058[source]▶
This is incredibly valuable feedback, thank you. You've pointed out some major areas of confusion on our pricing page that we need to fix. You're right. The intention was to offer a loyalty reward, but the execution is clearly confusing and distracts from the core message of simple, transparent pricing. We've restructured it to be more easy to understand and intuitive and it's not exactly entirely there yet but it's better than it was before I guess, am constantly looking for better ways to handle this!
10. ccheshirecat ◴[29 Jun 25 15:53 UTC] No.44414065[source]▶
Great question. Currently, the templates are pre-configured by us for quick-start scenarios (e.g., Ubuntu 24.04, AlmaLinux, etc.). The API allows you to list these and use them to launch a new VM. The ability for users to create their own custom templates (i.e., take a snapshot of a configured VM and use it as a base image for future deployments) is very high on our roadmap. It's the logical next step after implementing cloud-init support. We see that as a critical feature for building scalable, repeatable infrastructure. So, to answer directly: not yet, but soon.
replies(1): >>44414869 #
11. ccheshirecat ◴[29 Jun 25 15:54 UTC] No.44414075[source]▶
This is a fantastic and fundamental question. We evaluated OpenStack, and it's an incredibly powerful and comprehensive project. For us, it came down to two things: complexity and opinionation. Complexity: OpenStack is a massive suite of services designed to do everything for everyone. We needed to do one thing exceptionally well: provide high-performance, dedicated-core VMs with a dead-simple control plane. The operational overhead of running a full OpenStack cluster felt like using a sledgehammer to crack a nut for our specific, focused use case. Opinionation: We have very strong opinions about how the user experience should feel (e.g., the simple slider for scaling, the transparent pricing unit). Building our own control plane allowed us to bake those opinions directly into the product from the ground up, without fighting the "OpenStack way" of doing things. It let us focus obsessively on the user-facing API and CLI experience. It was definitely a harder path in the short term, but it's given us the freedom to build exactly the lean, fast, and user-friendly platform we envisioned.
12. ccheshirecat ◴[29 Jun 25 15:56 UTC] No.44414086[source]▶
You read our minds. We agree that offering non-traditional payment methods is important. We just finished integrating support for cryptocurrency payments. Still having issues with a lot of coins but most of the common ones are there and XMR works fine just tested it, BTC as well.
13. mdaniel ◴[29 Jun 25 17:41 UTC] No.44414869{3}[source]▶
> (i.e., take a snapshot of a configured VM and use it as a base image for future deployments)

I would advise against that if possible, since the "reset" process for an already contaminated VM is much trickier than the "build-up" process for what one would think of as a template. That's actually why `docker build` exists when `docker save` already exists. I do recognize from your other comments that my mental model may not map onto your target audience, so my comments are always "for your consideration" and not wagging my finger at your choices

If you were to choose to go with "build up," there are already so many specifications for that template construction process you could choose any one of them that you think would work well for your audience: Containerfile[1], Dockerfile, Packer, AWS Image Builder, and probably hundreds of others

1: relevant: bootc-image-builder: Build your entire OS from a Containerfile - https://news.ycombinator.com/item?id=44367004 - June, 2025 (27 comments)