GrapheneOS confirms it is migrating part of its infrastructure to self-hosted systems

⏱️ Lectura: 9 min

GrapheneOS doesn’t use mastodon.social or any third-party instance to communicate: it runs its own Mastodon server at grapheneos.social. From that same account, the project recently posted that it’s well underway in the process of converting part of its internal infrastructure to self-hosted systems.

📑 En este artículo

1. TL;DR
2. What happened
3. Background and history
4. Technical details: how self-hosted infrastructure is maintained
5. How to start testing it
6. Impact and analysis
7. What’s next
8. Frequently Asked Questions
   1. What is grapheneos.social?
   2. What other infrastructure does GrapheneOS self-host?
   3. What exactly does “converting internal infrastructure” mean in this announcement?
   4. Do I need an account to query a Mastodon instance’s API?
   5. How much hardware do I need to self-host Mastodon?
   6. Why does a privacy-focused project like GrapheneOS prioritize self-hosted infrastructure?
9. References

The original message, as it remains publicly available, doesn’t specify which system is being migrated or when the process will finish. But the fact itself (a security and privacy project that prioritizes having full control over its own infrastructure) is consistent with how GrapheneOS has always operated, and it serves as a starting point to explain what self-hosting critical services means in 2026.

TL;DR

• GrapheneOS announced on its official Mastodon account that it’s well underway in the process of converting part of its internal infrastructure.
• The message was posted from grapheneos.social, the Mastodon instance that the project itself operates and manages.
• GrapheneOS already self-hosts several key services: its app repository at apps.grapheneos.org and its remote attestation server at attestation.app.
• The available source of the announcement doesn’t specify which system was converted or a completion date.
• Self-hosting a minimal Mastodon instance requires Docker, PostgreSQL, and Redis, with 2 vCPUs and 4 GB of RAM as a typical baseline.
• A self-hosted infrastructure strategy reduces single points of failure and dependence on third-party moderation or suspension.
• GrapheneOS’s case serves as a practical example for teams evaluating a move from centralized SaaS to self-hosting.

What happened

The announcement came from the project’s official communication channel on Mastodon, not from a blog post or press release. GrapheneOS uses that account for security advisories, Pixel compatibility updates, and, in this case, an operational update: the team said it’s well underway in converting part of its infrastructure to systems it manages directly.

This is a familiar pattern for the project: GrapheneOS is a nonprofit funded by donations that avoids relying on corporate infrastructure it doesn’t control, something already visible in three pieces of its current stack: the app repository, the remote attestation service, and the social network itself where it announces these changes.

Background and history

GrapheneOS started as CopperheadOS and built its reputation from the beginning on a simple principle: minimizing the trust surface. That applies to the operating system (kernel hardening, reinforced sandboxing, verified boot) but also to the infrastructure that supports the project on the outside.

Two already-established examples of that self-hosted infrastructure philosophy: the repository at apps.grapheneos.org, compatible with the F-Droid client, which distributes Auditor, Vanadium, and other first-party apps without going through Google Play or a third-party mirror; and attestation.app, the service that lets any Pixel running GrapheneOS cryptographically prove its boot state against a server the project operates end to end.

The fact that the announcements account also runs on its own server (grapheneos.social) instead of a generic instance closes that loop: no critical channel of the project depends on a third party that could suspend the account, change terms of service, or insert unwanted telemetry.

Technical details: how self-hosted infrastructure is maintained

Setting up and maintaining self-hosted infrastructure like GrapheneOS’s involves concrete architecture decisions. For a self-hosted Mastodon server, the minimal stack combines a reverse proxy, the Mastodon web process, the streaming process (for the real-time timeline), and two data stores: PostgreSQL for persistent state and Redis for queues and caching.

flowchart TD
    A["Mastodon Client"] --> B["Nginx (reverse proxy)"]
    B --> C["Mastodon Web"]
    B --> D["Streaming API"]
    C --> E[("PostgreSQL")]
    C --> F[("Redis")]
    D --> F
    subgraph Backend
    C
    D
    E
    F
    end

Before touching any configuration, it’s useful to see how a real instance responds. This first snippet queries the public API of grapheneos.social and returns the Mastodon version it’s running:

curl -s https://grapheneos.social/api/v2/instance | jq '.version'

That command doesn’t require authentication or an account: any Mastodon instance exposes its version and basic metadata by design, part of the ActivityPub protocol the network uses.

To spin up your own instance, the following block is a docker-compose.yml trimmed down to the three essential services (without separate background job queues, which in production should be isolated):

services:
  db:
    image: postgres:15-alpine
    restart: always
    environment:
      POSTGRES_USER: mastodon
      POSTGRES_PASSWORD: change_this_password
      POSTGRES_DB: mastodon_production
    volumes:
      - ./postgres:/var/lib/postgresql/data

  redis:
    image: redis:7-alpine
    restart: always
    volumes:
      - ./redis:/data

  web:
    image: tootsuite/mastodon:v4.3.0
    restart: always
    env_file: .env.production
    ports:
      - "3000:3000"
    depends_on:
      - db
      - redis

