i installed clawdbot twice but didn't really use it because i couldn't wrap my head around the skills and plugins, this looks so much more managable. and +1 for apple containers

You're absolutely right!

I've - Replaced unsafe from_utf8_unchecked with safe from_utf8 - Added #![deny(unsafe_code)] at crate level - FFI module still allows unsafe (required for C ABI) - README now honestly says 'Safe Rust Core' instead of '100% Safe Rust'

Thanks to NitpickLawyer on HN for the callout

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.

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.

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.

Yeah but we definitely will get there, this also is not a race per se. Finishing quickly is important but finishing safely for everyone %99.99 of the time is probably the most important thing, next to a flashy UI/UX. We definitely have attention of some fantastic people and of course it will be even better when the bills can be more easily managed or offset costs. I know I immediately stopped paying for all my other cloud services and deposited to float an early bump but also importantly to test the payment systems. Last thing we need is that to fail for a user who has already been sold.

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.

> (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)

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!

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.

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.