All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Introducing BMAC - Build My App Cloud
So you've got your bare metal. Now what?
We built BMAC as tool to simplify taking blank machines and turning them into a usable harness for your webapps, with many of the advanced features you expect from the big cloud players but with the cost of your own hardware. BMAC is fully open-source and licensed under the GPLv3.
One of the main features we shot for was minimal-downtime during failures. You can't really do that with just a single machine, but with two machines in a cluster it's doable, and that's our basic config. But what happens with that second machine when it's just sitting there waiting to act as a failover host? Well we take full advantage of that second machine while the first one is busy hosting your webapp(s). The second machine has sync state of the production workload, so we leverage that synced-state on the standby host in order to be able to immediately spin-up staging VMs, without any extra copy, based on the FULL STATE of your production VM running on your production machine, but without affecting your production state at all. This means you get to test your new changes, in staging, against the actual full and true state of your production environment, database and all, without any extra wasted time and space making a copy. This is all thanks to the magic wizardy of how ZFS data can be sync'd across the hosts and how you can create Copy-on-Write (CoW) lightweight instant "linked clones" of a ZFS snapshot, which is how we pull this off on the standby host. It's an incredibly useful feature, and ensures that your standby host doesn't just sit there idle waiting for a failure event. Here are some diagrams to explain how this works.
BMAC just reached its v1.0.0 milestone, which means we're using it in production ourselves and we've fully tested all of its scripts for that release (tested from a Ubuntu x64 workstation - many of them do run on macOS though, but ideally you run these from a Debian-based x64 Linux environment). And BMAC is pretty opinionated about some of its requirements because ... well because we made it for ourselves. However it can be pointed at any random machines with NVMe drives and used to set them up, independent of our own requirements, so it's generically-useful even today.
If you want to get a better understand of how you can use BMAC in your scenario, I suggest you drop the project's URL into your favorite chatbot and ask it to help you to understand what it can do for you.
Here's the project. Hope it helps!
https://github.com/OtterFlip/bmac
Disclaimer: You'll notice we're using currently using FiberState to lease our dedicated bare-metal. We're not associated with them in any way other than being a customer, at the moment. But this explains why some aspects of BMAC discuss FiberState. It's definitely not necessary to use FiberState if you're using BMAC.
Comments
Great, I just need 1 VPS and Coolify/Dokploy.
Or maybe just raw dogging Docker/Proxmox on a Dedi.
Your software need 3 separated server and tons of other things brother.
Yeah, this is for folks who want fault-tolerance, high-availability, a minimal-downtime upgrade path, etc, while also managing the bare metal itself. It's an opinionated stack with a lot of features not everyone needs or wants.
Yes, but why make things 300% more complicated.
Totally fair question. If your requirements are satisfied by one VPS running Coolify/Dokploy, then you absolutely should do that. It's much simpler.
For us, there's a scaling cost curve that gets extremely expensive at scale, and by owning all your own hardware (especially if you're using refurb) you can cut down on the cost enormously. We calculated major savings not far out, actually. Each workload is different in the scaling requirements and so this isn't a fit for everyone. Probably not a fit for many. It's more for those who really need to manage the hardware itself.
And... it may be 300x more complicated, not 300%. lol
But hey, it's free, and it's out there, so y'know - you can take it or leave it and no harm done.
No offense mate, what I saw is complicating things. And I said it.
Yup, no argument here.
This is junk.
Nobody is going to waste time on this based on a wall of text and a couple of diagrams.
If you want to promote something like this, make a website/presentation with screenshots and/or a demo.
Or add it to: https://github.com/OtterFlip/DrugFreeSleep
That's healthy feedback, thanks. I've been thinking the same thing - that a comprehensive visual guide would really help. Along those lines I've also thought that wrapping all this functionality (there are over 20 workflows embodied in the scripts) in a GUI (perhaps a python-locally-hosted web UI) would make this more approachable.
You can think of this set of 20+ well-tested scripts (with ~400 unit tests, but also tested in real-life) as a library, where each script currently only accepts and emits human-readable input/output text. However this means it'll be trivial for me to add the option for each script to used structured inputs/outputs (I'll likely use NDJSON), which will make all these scripts machine-callable. Once they're machine-callable then I can wrap them with a desktop GUI. This will make the whole project much easier to use and to comprehend (hopefully fixing the 'wall of text' issue you pointed out). I'll work on this now.
Okay, as promised, I implemented a GUI to wrap the script library's functionality. I'm glad you guys pushed back on the complexity of the scripts because it was only a day's work to wrap it with a GUI and it made it a much more pleasant user-experience, even for me.
Here are some screenshots.
Little question. Why does the UI look like it was built by Shin Shan Shun 3.5
LOL. Well, it's a developer tool, not a beauty pageant.
I put the GUI together in a day to make the underlying functionality more accessible. I'm sure the aesthetics could use some refinement, but functionality and usability were the priorities. If you've got specific suggestions for improving it, I'm all ears.
Coolify : vps :: this : box ?
The can actually be complimentary, one managing the infrastructure, the other managing the app(s).