ArmMini is built by iOS developers and SREs. We didn't launch a product and then go looking for customers — the 4 Mac minis we racked in 2021 were originally just running CI for our own apps. This page covers who we are, why we insist on dedicated physical machines, and how the hardware actually works.
The team is 7 people today: 3 iOS developers, 2 SREs, and 2 support engineers, spread across UTC+8 and UTC-8. Everyone has their own app or CI pipeline running on our own nodes, so when a machine has an issue, we usually get paged before our customers do — because our own builds turn red first.
That shapes our priorities: keep the machines stable, get credentials delivered fast, and make sure a stuck box can be restarted without waiting on us — everything else comes after that. Every troubleshooting step and every latency number on this site was measured on our own machines, not copied out of a spec sheet.
We've kept the team deliberately small. Seven people managing over a hundred machines isn't about working longer hours — it's about getting out-of-band power control, automated health checks, and self-service reimaging right the first time. We hold first-response times under two hours because 80% of issues get resolved by customers themselves in the portal, and only the rest need a human.
If you spend your days wrestling with Xcode, runners, and simulators, we'll probably get along. For specific questions, check the troubleshooting guide or reach out directly.
$ system_profiler SPHardwareDataType | grep Chip
Chip: Apple M4 Pro
$ uptime
14:32 up 217 days, load averages: 3.42 2.98 2.71
$ ops team --list
ios-dev x3 sre x2 support x2
coverage: UTC+8 / UTC-8
eating our own dogfood since 2021
all nodes healthySlicing one host into eight virtualized shares would look great on a margin spreadsheet. We didn't go that route, for three reasons — and none of them are negotiable.
macOS's license terms require the OS to run on Apple-branded hardware. One real Mac mini per customer is the cleanest, most defensible way to stay compliant; shared-slicing setups always sit in a licensing gray area, and we don't want your release pipeline built on top of one.
What kills CI isn't slowness, it's jitter. A physical node has no noisy neighbor fighting you for CPU or disk I/O — back-to-back full builds of the same project typically vary by under 3% (measured on our own projects). Predictable build times are what let you set queueing rules and timeout thresholds that actually hold up.
Virtualization layers still can't expose full Metal or Neural Engine access — MLX inference, Simulator GPU rendering, Final Cut hardware encoding either don't run at all in a VM or run at half speed. On a physical machine, nothing sits in between: you get exactly what the chip offers.
Three physical locations, and we designed the rack layout and turned every screw ourselves. Here's what each node actually looks like.
Our founding datacenter since 2021, and the default pick for East Asia. All three tiers are available to rent year-round, and our own CI runs here too.
Launched in 2024 to serve remote development in Northeast Asia. All three tiers are available at the Seoul node.
Launched in 2023, built for North American teams' CI runners and bandwidth-heavy workloads — like uploading large build artifacts to TestFlight.
The Mac mini was never designed for a rack, so we machined our own CNC aluminum trays: four units per 1U, front cable routing, and each machine slides out for a swap without touching its neighbors. It sounds minor, but it's the difference between a 5-minute hardware swap and a 50-minute one.
All three facilities run dual utility feeds plus UPS and diesel generator backup, with each rack wired to two independent PDUs. If either feed drops, the machines keep running without a blip. Zero power-related outages in the last 12 months.
Every machine is wired to its own switched PDU channel. If the system locks up completely, nobody has to walk into the datacenter — click Force Restart in the portal and the PDU cuts power and brings it back up, in about 40 seconds on average, even at 3 a.m.
Dedicated hardware means trust matters, and trust can't run on slogans alone. These four rules are page one of our internal runbook, and we're posting them here so you can hold us to them.
You're prompted to rotate every credential the moment a machine is delivered; we don't preinstall monitoring agents or leave ops accounts behind. Our health monitoring only looks at network and power metrics — whether the machine has power and network. What's running on it is something we neither know nor want to know.
Routine operations stop at the out-of-band layer — power, network, hardware. If we ever need to log into your system to help debug something, it requires your explicit authorization in a support ticket, is performed by a single on-duty engineer, and the full record is attached to that ticket. Without authorization, nobody touches a customer's machine.
Any incident affecting customers gets a public postmortem within 72 hours: root cause, blast radius, timeline, and remediation items, in full. It's written by the engineer who actually handled the incident, with no marketing polish applied. We're customers of our own infrastructure too, so we know exactly what a watered-down postmortem reads like.
Within 7 days of a machine being decommissioned or a customer offboarding, the full drive is wiped and a record is issued. Retired SSDs are cryptographically wiped end-to-end, then physically destroyed, with destruction certificates archived. Your code-signing certificates and private repo credentials never leave the datacenter in any form.
Talk is cheap, so here are numbers you can verify. Our methodology is below — feel free to question any of it in a support ticket.
Methodology: trailing 12 months as of Jul 2026; uptime is sampled at per-minute granularity and calculated per machine; delivery time is measured from successful payment to credentials-delivered email; first response is measured from ticket creation to first human reply.
No funding story here — just a track record of managing more and more machines over time.
Running CI for our own two apps. The first rack tray was 3D-printed — we still keep one as a memento.
A friend's team rented half our fleet to run GitHub Actions runners, and went three months without a single complaint. That's when we realized this could be a real business, and decided to take it seriously.
Self-service ordering, automated credential delivery, one-click restart and reimaging all shipped — delivery time dropped from half a day of manual work to under 10 minutes.
32 machines at launch, built for North American teams' CI needs. Around the same time, CNC aluminum trays became the standard across all five locations.
Filled in low-latency coverage for Northeast Asia; every machine gets its own switched PDU channel, and Force Restart goes from a support ticket request to a self-service button.
All three tiers unified on the M4 generation, with the online fleet passing 120 machines. Older hardware gets retired in batches, with drives handled through our destruction process.
We're hiring. The pace is remote, async-first, minimal meetings, and write-it-down-before-you-build-it.
Own automated health checks, out-of-band control, and the delivery pipeline across our three physical locations. You should be comfortable with both macOS and networking, able to handle a 3 a.m. page solo, and able to write a postmortem people can actually follow.
To apply: email support@armmini.com with "SRE Application" in the subject line. We'd rather read about the worst incident you've ever handled than a resume.
Handle connection, build, and networking issues coming in through support tickets, and feed recurring problems back into the troubleshooting guide. Ideally you've shipped your own app or set up a self-hosted runner, and you're comfortable working from the command line.
To apply: email support@armmini.com with "Support Engineer Application" in the subject line, and attach a troubleshooting writeup you've done.
Billed daily, credentials are delivered in about 10 minutes, and unused days are refunded within 7 days. Worst case, you're out one day's rent.