Infrastructure
Introduction
The purpose of these documents are 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% availablity 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 datacenters. Toronto is the home of our primary computing workloads, while New York and San Fransisco are used for object storage hosting and data backups.
AWS is also used for some services, hosted from the Ohio datacenter region.
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 dedicated vCPU 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.