Self hosting an M4 Mini for production apps with AI Infrastructure
In a world of custom cloud infrastructures and myriad architectures tailored to every demand, one might wonder why hosting outside the cloud even makes sense. What about data redundancy, power and internet reliability, latency, and global availability? Well, in most cases, traditional cloud setups win—but considering the vague cloud costs and lack of clarity, a non-cloud solution can work, depending on your needs. Especially now with GPU compute being so limited and expensive.
Recently, I had the chance to migrate a production app from Digital Ocean/AWS to an M4 Mini and the results have been impressive so far and we haven't felt the need to go back to cloud hosting just yet.
What are we hosting and what are the requirements?
This is probably the most important part, The application handles 10-20k requests per hour, with a subset directed to our AI models. The front end is Nextjs with a backend handled by a self hosted Supabase instance and yet another server that deals with the rest of ancillary tasks. This setup also powers the Android and iOS apps. Besides this there is a realtime WebRTC component that requires a TURN server as a fallback for directing the real time traffic in case there is no peer to peer connection between the clients. The app has an audience that is mostly sourced from a particular geographical region but it does have traffic coming in from around the world.
At first glance, this seems like easy pickings for a base M4 Mini—and it is: it barely uses 10-20% of the CPU, and temperatures stay in the 46-50°C range even during bursts of AI traffic, which it handles with ease. However, getting it to that point—making it robust enough for production while also delivering a great developer experience—was interesting enough to document.
Basic Setup
To begin with, you need a robust data ingress gateway complete with firewalls and security measures. We also opted for a static IP to simplify hosting; we chose an Omada ER605 for its features, though Ubiquiti routers are a solid alternative.
Once your data ingress is set up, the next step is to update your domain’s DNS so that your new IP address is pointed to—typically by configuring A records.
Internet & Power redundancy
Internet redundancy is straightforward: get a second connection, and your Omada ER605 or Ubiquiti router will automatically switch to the backup if the primary fails. We wrote a script to update our DNS whenever the network changes, though there are open-source solutions available too. The Mac Mini M4 is impressively efficient, averaging only 10-20 watts with occasional bursts for AI traffic, and we already had a simple backup power system that kept it running for several days. Depending on where you are, you can easily order an affordable backup system off of Amazon.
Local Setup & Security
Once your M4 Mini is connected, the first step is to assign it a static IP via your router and set up port forwarding for HTTP (80) and HTTPS (443). Since this exposes your M4 Mini to the internet, be sure to enable a firewall or other security measures to restrict traffic only to those two ports.
Mac isn't Linux
I wish it were—or at least natively supported. Running your apps on a Mac isn’t the smoothest experience; if you only have one or two apps to update manually, bare metal might work, but that gets old quickly. Without zero-downtime deployments, it becomes more of a hobby project rather than a robust production environment capable of handling team development cycles and deployments. Maybe it’s time to look into Docker and Kubernetes.
领英推荐
Linux Options on a mac
There are many options to run a docker environment on a mac including virtual machines. Here are some of them that we tried:
Backups
Nothing too complicated here, Backups are pretty straightforward: we store our code on GitHub and perform daily or hourly database backups to S3, overwriting older backups to maintain about a 7-day history. Of course, you can adjust these settings based on your specific needs. Mini is more than capable of being a CI/CD server as well.
Global Availability
This one was pretty simple, a CDN in front of your production environment and you are all set. We use Cloudfront and have relatively snappy performance depending on the CDN availability. This could be a limiting factor for self hosting though if your requirements are stringent or if you want to cater for global DB replicas. This was not an issue for us.
Extra Credit - Wireguard
This isn't necessary but it's nice to be able to enable Wireguard on your router to check in to log into your local network from anywhere in the world and check on the containers just like you would on your local network if you weren't traveling.
Cost Savings
This was't the main reason for the switch but it's interesting to note that the hosting costs went down from about $120-$150/month to about $4/month. I think the main draw certainly was a ton of GPU compute available locally that can be scaled over time and not be limited by the cloud for GPU compute. This opens up a ton of AI related possibilities for future feature development.
Conclusion - Was it worth it?
This will depend on your circumstances and what you are hosting, in our case it was a platform that needs to be run for the longer term and has already been running for over 5 years on Digital Ocean/AWS. I would like to imagine it like glacial storage tier on the S3, except that this is glacial hosting for longer term. So far so good, we have had over 99 percent uptime over the past 6 months and no one has noticed the switch, yet : )
Lastly, there are a ton of details that I have left out to condense this to a short writeup including details about Devops infrastructure but I will probably cover that in a future post.
Overall, it’s been totally worth it so far—I don’t see us going back. And if we ever do, I’ll definitely document why self-hosting just doesn’t cut it!