Infrastructure
Introduction
The purpose of these documents is to provide an overview of the infrastructure used to operate the Mastodon server, vmst.io. It should explain how the various services interact and how "the magic" happens when our users open the Mastodon app on their phone or enter our address into their web browser.
It should also help provide some assurance to our current and potential members that care has been taken in architecting and operating this Mastodon instance.
Architecture Goals
- Provide better than 99.9% availability each month for our users.
- All critical components should be easily recoverable in the event of failure.
- Be easily scalable, both vertically and horizontally.
- Provide a highly performant experience for our users.
- Don't operate what we're not best suited to operating.
- Automate as much as possible for upgrades to enable the fastest time to implementation.
- Maintain a stable endpoint on the ActivityPub network.
Layout
Core Services
DigitalOcean is our primary hosting provider. We have workloads and data hosted in the TOR1, NYC3, and SFO3 data centers. Toronto is the home of our primary computing workloads, while New York is used for object storage hosting of the media CDN and documentation site. San Francisco houses regular backups while an additional replicated copy is located in Kansas City.
Required Components
The following reflect the required software components to have a functional deployment of Mastodon:
Additional Components
Most Mastodon deployments leverage one or more additional components to provide additional functionality.
Some of them include:
Core Elements
Virtual Machines
We use an all-virtual architecture using DigitalOcean "Droplets" as Kubernetes nodes. These Droplets are provisioned automatically by the Kubernetes control plane. There are typically multiple nodes with 4 vCPUs and 8 GB of memory each. The total number of nodes can be scaled up or down based on overall demand.
Kubernetes
We use the DigitalOcean managed Kubernetes service.