GoKawiilAn Analysis of GrapheneOS's Server Infrastructure
GrapheneOS has a well-earned reputation for serious security work. Cellebrite — the forensics company law enforcement pays to crack phones — [publicly lists GrapheneOS as one of the few Android devices it cannot extract data from](https://discuss.techlore.tech/t/claims-made-by-forensics-companies-their-capabilities-and-how-grapheneos-fares/8653). The kernel hardening, the memory allocator, the sandboxing — these are real and they work. If you're running GrapheneOS, your phone is genuinely more secure than almost anything else available. But GrapheneOS is more than a phone OS. It's a project with servers, infrastructure, and an organisation behind it. And when you look closely at that infrastructure — which is [publicly available on GitHub](https://github.com/GrapheneOS/infrastructure) — a picture emerges that's harder to square with the project's stated values than most users realise. This isn't an attack on GrapheneOS. It's what you find when you actually read the code. --- ## Who Actually Runs This GrapheneOS was founded by Daniel Micay, who goes by `thestinger` online. In 2023, after a prolonged period of public conflict with other members of the privacy community — including [accusing Louis Rossmann of being "complicit in attempted murder" for leaving a YouTube comment](https://privatephoneshop.com/why-we-no-longer-sell-phones-with-grapheneos/) — Micay announced he was stepping down as lead developer and Foundation director. [Canadian federal corporate records still listed him as a director as of late 2025](https://factually.co/fact-checks/technology/who-runs-grapheneos-after-daniel-micay-14e426) — two and a half years after the announcement. The infrastructure repository's [FUNDING.yml](https://github.com/GrapheneOS/infrastructure/blob/main/.github/FUNDING.yml) lists his personal GitHub account (`thestinger`) as the sole funding recipient. The server config files contain his personal dotfiles: his editor theme (gruvbox for Neovim), his shell preferences, his keyboard bindings. The production mail server has `mutt` and `s-nail` installed — command-line email clients that you install when you personally read mail directly on the server. [GrapheneOS themselves report around 400,000 active users](https://en.wikipedia.org/wiki/GrapheneOS). One person's personal setup serves all of them. --- ## The Servers: What They Actually Run GrapheneOS publishes their server configuration as open source — that part is genuinely commendable. Reading it reveals some surprising choices. **Arch Linux, everywhere.** Every server, from the massive dedicated boxes to the smallest DNS nodes, runs Arch Linux. You can verify this directly: every package list in the repo includes `pacman-contrib` and `pacutils`, which are Arch-specific tools that don't exist on any other distribution. The [`deploy-initial-vps` script](https://github.com/GrapheneOS/infrastructure/blob/main/deploy-initial-vps) also explicitly checks for the Arch ISO before doing anything: `ssh $remote '[[ $(grep IMAGE_ID /etc/os-release) = "IMAGE_ID=archlinux" ]]'`. Arch is a rolling-release distribution — updates arrive continuously rather than in stable, tested batches. Most security-conscious server operators use something like Debian (slow, predictable, heavily tested) or Alpine (tiny and hardened). Arch on a server is unusual enough that it raises eyebrows. To be fair: they do use the LTS kernel on every machine, which is the slower-moving stable kernel rather than the bleeding edge. That mitigates the biggest concern. But the rest of the userspace still rolls forward continuously, with no immutability and no verified boot — which is the opposite of how they approach the phone OS. **Full installs for everything, including DNS.** A DNS server has one job: answer "what's the IP address for this domain?" It needs almost nothing to do that. GrapheneOS's DNS nodes come with Neovim, Fish shell, htop, mtr, nmap, strace, iperf, and the full Arch package manager. The [package list for a basic DNS node](https://github.com/GrapheneOS/infrastructure/tree/main/packages) has 42 entries. The phone OS philosophy is to strip everything unnecessary to reduce attack surface. The server philosophy is to install the full toolkit everywhere because it's convenient. These are contradictory positions. **Containers that aren't really containers.** Some services — the DNS secondary nodes and mail server — run inside containers, which are meant to be isolated, minimal environments. GrapheneOS's containers contain a complete Arch Linux installation, including the package manager itself. They're bootstrapped using `pacstrap`, the same tool used to install Arch from scratch onto bare metal. The only difference from a standalone server is that the container has no kernel and no bootloader — everything else is identical. The [hosts that run containers](https://github.com/GrapheneOS/infrastructure/blob/main/hosts.sh) have `arch-install-scripts` installed (which provides `pacstrap`), and nowhere else does. --- ## The Cloudflare DNS Contradiction This one is genuinely hard to explain. GrapheneOS runs [over 40 DNS servers across 16 locations worldwide](https://grapheneos.org/articles/grapheneos-servers). DNS is the internet's address book — when your phone checks for an update, it first asks a DNS server "what's the IP address for releases.grapheneos.org?" Rather than outsourcing that to Cloudflare or Amazon, GrapheneOS built their own global DNS network, complete with anycast routing (a technology that automatically directs your request to the nearest server) and a custom geographic routing system. This is serious, expensive infrastructure, and the implicit reason for building it is independence from third parties who could see your query patterns or manipulate responses. Then look at [`etc/unbound/unbound.conf`](https://github.com/GrapheneOS/infrastructure/blob/main/etc/unbound/unbound.conf) in the same repository: ``` forward-zone: name: "." forward-tls-upstream: yes forward-addr: 1.1.1.1@853#cloudflare-dns.com forward-addr: 1.0.0.1@853#cloudflare-dns.com ``` Every GrapheneOS server has a local DNS resolver (Unbound) that's configured not to resolve queries itself, but to forward them to Cloudflare's servers over an encrypted connection. This means Cloudflare sees the DNS query patterns of every GrapheneOS server — what domains they look up, when, and how often. This is the same project that [left their French hosting provider in late 2025](https://www.datacenterdynamics.com/en/news/grapheneos-migrates-workloads-off-of-ovh-cites-issues-with-frances-digital-privacy-policy/) citing surveillance concerns, and that built an entire global DNS network to avoid third-party dependency. No explanation for the Cloudflare forwarding appears anywhere in their public documentation. --- ## The Jurisdiction Question The OVH departure was covered pretty widely. GrapheneOS [announced they were leaving their French hosting provider](https://lemmy.ml/post/39430289) because France supports "Chat Control" — proposed EU legislation that would require scanning private messages. The framing was principled: France isn't safe for a privacy project. What got less attention is where the servers moved to. The forum, Matrix chat server, Mastodon instance, and attestation service are now hosted on [netcup servers in Manassas, Virginia](https://grapheneos.org/articles/grapheneos-servers). Netcup is a German company, which sounds meaningful, but these particular servers are in the United States. US jurisdiction comes with National Security Letters (which can demand data and forbid the recipient from telling anyone), FISA courts, and a surveillance apparatus that is, by most measures, more expansive than the French legislation they objected to. Whether this was a pragmatic necessity of moving quickly or simply wasn't thought through, it sits awkwardly next to the narrative that was presented at the time. --- ## The Bus Factor "Bus factor" is a slightly morbid way of asking how many people would need to be unavailable before a project fails. For GrapheneOS, the honest answer based on available evidence is: one. The OS update signing keys — the cryptographic credentials that prove an update genuinely comes from GrapheneOS and hasn't been tampered with — are held on [air-gapped local machines outside their server infrastructure](https://grapheneos.org/articles/grapheneos-servers). That's good practice. But those machines are controlled by the same person whose dotfiles run the servers, whose personal GitHub account is the funding recipient, and who [Canadian corporate records show is still a Foundation director](https://factually.co/fact-checks/technology/who-runs-grapheneos-after-daniel-micay-14e426) despite stepping down. When Micay stepped down in 2023, he said signing infrastructure would be ["replicated in multiple locations and verified against each other"](https://lemmy.ca/post/568614). There's no public evidence this has happened. The infrastructure repository still reflects a single person's deployment scripts pushing to servers they control. The OS itself would survive. Verified boot means existing installations can't be silently compromised even if every server were taken over. But the ability to ship new security patches — which GrapheneOS does frequently and which is central to why it's worth running — depends on infrastructure and keys that appear to live with one person. --- ## What This Actually Means None of this means stop using GrapheneOS. The phone security is real and largely independent of all of this. Verified boot, the Titan chip, the hardened memory allocator — these work regardless of what's happening on the servers. The practical concerns are more specific: The community infrastructure — forum, Matrix, the places users go for help and discussion — sits in US jurisdiction on infrastructure with no demonstrated redundancy or succession plan. A legal demand, a health crisis, or Micay simply walking away could create a serious disruption. The Cloudflare DNS forwarding is a real privacy inconsistency for a project that explicitly built infrastructure to avoid exactly this kind of third-party visibility. It's not hidden — it's in a public config file — but it's unexplained. The governance framing of "GrapheneOS Foundation with a board of directors" implies more collective oversight than the evidence supports. Based on what's publicly visible, this is closer to one person's project that happens to serve 400,000 users than a meaningfully distributed organisation. --- ## The Odd Gap What makes GrapheneOS unusual is how sharp the contrast is between how rigorously they think about the phone OS and how pragmatically they've built everything around it. On the phone: adversarial thinking, minimal surface, assume everything is hostile. On the servers: one person's preferred tools, full installs everywhere, choices that sometimes work against stated principles. Micay is a mobile security researcher who has done genuinely important work. The infrastructure looks like what you get when someone very good at one thing builds the supporting systems around it themselves, without applying the same adversarial rigour to the scaffolding. GrapheneOS is still the best option for a security and privacy conscious Android phone — that's not really in question. But "best available" and "without meaningful caveats" are different things, and the privacy community tends to treat GrapheneOS as the latter when it's really the former. The OS earns its reputation. The project around it is more complicated. --- *All claims in this article are based on GrapheneOS's own public repositories, official documentation, and public statements. Primary sources are linked inline.*