Mastodon
  • What is Mastodon?
  • Using Mastodon
    • Signing up for an account
    • Setting up your profile
    • Posting to your profile
    • Using the network features
    • Dealing with unwanted content
    • Promoting yourself and others
    • Set your preferences
    • More settings
    • Using Mastodon externally
    • Moving or leaving accounts
    • Running your own server
  • Running Mastodon
    • Preparing your machine
    • Installing from source
    • Configuring your environment
    • Configuring full-text search
    • Installing optional features
      • Object storage
      • Onion services
      • Captcha
      • Single Sign On
    • Setting up your new instance
    • Using the admin CLI
    • Upgrading to a new release
    • Backing up your server
    • Migrating to a new machine
    • Scaling up your server
    • Moderation actions
    • Troubleshooting errors
      • Database index corruption
    • Roles
  • Developing Mastodon apps
    • Getting started with the API
    • Playing with public data
    • Obtaining client app access
    • Logging in with an account
    • Libraries and implementations
  • Contributing to Mastodon
    • Technical overview
    • Setting up a dev environment
    • Code structure
    • Routes
    • Bug bounties and responsible disclosure
  • Spec compliance
    • ActivityPub
    • WebFinger
    • Security
    • Microformats
    • OAuth
    • Bearcaps
  • REST API
    • Datetime formats
    • Guidelines and best practices
    • OAuth Tokens
    • OAuth Scopes
    • Rate limits
  • API Methods
    • apps
      • oauth
      • emails
    • accounts
      • bookmarks
      • favourites
      • mutes
      • blocks
      • domain_blocks
      • filters
      • reports
      • follow_requests
      • endorsements
      • featured_tags
      • preferences
      • followed_tags
      • suggestions
      • tags
    • profile
    • statuses
      • media
      • polls
      • scheduled_statuses
    • timelines
      • conversations
      • lists
      • markers
      • streaming
    • grouped notifications
    • notifications
      • push
    • search
    • instance
      • trends
      • directory
      • custom_emojis
      • announcements
    • admin
      • accounts
      • canonical_email_blocks
      • dimensions
      • domain_allows
      • domain_blocks
      • email_domain_blocks
      • ip_blocks
      • measures
      • reports
      • retention
      • trends
    • proofs
    • oembed
  • API Entities
    • Account
    • AccountWarning
    • Admin::Account
    • Admin::CanonicalEmailBlock
    • Admin::Cohort
    • Admin::Dimension
    • Admin::DomainAllow
    • Admin::DomainBlock
    • Admin::EmailDomainBlock
    • Admin::Ip
    • Admin::IpBlock
    • Admin::Measure
    • Admin::Report
    • Announcement
    • Appeal
    • Application
    • Context
    • Conversation
    • CustomEmoji
    • DomainBlock
    • Error
    • ExtendedDescription
    • FamiliarFollowers
    • FeaturedTag
    • Filter
    • FilterKeyword
    • FilterResult
    • FilterStatus
    • IdentityProof
    • Instance
    • List
    • Marker
    • MediaAttachment
    • Notification
    • NotificationPolicy
    • NotificationRequest
    • Poll
    • Preferences
    • PreviewCard
    • PreviewCardAuthor
    • PrivacyPolicy
    • Quote
    • Reaction
    • Relationship
    • RelationshipSeveranceEvent
    • Report
    • Role
    • Rule
    • ScheduledStatus
    • Search
    • ShallowQuote
    • Status
    • StatusEdit
    • StatusSource
    • Suggestion
    • Tag
    • TermsOfService
    • Token
    • Translation
    • V1::Filter
    • V1::Instance
    • V1::NotificationPolicy
    • WebPushSubscription

Migrating to a new machine

Copying your Mastodon installation to a new server without losing anything.

    • Basic steps
    • Detailed steps
      • Stop the Mastodon services
      • What data needs to be migrated
      • Dump and load PostgreSQL
      • Copy files
      • During migration
      • After migrating

Sometimes, for various reasons, you may want to migrate your Mastodon instance from one server to another. Fortunately, this is not too difficult of a process, although it may result in some downtime.

This guide was written with Ubuntu Server in mind; your mileage may vary for other setups.