With those three services up (docker compose up -d), Mastodon listens on port 3000 behind your own proxy. The database and cache never leave your internal network, something you can’t guarantee with a centralized SaaS.

How to start testing it

To reproduce a minimal self-hosted infrastructure environment like the one GrapheneOS uses, the first step is having Docker running. Installation commands vary by operating system:

# Linux (Debian/Ubuntu)
curl -fsSL https://get.docker.com | sh

# macOS (with Homebrew)
brew install --cask docker

# Windows (with winget)
winget install Docker.DockerDesktop

Once Docker is installed and you have the docker-compose.yml from the previous example in a folder alongside a .env.production file with the keys generated by bin/tootctl (application secret, VAPID keys, and OTP credentials), the startup is:

docker compose up -d
docker compose exec web bin/tootctl accounts create admin --email [email protected] --confirmed --role Owner

To confirm the instance came up correctly, the same call we used earlier against grapheneos.social works against your own server:

curl -s http://localhost:3000/api/v1/instance | jq '.title, .version'

If the JSON returns the configured title and version, the instance is alive and federating according to the LOCAL_DOMAIN setting in .env.production.

⚠️ Heads up: a production Mastodon instance, with email delivery, backups, and real moderation, needs quite a bit more than this three-container stack: separate Sidekiq queues, media storage (S3 or dedicated disk), and a version upgrade plan. The example above is meant to explain the architecture, not to expose it to the internet without adjustments.

Impact and analysis

The difference between relying on a third-party platform and maintaining self-hosted infrastructure isn’t cosmetic. When GrapheneOS hosts its own remote attestation at attestation.app, the project controls the entire trust chain: there’s no intermediary that could change the result of a boot verification. The same applies to apps.grapheneos.org: being compatible with F-Droid, any client can verify package signatures without going through Google Play.

The trade-off is operational cost. Self-hosting means patching servers, monitoring uptime, paying for bandwidth, and absorbing traffic spikes without the cushion of a managed provider. For a project running on donations, that cost competes directly with development of the operating system itself.

Option	When to use it	Advantage	Limitation
Self-hosted Mastodon	When full control over data and moderation is a priority	No dependency on third parties or risk of external suspension	Requires its own maintenance, backups, and monitoring
Third-party Mastodon instance (e.g. mastodon.social)	When the goal is just having a presence, without operating servers	Zero maintenance, instant setup	Subject to a third party’s policies and availability
Network based on AT Protocol (e.g. Bluesky)	When identity portability between providers is a priority	The account and social graph are portable between hosts	Self-hosting ecosystem less mature than ActivityPub

💭 Key point: the same argument that leads GrapheneOS to run attestation.app instead of delegating it to a third party explains why it also hosts its own Mastodon: every piece of infrastructure you don’t control is a point where someone else can decide for you.

What’s next

The original message doesn’t specify a closing timeline for this infrastructure conversion, so what’s verifiable today is what the project already runs on its own: the app repository, the attestation server, and the Mastodon instance from which the announcement was made. Any additional detail about the specific system being migrated will depend on future official posts from the project on that same channel.

For development teams following this case as a reference, the logical next step is to audit which of their own services currently depend on third-party SaaS and evaluate, service by service, whether the operational cost of self-hosting is justified against the risk of depending on an external provider.

📖 Summary on Telegram: View summary

Try it yourself: run curl -s https://grapheneos.social/api/v2/instance | jq '.version' right now to see live the Mastodon instance that GrapheneOS runs on its own infrastructure.

Frequently Asked Questions

What is grapheneos.social?

It’s the Mastodon instance that GrapheneOS operates and manages directly, instead of using mastodon.social or any other third-party server for its official account.

What other infrastructure does GrapheneOS self-host?

At least two publicly documented pieces: the app repository at apps.grapheneos.org (compatible with F-Droid) and the remote attestation service at attestation.app.

What exactly does “converting internal infrastructure” mean in this announcement?

The publicly available message doesn’t specify the exact system or the migration’s destination; it only confirms that the process is well underway.

Do I need an account to query a Mastodon instance’s API?

No. Endpoints like /api/v2/instance are public by design of the ActivityPub protocol and don’t require authentication.

How much hardware do I need to self-host Mastodon?

For a small instance, the official documentation typically recommends 2 vCPUs and 4 GB of RAM as a baseline, plus disk space for PostgreSQL and media storage.

Why does a privacy-focused project like GrapheneOS prioritize self-hosted infrastructure?

Because it reduces the number of third parties that can make decisions about the availability, moderation, or data access of its own critical services.

References

• Original post on grapheneos.social: GrapheneOS’s official announcement about the internal infrastructure conversion.
• GrapheneOS (official site): project documentation and its security principles.
• GrapheneOS on GitHub: source code repositories for the operating system and its tools.
• Official Mastodon installation guide: reference documentation for self-hosting an instance.

📱 Do you like this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.

Imagen destacada: Foto de Albert Stoynov en Unsplash