I no longer maintain this fork. Over time, my patches and approach have diverged too much from upstream's, and I have decided to go for an ad-hoc chart/kustomization specifically for my instance instead of reusing a common one.
This is a Helm chart for installing Mastodon into a Kubernetes cluster. The basic usage is:
- edit
values.yaml
or create a separate yaml file for custom values helm dep update
helm install --namespace mastodon --create-namespace my-mastodon ./ -f path/to/additional/values.yaml
This chart is tested with k8s 1.21+ and helm 3.6.0+.
This chart is released as an OCI image to ghcr.io/mastodon/charts/mastodon
. You can install it without the need to add any repository to your helm installation using:
helm install mastodon oci://ghcr.io/mastodon/charts/mastodon --values your-values-file.yaml
You can also add it as a dependency to another chart in your Chart.yaml:
dependencies:
- name: mastodon
version: 4.0.0
repository: oci://ghcr.io/mastodon/charts
The variables that must be configured are:
-
password and keys in the
mastodon.secrets
,postgresql
, andredis
groups; if left blank, some of those values will be autogenerated, but will not persist across upgrades. -
SMTP settings for your mailer in the
mastodon.smtp
group.
If your PersistentVolumeClaim is ReadWriteOnce
and you're unable to use a S3-compatible service or
run a self-hosted compatible service like Minio
then you need to set the pod affinity so the web and sidekiq pods are scheduled to the same node.
Example configuration:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app.kubernetes.io/part-of
operator: In
values:
- rails
topologyKey: kubernetes.io/hostname
You can run admin CLI commands in the web deployment.
kubectl -n mastodon exec -it deployment/mastodon-web -- bash
tootctl accounts modify admin --reset-password
or
kubectl -n mastodon exec -it deployment/mastodon-web -- tootctl accounts modify admin --reset-password
Currently this chart does not support:
- Hidden services
- Swift
Because database migrations are managed as a Job separate from the Rails and Sidekiq deployments, it’s possible they will occur in the wrong order. After upgrading Mastodon versions, it may sometimes be necessary to manually delete the Rails and Sidekiq pods so that they are recreated against the latest migration.