Basic steps

  1. Set up a new Mastodon server using the Production Guide (however, don’t run mastodon:setup and only leave the PostgreSQL service running).
  2. Stop Mastodon on the old server (e.g. systemctl stop 'mastodon-*.service').
  3. Dump and load the PostgreSQL database using the instructions below.
  4. Copy the system/ files using the instructions below. (Note: if you’re using S3, you can skip this step.)
  5. Copy the .env.production file.
  6. Save the Redis database, stop the Redis service on both your old and new machines, and copy the Redis database from /var/lib/redis/ to the new server.
  7. Run RAILS_ENV=production bundle exec rails assets:precompile to compile Mastodon
  8. Start Mastodon and Redis on the new server.
  9. Run RAILS_ENV=production ./bin/tootctl feeds build to rebuild the home timelines for each user.
  10. Run RAILS_ENV=production ./bin/tootctl search deploy to rebuild your Elasticsearch indices (Note: if you are not using Elasticsearch, you can skip this step.)
  11. Update your DNS settings to point to the new server.
  12. Update or copy your Nginx configuration, and re-run LetsEncrypt as necessary.
  13. Enjoy your new server!

Detailed steps

Stop the Mastodon services

systemctl stop 'mastodon-*.service'

What data needs to be migrated

At a high level, you’ll need to copy over the following:

  • The ~/live/public/system directory, which contains user-uploaded images and videos (if using S3, you don’t need this)
  • The PostgreSQL database (using pg_dump)
  • The ~/live/.env.production file, which contains server config and secrets
  • The Redis database in the /var/lib/redis/ directory, which contains unproccessed Sidekiq jobs.

Less crucially, you’ll probably also want to copy the following for convenience:

  • The nginx config (under /etc/nginx/sites-available/mastodon)
  • The SSL certificates for your domain (under /etc/letsencrypt/live/ if using LetsEncrypt)
  • The systemd config files (/etc/systemd/system/mastodon-*.service), which may contain your server tweaks and customizations
  • The PgBouncer configuration under /etc/pgbouncer (if you’re using it)

Dump and load PostgreSQL

Instead of running mastodon:setup, we’re going to create an empty PostgreSQL database using the template0 database (which is useful when restoring a PostgreSQL dump, as described in the pg_dump documentation).

If you are using a password for your PostgreSQL user, you may want to configure the mastodon user on your new system to use the same password as your old system for convenience:

sudo -u postgres psql  
ALTER USER mastodon WITH PASSWORD 'YOUR_PASSWORD';  
\q

Run this as the mastodon user on your old system:

pg_dump -Fc mastodon_production -f backup.dump

Copy the backup.dump file over, using rsync or scp. Then on the new system, create an empty database as the mastodon user:

createdb -T template0 mastodon_production

Then import it (replace # in -j# with the number of CPUs in your system to improve restore performance):

pg_restore -Fc -j# -U mastodon -n public --no-owner --role=mastodon \
  -d mastodon_production backup.dump

(Note that if the username is not mastodon on the new server, you should change the -U AND --role values above. It’s okay if the username is different between the two servers.)

Copy files

This will probably take some time, and you’ll want to avoid re-copying unnecessarily, so using rsync is recommended. On your old machine, as the mastodon user, run:

rsync -avz ~/live/public/system/ mastodon@example.com:~/live/public/system/

You’ll want to re-run this if any of the files on the old server change.

You should also copy over the .env.production file, which contains secrets.

On your new machine, ensure that Redis is not running, otherwise it may overwrite the dump file you are trying to restore. As the root user, run:

systemctl stop redis-server.service

Now copy your Redis database over (adjust the location of your Redis database as needed). On your old machine, as the root user, run:

redis-cli SAVE
systemctl stop redis-server.service
rsync -avz /var/lib/redis/ root@example.com:/var/lib/redis

Optionally, you may copy over the nginx, systemd, and PgBouncer config files, or rewrite them from scratch.

During migration

You can edit the ~/live/public/500.html page on the old machine if you want to show a nice error message to let existing users know that a migration is in progress.

You’ll probably also want to set the DNS TTL to something small (30-60 minutes) about a day in advance, so that DNS can propagate quickly once you point it to the new IP address.

After migrating

Run the following commands as your mastodon user:

RAILS_ENV=production bundle exec rails assets:precompile  

Now run the following commands as your root user:

systemctl daemon-reload
systemctl start redis-server  
systemctl enable --now mastodon-web mastodon-sidekiq mastodon-streaming  
systemctl restart nginx

Once your server is back online, you can rebuild the home feeds for users (this can take a long time depending on the number of users.)

RAILS_ENV=production ./bin/tootctl feeds build

If you use Elasticsearch, run the following command to rebuild the indices (this can take a long time depending on the number of statuses you have.)

RAILS_ENV=production ./bin/tootctl search deploy

You can check whatsmydns.net to see the progress of DNS propagation. To jumpstart the process, you can always edit your own /etc/hosts file to point to your new server so you can start playing around with it early.

Last updated January 23, 2025 · Improve this page
Also available in: 简体中文

Sponsored by

Dotcom-Monitor LoadView Stephen Tures Swayable SponsorMotion

Join Mastodon · Blog ·

View source · CC BY-SA 4.0 · Imprint