新たな更新（リリース）があったときには、自鯖をアップデートする必要が出てきます。
短期間のみの運用であればともかく、長期的に自鯖を運用する場合は、セキュリティ対策も含めてアップデートが必須となってきます。
ホスティングサービスを利用している場合
サービス側で自動的にアップデートしてくれます。
逆に言えば、サービス側が動いてくれない限り、アップデートはされません。
VPSなどを使って自力で運用している場合
アップデート作業も自力で行う必要があります。アップデート作業に失敗する例も多々あり、できれば作業前には前述したようにバックアップを確保することを強く推奨します。
大雑把な共通の動き
1.更新するべきこと（リリース）の有無を確認します。こまめに更新するのが一番ですが、特に久しぶりにアップデート作業を行うときは、絶対に更新履歴を全て遡り、リリースノートに目を通し、「本体の他に更新しないといけない背後のプログラム」など、本体の更新以外の作業を確認してください。これを怠ると、更新に失敗します。
2.できればアップデート作業を行うことを告知してください。うっかり何かのミスで更新に失敗したときに助けを求めやすくなったり、それ故に長期間サーバーが止まっていたとしても他のサーバーとのやり取りを切られずに済みます。
3.バックアップを確保しましょう。
4.各プログラムに定められた手順に沿ってアップデート作業を行います。
5.アップデートが無事に終われば、終わったことを報告すれば、より親切です。
Mastodon,kmyblueの場合
通常の更新作業は、概ね以下のとおりです。稀に大幅な変更がある場合は、リリースノートにて記されています。
1.（サーバーを止めたい場合は）サーバーを止めます。
sudo systemctl stop mastodon-web mastodon-sidekiq
2.更新内容の確認とソース変更を行います。
sudo su - mastodon
cd live
git fetch --tags
git checkout （定められた指定バージョン）
この時、gitがdetached HEADの状態であるとコメントが出ると思われますが、これについてはご自身で改造をしていなければ無視をしても問題のないことが多いものです。気になる方が多いとのことで、手順の済んだ後にどういうことかを書きます。
3.Rubyのバージョンアップがある場合は、このタイミングで実施します。
RUBY_CONFIGURE_OPTS=--with-jemalloc rbenv install （バージョン数字）
rbenv global （バージョン数字）
最初の行のコマンドを入れた段階で、今のVPSではそのバージョンがあることも分からなかったから、Ruby一覧の更新を行うようにと求められる場合があります。その場合は、作業画面内にある git （中略） pull の部分をコピー＆ペーストし、もう一度 RUBY_CONFIGURE_OPTS=--with-jemalloc rbenv install （バージョン数字） からやり直してください。
4.Rubyパッケージのアップデートを行います。
bundle install
5.JavaScriptパッケージのアップデートを行います。
yarn install
6.バージョンによって必要があれば、以下の作業を追加します。必要がなくても実行して問題はありません。
RAILS_ENV=production bin/rails db:migrate
RAILS_ENV=production bundle exec rails assets:precompile
7.作業用ユーザーに戻ります。
exit
8.サーバーを起動します。
sudo systemctl start mastodon-web mastodon-sidekiq
sudo systemctl restart mastodon-streaming
サーバーを止めていない場合は、再起動させます。
sudo systemctl restart mastodon-web mastodon-streaming mastodon-sidekiq
gitがdetached HEADの状態であるというコメントについて
gitというシステムを使うことでプログラムなどのバージョン管理ができますが、例えば同じプログラムで安定版と開発版を並行して取り扱いたいときに、ブランチという仕組みで枝分かれさせて管理していることが多いです。
もしプログラムの開発に関わっている場合は、このブランチを追いかけて、変更を取り入れたり提案したりします。
一方で、タグという、ここでバージョンを分けるよ！という目印となる仕組みもあり、Mastodonやkmyblueの公式サイトでは、このタグのついたまさにその瞬間のプログラムを自分のVPSに引っ張ってきて更新するようなコマンドを採用しています（ git checkout （バージョン名） 、が該当コマンドで、これを実行したらVPSの中でソースが置き換わっています）。
このコマンドの中には、どのブランチを追いかける、という情報は含まれていません。
ブランチを追いかけずに特定のバージョンだけをピンポイントで更新すると、その後、そのバージョンに変更を加えても、提案する先の情報がなく、変更の提案ができません。よって、gitから、ブランチの情報がないよ！とコメントが出されます。これがdetached HEADの正体です。
無改造の場合はコメントをスルーしていても問題ないことが多い、と前述しているのは、無改造の場合は、公式にタグで指定された更新を追いかけるだけで問題ないからです。
Bashスクリプトを利用してMisskeyを建てた場合
1.リリースノート内にMisskey本体の他に更新するべきプログラムがないか確認し、必要があればあらかじめ更新しておきます。
2.初めて更新を行う時は、アップデート用のスクリプトをダウンロードしてきます。
wget https://raw.githubusercontent.com/joinmisskey/bash-install/main/update.ubuntu.sh -O update.sh
3.アップデート用のスクリプトを実行します。
sudo bash update.sh
なお、このときにdockerではなくsystemd環境で構築していれば、 sudo bash update.sh -r にてシステムのアップデートと再起動も行うことができます。
手動でMisskeyを建てた場合
1.リリースノート内にMisskey本体の他に更新するべきプログラムがないか確認し、必要があればあらかじめ更新しておきます。
2.Misskeyを止めます。
sudo systemctl stop misskey
3.Misskey本体を更新します。
su - misskey
git pull; NODE_ENV=production; pnpm install --frozen-lockfile pnpm run clean; NODE_ENV=production pnpm run build; pnpm run migrate
exit
4.Misskeyを起動させます。
sudo systemctl start misskey
念のため、背後のプログラムを再度全て更新する場合は、この後の項目をご確認ください。
この場合、VPSを再起動した場合は、MisskeyはVPSの再起動後に自動で起動します。
背後で動いているプログラムたち
たまにこうしたプログラムの更新作業も必要になってきます。Ubuntuを含め、大半が apt コマンドでアップデートされていく場合が多いです。
sudo apt update -y
sudo apt full-upgrade -y
再起動を行う場合は、 sudo reboot で可能です。
PostgreSQL（ポストグレス キューエル）
オブジェクト関係データベース管理システムの一種です。サーバー内の様々な情報を保存するのに使われます。
少なくとも更新作業の前にはこのデーターベースのバックアップを行うのが無難です。
Redis
データベースや連合との通信を管理するなどの役割を持ちます。
Node.js
サーバー内でJavaScriptを扱うのに必要な環境です。背後で動いているプログラムの中では比較的頻回にセキュリティリリースが来ます。
これの更新で苦労しまくった初心者は、筆者だけではない筈。
node -v にてバージョン確認ができます。
インストール方法によっては apt で更新されますが、例えばnのようなNode.js用バージョン管理プログラムを導入していると、そのプログラムに沿った方法でのアップデートが必要です。
apt でピンポイントにNode.jsを更新する場合は、以下のコマンドを用います。
sudo apt update && sudo apt install nodejs
Ruby
Mastodonとkmyblueで使われているプログラミング言語です。
apt では更新されず、独自の手順が必要で、多少の時間が掛かります。前述のMastodon,kmyblueの更新についての項目で更新方法について述べています。
NGINX（エンジンエックス）、Certbot、Caddyなど
サーバーをブラウザから表示する時に必要です。
NGINX（エンジンエックス）を利用する場合はhttpsでの接続を行うためにCertbotなどでデジタル証明書を発行する必要がありますが、Caddyの場合は単体でもhttps接続ができるようです。
Certbotによるデジタル証明書はおよそ90日毎に更新が必要で、自動化されている場合も多いのですが、稀に自動化に失敗しているとサーバーの表示に不具合をきたします。
もしCertbotの証明書が切れた場合は、以下のコマンドを試してみましょう。
sudo certbot renew
オプション系の中で唯一手動更新の必要となってくるElasticsearch
Mastodon,kmyblueの全文検索オプションに使われるElasticsearchは、オプション系の中でほぼ唯一、アップデートを行う必要性が出てきます。
詳しくは、『ElasticsearchをMastodonとは別のサーバに設置する』（Fedibird管理人のえるさんによる2019年の忘備録）を読むのが安定でしょう。
https://blog.noellabo.jp/entry/2019/04/19/YNUL9UsohRgNKSya
Elasticsearchのプラグインはバージョンチェックが厳密で、本体のバージョンと完全一致したものを使う必要があり、毎回削除して入れ直しが必要です。
つまり、本体だけうっかりアップデートすると動かなくなりますので、普段は apt-mark でholdしておくこと（更新を差し押さえておくこと）が必要です。
https://github.com/WorksApplications/elasticsearch-sudachi/releases からanalysis-sudachiの最新リリースをチェックし、対応版がでてから切り替えるのが良いでしょう。
sudo /usr/share/elasticsearch/bin/elasticsearch-plugin remove analysis-sudachi
sudo apt-mark unhold elasticsearch
sudo apt install elasticsearch
sudo apt-mark hold elasticsearch
wget https://github.com/WorksApplications/elasticsearch-sudachi/releases/download/次のSudachiバージョンの数値/analysis-sudachi-elasticsearch7.何かしらの数字-次のバージョンの数値.zip←バージョンにより数字は変わります
sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install file:///home/（作業ユーザー名）/analysis-sudachi-elasticsearch7.何かしらの数字-次のバージョンの数値.zip←同上
sudo systemctl restart elasticsearch
Ubuntuについて
勿論、Ubuntu本体にもいつかは細かいアップデートではなく、大きなバージョンアップ（LTLから次のLTSへ）の必要な日が来ることでしょう。バグなどの報告がないか慎重に情報を集め、事前に条件の変更などがないかよく確認し、バックアップを行ってからのバージョンアップが良いでしょう。
コマンドそのものは、以下です。
sudo do-release-upgrade