Your self-hosted, globally interconnected microblogging community
Mastodon
Mastodon is a free, open-source social network server. A decentralized alternative to commercial platforms, it avoids the risks of a single company monopolizing your communication. Anyone can run Mastodon and particip
Mastodon is a free, open-source social network server. A decentralized alternative to commercial platforms, it avoids the risks of a single company monopolizing your communication. Anyone can run Mastodon and participate in the social network seamlessly.
An alternative implementation of the GNU social project. Based on ActivityStreams, Webfinger, PubsubHubbub and Salmon.
Click on the screenshot to watch a demo of the UI:
Focus of the project on a clean REST API and a good user interface. Ruby on Rails is used for the back-end, while React.js and Redux are used for the dynamic front-end. A static front-end for public resources (profiles and statuses) is also provided.
Fully interoperable with GNU social and any OStatus platform Whatever implements Atom feeds, ActivityStreams, Salmon, PubSubHubbub and Webfinger is part of the network
Real-time timeline updates See the updates of people you're following appear in real-time in the UI via WebSockets
Federated thread resolving If someone you follow replies to a user unknown to the server, the server fetches the full thread so you can view it without leaving the UI
Media attachments like images and WebM Upload and view images and WebM videos attached to the updates
OAuth2 and a straightforward REST API Mastodon acts as an OAuth2 provider so 3rd party apps can use the API, which is RESTful and simple
Background processing for long-running tasks Mastodon tries to be as fast and responsive as possible, so all long-running tasks that can be delegated to background processing, are
Deployable via Docker You don't need to mess with dependencies and configuration if you want to try Mastodon, if you have Docker and Docker Compose the deployment is extremely easy
Configuration
LOCAL_DOMAIN should be the domain/hostname of your instance. This is absolutely required as it is used for generating unique IDs for everything federation-related
LOCAL_HTTPS set it to true if HTTPS works on your website. This is used to generate canonical URLs, which is also important when generating and parsing federation-related IDs
HUB_URL should be the URL of the PubsubHubbub service that your instance is going to use. By default it is the open service of Superfeedr
Consult the example configuration file, .env.production.sample for the full list. Among other things you need to set details for the SMTP server you are going to use.
Requirements
PostgreSQL
Redis
Neo4J (optional)
GraphAware NodeRank
Running with Docker and Docker-Compose
The project now includes a Dockerfile and a docker-compose.yml. You need to turn .env.production.sample into .env.production with all the variables set before you can:
docker-compose build
And finally
docker-compose up -d
As usual, the first thing you would need to do would be to run migrations:
docker-compose run --rm web rails db:migrate
And since the instance running in the container will be running in production mode, you need to pre-compile assets:
docker-compose run --rm web rails assets:precompile
The container has two volumes, for the assets and for user uploads. The default docker-compose.yml maps them to the repository's public/assets and public/system directories, you may wish to put them somewhere else. Likewise, the PostgreSQL and Redis images have data containers that you may wish to map somewhere where you know how to find them and back them up.
Note: The --rm option for docker-compose will remove the container that is created to run a one-off command after it completes. As data is stored in volumes it is not affected by that container clean-up.
Tasks
rake mastodon:media:clear removes uploads that have not been attached to any status after a while, you would want to run this from a periodic cronjob
rake mastodon:push:clear unsubscribes from PuSH notifications for remote users that have no local followers. You may not want to actually do that, to keep a fuller footprint of the fediverse or in case your users will soon re-follow
rake mastodon:push:refresh re-subscribes PuSH for expiring remote users, this should be run periodically from a cronjob and quite often as the expiration time depends on the particular hub of the remote user
rake mastodon:feeds:clear removes all timelines, which forces them to be re-built on the fly next time a user tries to fetch their home/mentions timeline. Only for troubleshooting
rake mastodon:graphs:sync re-imports all follow relationships into Neo4J. Only for troubleshooting
Running any of these tasks via docker-compose would look like this:
docker-compose run --rm web rake mastodon:media:clear
Updating
This approach makes updating to the latest version a real breeze.
git pull
To pull down the updates, re-run
docker-compose build
And finally,
docker-compose up -d
Which will re-create the updated containers, leaving databases and data as is. Depending on what files have been updated, you might need to re-run migrations and asset compilation.
Contributing
You can open issues for bugs you've found or features you think are missing. You can also submit pull requests to this repository. This section may be updated with more details in the future.
A lot of people seem to be jumping on https://mastodon.social right now, even though the end goal is to have users separated out across multiple federated instances. However, if people start putting up a lot of content and getting followers on the primary instance, this will be a disincentive to move providers.
I think this largely means that Mastodon needs to support two things:
Account import across providers, which should be authenticated on both ends to prevent people bulk copying another person's account, and
A "redirected account" field against user accounts, which indicates the full URL of the new user account
When users configure a redirect location against their account (whether explicitly on an account page, or implicitly set during a cross-provider account import), the instance on which the account is should implicitly and automatically redirect followers.
That is, if I have the account @hq on the primary instance (which I do), and I set up the account @hach-que on another Mastodon service, the @hq should:
Remain on the primary instance, and not be disabled in any way
Show posts from @hach-que after the redirection is set up
Disallow posting from the @hq account while ever the redirection is in place
Existing followers of @hq should start seeing posts from @hach-que instead
New followers of @hq should be allowed to follow the account (and internally, they are following @hq, but see posts from @hach-que)
Followers should not actually have their lists updated to follow @hach-que - in the event of a mistaken redirect, removing the redirect should act exactly as if there never was a redirect in the first place
This is just my 2c on how I think this should work, but I'm interested to hear other people's thoughts.
The question of a new logo has been already brought up a few times.
This thread is here to gather propositions and have a central place where we can discuss this. Maybe at some point, all design related discussions and files could end up in their own repo. But let's first see how this goes.
Safari SVG tab icon look (to have an idea of the small sizes):
Here is the suggestion by @Gargron of what the new logo could be.
In order to have a clear process about this collaborative design approach, maybe we should start by throwing propositions and rough sketches along the guidelines provided by @Gargron.
And see where we go from there.
Looking forward to work with you all.
[x] I searched or browsed the repo’s other issues to ensure this is not a duplicate.
On these local copies, Mastodon can perform operations like resizing, optimizing, creating thumbnails that fit Mastodon's UI - because the origin of the content can provide media in super large sizes that would severely impact end-user's bandwidth and browser performance if just displayed verbatim.
Moreover, bandwidth is not always cheap - it is capped to something like 1TB/mo on DigitalOcean, and is super expensive on Amazon S3, so hotlinking images and videos would severily impact owners of small instances, when lots of users of large instances would view their content from their public timelines (or even just home timelines through boosts). It does feel fair that an instance's admin is responsible for serving content to their own users, rather than also to users of other instances, which should be their admins' responsibilities.
However, this has storage and legal implications. I would like to hear your thoughts on how this can be improved.
Currently, you have to be following an account in order to be able to add it to a list. One of my primary use cases for lists is to follow bots that post news or media feeds. It would be nice to be able to follow such accounts without adding noise to the timeline, and lists would be an ideal solution for that.
[X] I searched or browsed the repo’s other issues to ensure this is not a duplicate.
One oddity here: the fixture file is a tar.gz where the contents are just one png file that the process will open up and save as a custom emoji record. On the one hand, this is similar to other fixture stuff we do, on the other hand this seems sort of weird. The other ideas I had were to just put the png in fixtures and then build the gz in a before block in the spec or something like that.
This is a bugfix release for the 4.2.0 version, if you're installing from an earlier version, please check the 4.2.0 release notes as they contain important information on how to update.
:warning: We recently released important security updates.
If you don't want or can't update to 4.2.x yet, the security updates are also available for the 4.1.x branch, the 4.0.x branch and the 3.5.x branch.
Changelog
Added
Add redirection on /deck URLs for logged-out users (ClearlyClaire)
Add support for v4.2.0 migrations to tootctl maintenance fix-duplicates (ClearlyClaire)
Changed
Change some worker lock TTLs to be shorter-lived (ClearlyClaire)
Change user archive export allowed period from 7 days to 6 days (suddjian)
Fixed
Fix clicking on already-opened thread post scrolling to the top of the thread (ClearlyClaire, ClearlyClaire)
Fix some remote posts getting truncated (ClearlyClaire)
Fix some cases of infinite scroll code trying to fetch inaccessible posts in a loop (ClearlyClaire)
Fix Vary headers not being set on some redirects (ClearlyClaire)
Fix mentions being matched in some URL query strings (mjankowski)
Fix unexpected linebreak in version string in the Web UI (vmstan)
Fix double scroll bars in some columns in advanced interface (ClearlyClaire)
Fix boosts of local users being filtered in account timelines (ClearlyClaire)
Fix multiple instances of the trend refresh scheduler sometimes running at once (ClearlyClaire)
Fix incorrectly keeping outdated update notices absent from the API endpoint (ClearlyClaire)
Fix import progress not updating on certain failures (ClearlyClaire)
Fix websocket connections being incorrectly decremented twice on errors (ThisIsMissEm)
Fix explore prompt appearing because of posts being received out of order (ClearlyClaire)
Fix explore prompt sometimes showing up when the home TL is loading (ClearlyClaire)
Fix link handling of mentions in user profiles when logged out (ClearlyClaire)
Fix filtering audit log for entries about disabling 2FA (ClearlyClaire)
Fix notification toasts not respecting reduce-motion (c960657)
Fix retention dashboard not displaying correct month (vmstan)
Fix tIME chunk not being properly removed from PNG uploads (TheEssem)
Fix division by zero in video in bitrate computation code (ClearlyClaire)
Fix inefficient queries in “Follows and followers” as well as several admin pages (ClearlyClaire, ClearlyClaire)
Fix ActiveRecord using two connection pools when no replica is defined (ClearlyClaire)
Fix the search documentation URL in system checks (renchap)
Upgrade notes
To get the code for v4.2.1, use git fetch && git checkout v4.2.1.
As always, make sure you have backups of the database before performing any upgrades. If you are using docker-compose, this is how a backup command might look: docker exec mastodon_db_1 pg_dump -Fc -U postgres postgres > name_of_the_backup.dump
Dependencies
External dependencies have not changed since v4.2.0, the compatible Ruby, PostgreSQL, Node, Elasticsearch and Redis versions are the same, that is:
Ruby: 3.0 to 3.2
PostgreSQL: 10 or newer
Elasticsearch (recommended, for full-text search): 7.x (OpenSearch should also work)
LibreTranslate (optional, for translations): 1.3.3 or newer
Redis: 4 or newer
Node: 16 or newer
ImageMagick: 6.9.7-7 or newer
If your uploaded images are broken after the upgrade, it means your installed ImageMagick version is older than the new minimum version (6.9.7-7), for example if you are running Ubuntu 18.04. If this happens, you can find more information and ways to fix it on this page.
Update steps
The following instructions are for updating from 4.2.0.
If you are upgrading directly from an earlier release, please carefully read the upgrade notes for the skipped releases as well, as they often require extra steps such as database migrations.
Non-Docker only:
Install dependencies: bundle install and yarn install --frozen-lockfile
Precompile the assets: RAILS_ENV=production bundle exec rails assets:precompile
:warning: We recently released important security updates, so if you are still using a 4.2.0 pre-release, 4.1.7 or below, 4.0.9 or below, or 3.5.13 or below, please update as soon as possible (see the release notes for v4.1.8).
Changelog
Changed
Change some worker lock TTLs to be shorter-lived (ClearlyClaire)
Change user archive export allowed period from 7 days to 6 days (suddjian)
Fixed
Fix mentions being matched in some URL query strings (mjankowski)
Fix multiple instances of the trend refresh scheduler sometimes running at once (ClearlyClaire)
Fix filtering audit log for entries about disabling 2FA (ClearlyClaire)
Fix tIME chunk not being properly removed from PNG uploads (TheEssem)
Fix inefficient queries in “Follows and followers” as well as several admin pages (ClearlyClaire, ClearlyClaire)
Upgrade notes
To get the code for v4.1.10, use git fetch && git checkout v4.1.10.
As always, make sure you have backups of the database before performing any upgrades. If you are using docker-compose, this is how a backup command might look: docker exec mastodon_db_1 pg_dump -Fc -U postgres postgres > name_of_the_backup.dump
Dependencies
External dependencies have not changed compared to v4.1.7, the compatible Ruby, PostgreSQL, Node, Elasticsearch and Redis versions are the same, that is:
Ruby: 2.7 to 3.0
PostgreSQL: 9.5 or newer
Elasticsearch (optional, for full-text search): 7.x
Redis: 4 or newer
Node: >= 14, < 18
ImageMagick: 6.9.7-7 or newer
If your uploaded images are broken after the upgrade, it means your installed ImageMagick version is older than the new minimum version (6.9.7-7), for example if you are running Ubuntu 18.04. If this happens, you can find more information and ways to fix it on this page.
Update steps
The following instructions are for updating from 4.1.9.
If you are upgrading directly from an earlier release, please carefully read the upgrade notes for the skipped releases as well, as they often require extra steps such as database migrations.
Non-Docker only:
Install dependencies: bundle install and yarn install --frozen-lockfile
:warning: The 4.0.x branch will not receive any update—including security fixes—after 2023-10-31.
:warning: We recently released important security updates, so if you are still using a 4.2.0 pre-release, 4.1.7 or below, 4.0.9 or below, or 3.5.13 or below, please update as soon as possible (see the release notes for v4.0.10).
End of life notice
The 4.0.x branch will not receive any update after 2023-10-31.
This means that no security fix will be made available for this branch after this date, and you will need to update to a more recent version (such as the 4.1.x branch) to receive security fixes.
Changelog
Changed
Change some worker lock TTLs to be shorter-lived (ClearlyClaire)
Change user archive export allowed period from 7 days to 6 days (suddjian)
Fixed
Fix mentions being matched in some URL query strings (mjankowski)
Fix multiple instances of the trend refresh scheduler sometimes running at once (ClearlyClaire)
Fix filtering audit log for entries about disabling 2FA (ClearlyClaire)
Fix tIME chunk not being properly removed from PNG uploads (TheEssem)
Fix inefficient queries in “Follows and followers” as well as several admin pages (ClearlyClaire, ClearlyClaire)
Upgrade notes
To get the code for v4.0.12, use git fetch && git checkout v4.0.12.
As always, make sure you have backups of the database before performing any upgrades. If you are using docker-compose, this is how a backup command might look: docker exec mastodon_db_1 pg_dump -Fc -U postgres postgres > name_of_the_backup.dump
Dependencies
External dependencies have not changed compared to v4.0.9, the compatible Ruby, PostgreSQL, Node, Elasticsearch and Redis versions are the same, that is:
Ruby: 2.7 to 3.0
PostgreSQL: 9.5 or newer
Elasticsearch (optional, for full-text search): 7.x
Redis: 4 or newer
Node: >= 14, < 18
ImageMagick: 6.9.7-7 or newer
If your uploaded images are broken after the upgrade, it means your installed ImageMagick version is older than the new minimum version (6.9.7-7), for example if you are running Ubuntu 18.04. If this happens, you can find more information and ways to fix it on this page.
Update steps
The following instructions are for updating from 4.0.11.
If you are upgrading directly from an earlier release, please carefully read the upgrade notes for the skipped releases as well, as they often require extra steps such as database migrations.
Non-Docker only:
Install dependencies: bundle install and yarn install --frozen-lockfile
:warning: The 3.5.x branch will not receive any update—including security fixes—after 2023-12-31.
:warning: We recently released important security updates, so if you are still using a 4.2.0 pre-release, 4.1.7 or below, 4.0.9 or below, or 3.5.13 or below, please update as soon as possible (see the release notes for v3.5.14).
End of life notice
The 3.5.x branch will not receive any update after 2023-12-31.
This means that no security fix will be made available for this branch after this date, and you will need to update to a more recent version (such as the 4.1.x branch) to receive security fixes.
Changelog
Changed
Change user archive export allowed period from 7 days to 6 days (suddjian)
Fixed
Fix mentions being matched in some URL query strings (mjankowski)
Fix filtering audit log for entries about disabling 2FA (ClearlyClaire)
Fix tIME chunk not being properly removed from PNG uploads (TheEssem)
Fix inefficient queries in “Follows and followers” as well as several admin pages (ClearlyClaire, ClearlyClaire)
Upgrade notes
To get the code for v3.5.15, use git fetch && git checkout v3.5.15.
As always, make sure you have backups of the database before performing any upgrades. If you are using docker-compose, this is how a backup command might look: docker exec mastodon_db_1 pg_dump -Fc -U postgres postgres > name_of_the_backup.dump
Dependencies
External dependencies have not changed compared to v3.5.13, the compatible Ruby, PostgreSQL, Node, Elasticsearch and Redis versions are the same, that is:
Ruby: 2.7 to 3.0
PostgreSQL: 9.5 or newer
Elasticsearch (optional, for full-text search): 7.x
Redis: 4 or newer
Node: >= 12.22, < 18
ImageMagick: 6.9.7-7 or newer
If your uploaded images are broken after the upgrade, it means your installed ImageMagick version is older than the new minimum version (6.9.7-7), for example if you are running Ubuntu 18.04. If this happens, you can find more information and ways to fix it on this page.
Update steps
The following instructions are for updating from 3.5.14.
If you are upgrading directly from an earlier release, please carefully read the upgrade notes for the skipped releases as well, as they often require extra steps such as database migrations.
Non-Docker only:
Install dependencies: bundle install and yarn install --frozen-lockfile
We are excited to release Mastodon 4.2.0, our next major upgrade 🎉
In this version, we've added (opt-in) search for posts, along with a refined set of privacy options where users can decide whether to have their content indexed for discovery. There are also many other small improvements across the user interface that come together to make everything much more polished and smooth to get started.
:warning: We recently released important security updates.
If you don't want or can't update to 4.2.0 yet, the security updates are also available for the 4.1.x branch, the 4.0.x branch and the 3.5.x branch.
Upgrade overview
This release contains upgrade notes that deviate from the norm:
ℹ️ Requires streaming API restart
ℹ️ Requires database migrations
ℹ️ Starting from this release, Mastodon will periodically check for updates (see below if you want to disable that behavior)
:warning: Requires rebuilding Elasticsearch indexes
:warning: The minimal supported version for Ruby has been bumped to 3.0
:warning: The minimal supported version for Node.js has been bumped to 16
:warning: The minimal supported version for PostgreSQL has been bumped to 10. Please note that using PostgreSQL 10 or 11 is deprecated and will not be supported in 4.3.0.
:warning: The minimal supported version for LibreTranslate has been bumped to 1.3.3
:warning: The way database replicas are configured has changed
:warning: Disables part of the StatsD integration by default
:warning: Drops built-in clustering support from the streaming server
:warning: Updated systemd unit files for the streaming server
:warning: We will stop bundling PgHero in a future release
For more information, scroll down to the upgrade instructions section.
Changelog
The following changelog entries focus on changes visible to users, administrators, client developers or federated software developers, but there has also been a lot of code modernization, refactoring, and tooling work, in particular by @danielmbrasil, @mjankowski, @nschonni, @renchap, and @takayamaki.
Add admin notifications for new Mastodon versions (ClearlyClaire)
This is done by querying https://api.joinmastodon.org/update-check every 30 minutes in a background job.
That URL can be changed using the UPDATE_CHECK_URL environment variable, and the feature outright disabled by setting that variable to an empty string (UPDATE_CHECK_URL=).
Add “Privacy and reach” tab in profile settings (Gargron, ClearlyClaire)
This reorganized scattered privacy and reach settings to a single place, as well as improve their wording.
Add ability to pick domains to forward reports to using the forward_to_domains parameter in POST /api/v1/reports (ClearlyClaire, ClearlyClaire)
The forward_to_domains REST API parameter is a list of strings. If it is empty or omitted, the previous behavior is maintained.
The forward parameter still needs to be set for forward_to_domains to be taken into account.
The forwarded-to domains can only include that of the original author and people being replied to.
Add forwarding of reported replies to servers being replied to (Gargron, ClearlyClaire)
Add ONE_CLICK_SSO_LOGIN environment variable to directly link to the Single-Sign On provider if there is only one sign up method available (CSDUMMI, ClearlyClaire, CSDUMMI, ClearlyClaire)
Add DELETE /api/v1/profile/avatar and DELETE /api/v1/profile/header to the REST API (danielmbrasil, ClearlyClaire)
Add ES_PRESET option to customize numbers of shards and replicas (Gargron, ClearlyClaire)
This can have a value of single_node_cluster (default), small_cluster (uses one replica) or large_cluster (uses one replica and a higher number of shards).
Add data-nosnippet so Google doesn't use trending posts in snippets for / (ClearlyClaire)
Add card with who invited you to join when displaying rules on sign-up (ClearlyClaire)
Add missing primary keys to accounts_tags and statuses_tags (ClearlyClaire)
Add support for custom sign-up URLs (ClearlyClaire, renchap, ClearlyClaire, mgmn)
This is set using SSO_ACCOUNT_SIGN_UP and reflected in the REST API by adding registrations.sign_up_url to the /api/v2/instance endpoint.
Add polling and automatic redirection to /start on email confirmation (ClearlyClaire)
Add ability to block sign-ups from IP using the CLI (danielmbrasil)
Add ALT badges to media that has alternative text in web UI (Gargron, c960657
Change user archive export to be faster and more reliable, and export .zip archives instead of .tar.gz ones (ClearlyClaire, TheEssem)
Change mastodon-streaming systemd unit files to be templated (e-nomem)
Change statsd integration to disable sidekiq metrics by default (mjankowski, mjankowski, ClearlyClaire)
This deprecates statsd support and disables the sidekiq integration unless STATSD_SIDEKIQ is set to true.
This is because the nsa gem is unmaintained, and its sidekiq integration is known to add very significant overhead.
Later versions of Mastodon will have other ways to get the same metrics.
Change replica support to native Rails adapter (krainboltgreene, Gargron, Gargron, Gargron, Gargron, ClearlyClaire, ClearlyClaire, ClearlyClaire, ClearlyClaire)
This is a breaking change, dropping makara support, and requiring you to update your database configuration if you are using replicas.
To tell Mastodon to use a read replica, you can either set the REPLICA_DB_NAME environment variable (along with REPLICA_DB_USER, REPLICA_DB_PASS, REPLICA_DB_HOST, and REPLICA_DB_PORT, if they differ from the primary database), or the REPLICA_DATABASE_URL environment variable if your configuration is based on DATABASE_URL.
Change DCT method used for JPEG encoding to float (electroCutie)
Change from node-redis to ioredis for streaming (gmemstr)
Change private statuses index to index without crutches (ClearlyClaire)
Change log-out to use Single Logout when using external log-in through OIDC (CSDUMMI)
Change sidekiq-bulk's batch size from 10,000 to 1,000 jobs in one Redis call (ClearlyClaire)
Change translation to only be offered for supported languages (c960657, c960657)
This adds the /api/v1/instance/translation_languages REST API endpoint that returns an object with the supported translation language pairs in the form:
{
"fr": ["en", "de"]
}
(where fr is a supported source language and en and de or supported output language when translating a fr string)
Change compose form checkbox to native input with appearance: none (ClearlyClaire)
Change posts' clickable area to be larger (c960657)
Change followed_by link to location=all if account is local on /admin/accounts/:id page (tribela)
Fix missing loading spinner and loading more on scroll in Private Mentions column (c960657)
Fix account header image missing from /settings/profile on narrow screens (c960657)
Fix height of announcements not being updated when using reduced animations (c960657)
Fix inconsistent radius in advanced interface drawer (thislight)
Fix loading more trending posts on scroll in the advanced interface (OmmyZhang)
Fix poll ending notification for edited polls (c960657)
Fix max width of media in /about and /privacy-policy (mgmn)
Fix streaming API not being usable without DATABASE_URL (Gargron)
Fix external authentication not running onboarding code for new users (ClearlyClaire)
Upgrade notes
To get the code for v4.2.0, use git fetch && git checkout v4.2.0.
As always, make sure you have backups of the database before performing any upgrades. If you are using docker-compose, this is how a backup command might look: docker exec mastodon_db_1 pg_dump -Fc -U postgres postgres > name_of_the_backup.dump
Dependencies
External dependencies have changed since v4.1.7, with the Ruby, PostgreSQL and Node.js minimum version being higher.
Ruby: 3.0 to 3.2
PostgreSQL: 10 or newer
Elasticsearch (recommended, for full-text search): 7.x (OpenSearch should also work)
LibreTranslate (optional, for translations): 1.3.3 or newer
Redis: 4 or newer
Node: 16 or newer
ImageMagick: 6.9.7-7 or newer
If your uploaded images are broken after the upgrade, it means your installed ImageMagick version is older than the new minimum version (6.9.7-7), for example if you are running Ubuntu 18.04. If this happens, you can find more information and ways to fix it on this page.
Database replica configuration
The way Mastodon handles read replicas has changed, removing the makara gem and using native Rails support instead.
This changes how database replicas are configured. Instead of editing config/database.yml, you should use an unmodified one and use the REPLICA_DB_NAME, along with REPLICA_DB_USER, REPLICA_DB_PASS, REPLICA_DB_HOST and REPLICA_DB_PORT, if they differ from the primary database.
If you are using DATABASE_URL, you can configure your read replica in a similar way using REPLICA_DATABASE_URL.
StatsD integration
We have identified the current implementation of the StatsD integration for sidekiq to cause a lot of overhead. Therefore, we have disabled it by default, but since we do not have an alternative yet, it is still available by setting the following environment variable: STATSD_SIDEKIQ=true.
Please note that StatsD integration is deprecated and will not be supported in 4.3.0.
Streaming server changes
We have dropped built-in clustering support from the streaming server, which means, depending on the load you are facing, that you may need to run multiple instances of it and configure a load-balancer.
Unless you are using Docker, it is recommended that you update your mastodon-streaming unit scripts with the ones we provide:
If you then need to run more than one mastodon-streaming server, you can:
Start a new instance with sudo systemctl start mastodon-streaming@port (e.g. mastodon-streaming@4001)
Edit your nginx configuration file to add the new server to the load-balancing (an example is provided in the comments in dist/nginx.conf)
Automatic update checking
Starting from this release, Mastodon will periodically check for updates by querying https://api.joinmastodon.org/update-check every 30 minutes in a background job.
That URL can be changed using the UPDATE_CHECK_URL environment variable, and the feature outright disabled by setting that variable to an empty string (UPDATE_CHECK_URL=).
Update steps
The following instructions are for updating from 4.1.9.
If you are upgrading directly from an earlier release, please carefully read the upgrade notes for the skipped releases as well, as they often require extra steps such as database migrations.
Non-Docker only:
If you are using rbenv, update the list of available versions and install Ruby 3.2.2 by doing RUBY_CONFIGURE_OPTS=--with-jemalloc rbenv install in the Mastodon install directory (e.g. /home/mastodon/live)
Install dependencies: bundle install and yarn install --frozen-lockfile
Precompile the assets: RAILS_ENV=production bundle exec rails assets:precompile
Run the pre-deployment database migrations by specifying the SKIP_POST_DEPLOYMENT_MIGRATIONS=true environment variable: SKIP_POST_DEPLOYMENT_MIGRATIONS=true RAILS_ENV=production bundle exec rails db:migrate
Restart all Mastodon processes
Run the post-deployment database migrations: RAILS_ENV=production bundle exec rails db:migrate
If you use Elasticsearch, rebuild the search indexes with RAILS_ENV=production bin/tootctl search deploy --reset-chewy
Using Docker:
Run the pre-deployment database migrations by specifying the SKIP_POST_DEPLOYMENT_MIGRATIONS=true environment variable: docker-compose run --rm -e SKIP_POST_DEPLOYMENT_MIGRATIONS=true web bundle exec rails db:migrate
Restart all Mastodon processes
Run the post-deployment database migrations: docker-compose run --rm web bundle exec rails db:migrate
If you use Elasticsearch, rebuild the search indexes with docker-compose run --rm web bin/tootctl search deploy --reset-chewy
This release addresses an issue that was introduced by the last security update and includes changelogs for both updates.
:warning: This is a follow-up to the important 4.1.8 security update that fixed major security issues (CVE-2023-42451, CVE-2023-42452).
Corresponding security releases are available for the 4.0.x branch and the 3.5.x branch.
If you are using nightly builds, do not use this release but update to nightly.2023-09-20 or newer instead. If you are on the main branch, update to the latest commit.
Fix post edits not being forwarded as expected (ClearlyClaire)
Fix moderator rights inconsistencies (ClearlyClaire)
Fix crash when encountering invalid URL (ClearlyClaire)
Fix cached posts including stale stats (ClearlyClaire)
Fix uploading of video files for which ffprobe reports 0/0 average framerate (NicolaiSoeborg)
Fix unexpected audio stream transcoding when uploaded video is eligible to passthrough (yufushiro)
Security
Fix missing HTML sanitization in translation API (CVE-2023-42452, GHSA-2693-xr3m-jhqr)
Fix incorrect domain name normalization (CVE-2023-42451, GHSA-v3xf-c9qf-j667)
Upgrade notes
To get the code for v4.1.9, use git fetch && git checkout v4.1.9.
As always, make sure you have backups of the database before performing any upgrades. If you are using docker-compose, this is how a backup command might look: docker exec mastodon_db_1 pg_dump -Fc -U postgres postgres > name_of_the_backup.dump
Dependencies
External dependencies have not changed compared to v4.1.7, the compatible Ruby, PostgreSQL, Node, Elasticsearch and Redis versions are the same, that is:
Ruby: 2.7 to 3.0
PostgreSQL: 9.5 or newer
Elasticsearch (optional, for full-text search): 7.x
Redis: 4 or newer
Node: >= 14, < 18
ImageMagick: 6.9.7-7 or newer
If your uploaded images are broken after the upgrade, it means your installed ImageMagick version is older than the new minimum version (6.9.7-7), for example if you are running Ubuntu 18.04. If this happens, you can find more information and ways to fix it on this page.
Update steps
The following instructions are for updating from 4.1.7 or 4.1.8.
If you are upgrading directly from an earlier release, please carefully read the upgrade notes for the skipped releases as well, as they often require extra steps such as database migrations.
Non-Docker only:
Install dependencies: bundle install and yarn install --frozen-lockfile
The Recipe app keeps track of all your recipes, ingredients, and inventory. It will allow you to save ingredients, keep track of what you have, create recipes, and generate a shopping list based on what you have and what you are missing from a recipe.
