docs/Custom-Emoji.md

-# Custom emoji
-
-To add custom emoji:
-* Add the image file(s) to `priv/static/emoji/custom`
-* In case of conflicts: add the desired shortcode with the path to `config/custom_emoji.txt`, comma-separated and one per line
-* Force recompilation (``mix clean && mix compile``)
-
-Example:
-
-image files (in `/priv/static/emoji/custom`): `happy.png` and `sad.png`
-
-content of `config/custom_emoji.txt`:
-```
-happy, /emoji/custom/happy.png
-sad, /emoji/custom/sad.png
-```
-
-The files should be PNG (APNG is okay with `.png` for `image/png` Content-type) and under 50kb for compatibility with mastodon.

docs/Differences-in-MastodonAPI-Responses.md

-# Differences in Mastodon API responses from vanilla Mastodon
-
-A Pleroma instance can be identified by "<Mastodon version> (compatible; Pleroma <version>)" present in `version` field in response from `/api/v1/instance` 
-
-## Flake IDs
-
-Pleroma uses 128-bit ids as opposed to Mastodon's 64 bits. However just like Mastodon's ids they are sortable strings
-
-## Attachment cap
-
-Some apps operate under the assumption that no more than 4 attachments can be returned or uploaded. Pleroma however does not enforce any limits on attachment count neither when returning the status object nor when posting.
-
-## Timelines
-
-Adding the parameter `with_muted=true` to the timeline queries will also return activities by muted (not by blocked!) users.
-
-## Statuses
-
-Has these additional fields under the `pleroma` object:
-
-- `local`: true if the post was made on the local instance.
-- `conversation_id`: the ID of the conversation the status is associated with (if any)
-
-## Attachments
-
-Has these additional fields under the `pleroma` object:
-
-- `mime_type`: mime type of the attachment.
-
-## Accounts
-
-- `/api/v1/accounts/:id`: The `id` parameter can also be the `nickname` of the user. This only works in this endpoint, not the deeper nested ones for following etc.
-
-Has these additional fields under the `pleroma` object:
-
-- `tags`: Lists an array of tags for the user
-- `relationship{}`: Includes fields as documented for Mastodon API https://docs.joinmastodon.org/api/entities/#relationship
-- `is_moderator`: boolean, true if user is a moderator
-- `is_admin`: boolean, true if user is an admin
-- `confirmation_pending`: boolean, true if a new user account is waiting on email confirmation to be activated
-
-## Notifications
-
-Has these additional fields under the `pleroma` object:
-
-- `is_seen`: true if the notification was read by the user

docs/Message-Rewrite-Facility-configuration.md

-# Message Rewrite Facility configuration
-The Message Rewrite Facility (MRF) is a subsystem that is implemented as a series of hooks that allows the administrator to rewrite or discard messages.
-
-Possible uses include:
-
-* marking incoming messages with media from a given account or instance as sensitive
-* rejecting messages from a specific instance
-* removing/unlisting messages from the public timelines
-* removing media from messages
-* sending only public messages to a specific instance
-
-The MRF provides user-configurable policies.  The default policy is `NoOpPolicy`, which disables the MRF functionality.  Pleroma also includes an easy to use policy called `SimplePolicy` which maps messages matching certain pre-defined criterion to actions built into the policy module.  
-It is possible to use multiple, active MRF policies at the same time.
-
-## Quarantine Instances
-
-You have the ability to prevent from private / followers-only messages from federating with specific instances. Which means they will only get the public or unlisted messages from your instance.
-
-If, for example, you're using `MIX_ENV=prod` aka using production mode, you would open your configuration file located in `config/prod.secret.exs` and edit or add the option under your `:instance` config object. Then you would specify the instance within quotes.
-```
-config :pleroma, :instance,
-  [...]
-  quarantined_instances: ["instance.example", "other.example"]
-```
-
-## Using `SimplePolicy`
-
-`SimplePolicy` is capable of handling most common admin tasks.
-
-To use `SimplePolicy`, you must enable it.  Do so by adding the following to your `:instance` config object, so that it looks like this:
-
-```
-config :pleroma, :instance,
-  [...]
-  rewrite_policy: Pleroma.Web.ActivityPub.MRF.SimplePolicy
-```
-
-Once `SimplePolicy` is enabled, you can configure various groups in the `:mrf_simple` config object.  These groups are:
-
-* `media_removal`: Servers in this group will have media stripped from incoming messages.
-* `media_nsfw`: Servers in this group will have the #nsfw tag and sensitive setting injected into incoming messages which contain media.
-* `reject`: Servers in this group will have their messages rejected.
-* `federated_timeline_removal`: Servers in this group will have their messages unlisted from the public timelines by flipping the `to` and `cc` fields.
-
-Servers should be configured as lists.
-
-### Example
-
-This example will enable `SimplePolicy`, block media from `illegalporn.biz`, mark media as NSFW from `porn.biz` and `porn.business`, reject messages from `spam.com` and remove messages from `spam.university` from the federated timeline:
-
-```
-config :pleroma, :instance,
-  rewrite_policy: [Pleroma.Web.ActivityPub.MRF.SimplePolicy]
-
-config :pleroma, :mrf_simple,
-  media_removal: ["illegalporn.biz"],
-  media_nsfw: ["porn.biz", "porn.business"],
-  reject: ["spam.com"],
-  federated_timeline_removal: ["spam.university"]
-
-```
-
-### Use with Care
-
-The effects of MRF policies can be very drastic.  It is important to use this functionality carefully.  Always try to talk to an admin before writing an MRF policy concerning their instance.
-
-## Writing your own MRF Policy
-
-As discussed above, the MRF system is a modular system that supports pluggable policies.  This means that an admin may write a custom MRF policy in Elixir or any other language that runs on the Erlang VM, by specifying the module name in the `rewrite_policy` config setting.
-
-For example, here is a sample policy module which rewrites all messages to "new message content":
-
-```!elixir
-# This is a sample MRF policy which rewrites all Notes to have "new message
-# content."
-defmodule Site.RewritePolicy do
-  @behavior Pleroma.Web.ActivityPub.MRF
-
-  # Catch messages which contain Note objects with actual data to filter.
-  # Capture the object as `object`, the message content as `content` and the
-  # message itself as `message`.
-  @impl true
-  def filter(%{"type" => Create", "object" => {"type" => "Note", "content" => content} = object} = message)
-      when is_binary(content) do
-    # Subject / CW is stored as summary instead of `name` like other AS2 objects
-    # because of Mastodon doing it that way.
-    summary = object["summary"]
-
-    # Message edits go here.
-    content = "new message content"
-
-    # Assemble the mutated object.
-    object =
-      object
-      |> Map.put("content", content)
-      |> Map.put("summary", summary)
-
-    # Assemble the mutated message.
-    message = Map.put(message, "object", object)
-    {:ok, message}
-  end
-
-  # Let all other messages through without modifying them.
-  @impl true
-  def filter(message), do: {:ok, message}
-end
-```
-
-If you save this file as `lib/site/mrf/rewrite_policy.ex`, it will be included when you next rebuild Pleroma.  You can enable it in the configuration like so:
-
-```
-config :pleroma, :instance,
-  rewrite_policy: [
-    Pleroma.Web.ActivityPub.MRF.SimplePolicy,
-    Site.RewritePolicy
-  ]
-```
-
-Please note that the Pleroma developers consider custom MRF policy modules to fall under the purview of the AGPL.  As such, you are obligated to release the sources to your custom MRF policy modules upon request.
\ No newline at end of file

docs/Pleroma-API.md

-# Pleroma API
-
-Requests that require it can be authenticated with [an OAuth token](https://tools.ietf.org/html/rfc6749), the `_pleroma_key` cookie, or [HTTP Basic Authentication](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization).
-
-Request parameters can be passed via [query strings](https://en.wikipedia.org/wiki/Query_string) or as [form data](https://www.w3.org/TR/html401/interact/forms.html). Files must be uploaded as `multipart/form-data`.
-
-## `/api/pleroma/emoji`
-### Lists the custom emoji on that server.
-* Method: `GET`
-* Authentication: not required
-* Params: none
-* Response: JSON
-* Example response: `{"kalsarikannit_f":"/finmoji/128px/kalsarikannit_f-128.png","perkele":"/finmoji/128px/perkele-128.png","blobdab":"/emoji/blobdab.png","happiness":"/finmoji/128px/happiness-128.png"}`
-* Note: Same data as Mastodon API’s `/api/v1/custom_emojis` but in a different format
-
-## `/api/pleroma/follow_import`
-### Imports your follows, for example from a Mastodon CSV file.
-* Method: `POST`
-* Authentication: required
-* Params:
-    * `list`: STRING or FILE containing a whitespace-separated list of accounts to follow
-* Response: HTTP 200 on success, 500 on error
-* Note: Users that can't be followed are silently skipped.
-
-## `/api/pleroma/captcha`
-### Get a new captcha
-* Method: `GET`
-* Authentication: not required
-* Params: none
-* Response: Provider specific JSON, the only guaranteed parameter is `type` 
-* Example response: `{"type": "kocaptcha", "token": "whatever", "url": "https://captcha.kotobank.ch/endpoint"}`
-
-## `/api/pleroma/delete_account`
-### Delete an account
-* Method `POST`
-* Authentication: required
-* Params: 
-    * `password`: user's password
-* Response: JSON. Returns `{"status": "success"}` if the deletion was successful, `{"error": "[error message]"}` otherwise
-* Example response: `{"error": "Invalid password."}`
-
-## `/api/account/register`
-### Register a new user
-* Method `POST`
-* Authentication: not required
-* Params:
-    * `nickname`
-    * `fullname`
-    * `bio`
-    * `email`
-    * `password`
-    * `confirm`
-    * `captcha_solution`: optional, contains provider-specific captcha solution,
-    * `captcha_token`: optional, contains provider-specific captcha token
-    * `token`: invite token required when the registerations aren't public.
-* Response: JSON. Returns a user object on success, otherwise returns `{"error": "error_msg"}`
-* Example response:
-```
-{
-	"background_image": null,
-	"cover_photo": "https://pleroma.soykaf.com/images/banner.png",
-	"created_at": "Tue Dec 18 16:55:56 +0000 2018",
-	"default_scope": "public",
-	"description": "blushy-crushy fediverse idol + pleroma dev\nlet's be friends \nぷれろまの生徒会長。謎の外人。日本語OK. \n公主病.",
-	"description_html": "blushy-crushy fediverse idol + pleroma dev.<br />let's be friends <br />ぷれろまの生徒会長。謎の外人。日本語OK. <br />公主病.",
-	"favourites_count": 0,
-	"fields": [],
-	"followers_count": 0,
-	"following": false,
-	"follows_you": false,
-	"friends_count": 0,
-	"id": 6,
-	"is_local": true,
-	"locked": false,
-	"name": "lain",
-	"name_html": "lain",
-	"no_rich_text": false,
-	"pleroma": {
-		"tags": []
-	},
-	"profile_image_url": "https://pleroma.soykaf.com/images/avi.png",
-	"profile_image_url_https": "https://pleroma.soykaf.com/images/avi.png",
-	"profile_image_url_original": "https://pleroma.soykaf.com/images/avi.png",
-	"profile_image_url_profile_size": "https://pleroma.soykaf.com/images/avi.png",
-	"rights": {
-		"delete_others_notice": false
-	},
-	"screen_name": "lain",
-	"statuses_count": 0,
-	"statusnet_blocking": false,
-	"statusnet_profile_url": "https://pleroma.soykaf.com/users/lain"
-}
-```
-
-## `/api/pleroma/admin/`…
-See [Admin-API](Admin-API.md)
-
-## `/api/v1/pleroma/flavour/:flavour`
-* Method `POST`
-* Authentication: required
-* Response: JSON string. Returns the user flavour or the default one on success, otherwise returns `{"error": "error_msg"}`
-* Example response: "glitch"
-* Note: This is intended to be used only by mastofe
-
-## `/api/v1/pleroma/flavour`
-* Method `GET`
-* Authentication: required
-* Response: JSON string. Returns the user flavour or the default one.
-* Example response: "glitch"
-* Note: This is intended to be used only by mastofe
-
-## `/api/pleroma/notifications/read`
-### Mark a single notification as read
-* Method `POST`
-* Authentication: required
-* Params:
-    * `id`: notifications's id
-* Response: JSON. Returns `{"status": "success"}` if the reading was successful, otherwise returns `{"error": "error_msg"}`

docs/administration/CLI_tasks/config.md

+# Transferring the config to/from the database
+
+{! backend/administration/CLI_tasks/general_cli_task_info.include !}
+
+## Transfer config from file to DB.
+
+!!! note
+    You need to add the following to your config before executing this command:
+
+    ```elixir
+    config :pleroma, configurable_from_database: true
+    ```
+
+=== "OTP"
+
+    ```sh
+    ./bin/pleroma_ctl config migrate_to_db
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.config migrate_to_db
+    ```
+
+## Transfer config from DB to `config/env.exported_from_db.secret.exs`
+
+!!! note
+    In-Database configuration will still be applied after executing this command unless you set the following in your config:
+
+    ```elixir
+    config :pleroma, configurable_from_database: false
+    ```
+
+Options:
+
+- `<path>` - where to save migrated config. E.g. `--path=/tmp`. If file saved into non-standard folder, you must manually copy file into directory where Pleroma can read it. For OTP install path will be `PLEROMA_CONFIG_PATH` or `/etc/pleroma`. For installation from source - `config` directory in the pleroma folder.
+- `<env>` - environment, for which is migrated config. By default is `prod`.
+- To delete transferred settings from database optional flag `-d` can be used
+
+=== "OTP"
+    ```sh
+     ./bin/pleroma_ctl config migrate_from_db [--env=<env>] [-d] [--path=<path>]
+    ```
+
+=== "From Source"
+    ```sh
+    mix pleroma.config migrate_from_db [--env=<env>] [-d] [--path=<path>]
+    ```
+
+## Dump all of the config settings defined in the database
+
+=== "OTP"
+
+    ```sh
+     ./bin/pleroma_ctl config dump
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.config dump
+    ```
+
+## List individual configuration groups in the database
+
+=== "OTP"
+
+    ```sh
+     ./bin/pleroma_ctl config groups
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.config groups
+    ```
+
+## Dump the saved configuration values for a specific group or key
+
+e.g., this shows all the settings under `config :pleroma`
+
+=== "OTP"
+
+    ```sh
+    ./bin/pleroma_ctl config dump pleroma
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.config dump pleroma
+    ```
+
+To get values under a specific key:
+
+e.g., this shows all the settings under `config :pleroma, :instance`
+
+=== "OTP"
+
+    ```sh
+    ./bin/pleroma_ctl config dump pleroma instance
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.config dump pleroma instance
+    ```
+
+## Delete the saved configuration values for a specific group or key
+
+e.g., this deletes all the settings under `config :tesla`
+
+=== "OTP"
+
+    ```sh
+    ./bin/pleroma_ctl config delete [--force] tesla
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.config delete [--force] tesla
+    ```
+
+To delete values under a specific key:
+
+e.g., this deletes all the settings under `config :phoenix, :stacktrace_depth`
+
+=== "OTP"
+
+    ```sh
+    ./bin/pleroma_ctl config delete [--force] phoenix stacktrace_depth
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.config delete [--force] phoenix stacktrace_depth
+    ```
+
+## Remove all settings from the database
+
+This forcibly removes all saved values in the database.
+
+=== "OTP"
+
+    ```sh
+    ./bin/pleroma_ctl config [--force] reset
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.config [--force] reset
+
+    ```
+
+## Remove invalid MRF modules from the database
+
+This forcibly removes any enabled MRF that does not exist and will fix the ability of the instance to start.
+
+=== "OTP"
+    ```sh
+    ./bin/pleroma_ctl config fix_mrf_policies
+    ```
+
+=== "From Source"
+    ```sh
+    mix pleroma.config fix_mrf_policies
+    ```
\ No newline at end of file

docs/administration/CLI_tasks/database.md

+# Database maintenance tasks
+
+{! backend/administration/CLI_tasks/general_cli_task_info.include !}
+
+!!! danger
+    These mix tasks can take a long time to complete. Many of them were written to address specific database issues that happened because of bugs in migrations or other specific scenarios. Do not run these tasks "just in case" if everything is fine your instance.
+
+## Replace embedded objects with their references
+
+Replaces embedded objects with references to them in the `objects` table. Only needs to be ran once if the instance was created before Pleroma 1.0.5. The reason why this is not a migration is because it could significantly increase the database size after being ran, however after this `VACUUM FULL` will be able to reclaim about 20% (really depends on what is in the database, your mileage may vary) of the db size before the migration.
+
+=== "OTP"
+
+    ```sh
+    ./bin/pleroma_ctl database remove_embedded_objects [option ...]
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.database remove_embedded_objects [option ...]
+    ```
+
+### Options
+- `--vacuum` - run `VACUUM FULL` after the embedded objects are replaced with their references
+
+## Prune old remote posts from the database
+
+This will prune remote posts older than 90 days (configurable with [`config :pleroma, :instance, remote_post_retention_days`](../../configuration/cheatsheet.md#instance)) from the database. Pruned posts may be refetched in some cases.
+
+!!! note
+    The disk space will only be reclaimed after a proper vacuum. By default Postgresql does this for you on a regular basis, but if your instance has been running for a long time and there are many rows deleted, it may be advantageous to use `VACUUM FULL` (e.g. by using the `--vacuum` option).
+
+!!! danger
+    You may run out of disk space during the execution of the task or vacuuming if you don't have about 1/3rds of the database size free. Vacuum causes a substantial increase in I/O traffic, and may lead to a degraded experience while it is running.
+
+=== "OTP"
+
+    ```sh
+    ./bin/pleroma_ctl database prune_objects [option ...]
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.database prune_objects [option ...]
+    ```
+
+### Options
+
+- `--keep-threads` - Don't prune posts when they are part of a thread where at least one post has seen local interaction (e.g. one of the posts is a local post, or is favourited by a local user, or has been repeated by a local user...). It also won't delete posts when at least one of the posts in that thread is kept (e.g. because one of the posts has seen recent activity).
+- `--keep-non-public` - Keep non-public posts like DM's and followers-only, even if they are remote.
+- `--prune-orphaned-activities` - Also prune orphaned activities afterwards. Activities are things like Like, Create, Announce, Flag (aka reports). They can significantly help reduce the database size.  Note: this can take a very long time.
+- `--vacuum` - Run `VACUUM FULL` after the objects are pruned. This should not be used on a regular basis, but is useful if your instance has been running for a long time before pruning.
+
+## Create a conversation for all existing DMs
+
+Can be safely re-run
+
+=== "OTP"
+
+    ```sh
+    ./bin/pleroma_ctl database bump_all_conversations
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.database bump_all_conversations
+    ```
+
+## Remove duplicated items from following and update followers count for all users
+
+=== "OTP"
+
+    ```sh
+    ./bin/pleroma_ctl database update_users_following_followers_counts
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.database update_users_following_followers_counts
+    ```
+
+## Fix the pre-existing "likes" collections for all objects
+
+=== "OTP"
+
+    ```sh
+    ./bin/pleroma_ctl database fix_likes_collections
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.database fix_likes_collections
+    ```
+
+## Vacuum the database
+
+!!! note
+    By default Postgresql has an autovacuum deamon running. While the tasks described here can help in some cases, they shouldn't be needed on a regular basis. See [the Postgresql docs on vacuuming](https://www.postgresql.org/docs/current/sql-vacuum.html) for more information on this.
+
+### Analyze
+
+Running an `analyze` vacuum job can improve performance by updating statistics used by the query planner. **It is safe to cancel this.**
+
+=== "OTP"
+
+    ```sh
+    ./bin/pleroma_ctl database vacuum analyze
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.database vacuum analyze
+    ```
+
+### Full
+
+Running a `full` vacuum job rebuilds your entire database by reading all of the data and rewriting it into smaller
+and more compact files with an optimized layout. This process will take a long time and use additional disk space as
+it builds the files side-by-side the existing database files. It can make your database faster and use less disk space,
+but should only be run if necessary. **It is safe to cancel this.**
+
+=== "OTP"
+
+    ```sh
+    ./bin/pleroma_ctl database vacuum full
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.database vacuum full
+    ```
+
+## Add expiration to all local statuses
+
+=== "OTP"
+
+    ```sh
+    ./bin/pleroma_ctl database ensure_expiration
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.database ensure_expiration
+    ```
+
+## Change Text Search Configuration
+
+Change `default_text_search_config` for database and (if necessary) text_search_config used in index, then rebuild index (it may take time). 
+
+=== "OTP"
+
+    ```sh
+    ./bin/pleroma_ctl database set_text_search_config english
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.database set_text_search_config english
+    ```
+
+See [PostgreSQL documentation](https://www.postgresql.org/docs/current/textsearch-configuration.html) and `docs/configuration/howto_search_cjk.md` for more detail.

docs/administration/CLI_tasks/digest.md

+# Managing digest emails
+
+{! backend/administration/CLI_tasks/general_cli_task_info.include !}
+
+## Send digest email since given date (user registration date by default) ignoring user activity status.
+
+=== "OTP"
+
+    ```sh
+     ./bin/pleroma_ctl digest test <nickname> [since_date]
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.digest test <nickname> [since_date]
+    ```
+
+
+Example: 
+
+=== "OTP"
+
+    ```sh
+    ./bin/pleroma_ctl digest test donaldtheduck 2019-05-20
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.digest test donaldtheduck 2019-05-20
+    ```
+

docs/administration/CLI_tasks/email.md

+# EMail administration tasks
+
+{! backend/administration/CLI_tasks/general_cli_task_info.include !}
+
+## Send test email (instance email by default)
+
+=== "OTP"
+
+    ```sh
+     ./bin/pleroma_ctl email test [--to <destination email address>]
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.email test [--to <destination email address>]
+    ```
+
+Example:
+
+=== "OTP"
+
+    ```sh
+    ./bin/pleroma_ctl email test --to root@example.org
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.email test --to root@example.org
+    ```
+
+## Send confirmation emails to all unconfirmed user accounts
+
+=== "OTP"
+
+    ```sh
+     ./bin/pleroma_ctl email resend_confirmation_emails
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.email resend_confirmation_emails
+    ```

docs/administration/CLI_tasks/emoji.md

+# Managing emoji packs
+
+{! backend/administration/CLI_tasks/general_cli_task_info.include !}
+
+## Lists emoji packs and metadata specified in the manifest
+
+=== "OTP"
+    ```sh
+    ./bin/pleroma_ctl emoji ls-packs [option ...]
+    ```
+
+=== "From Source"
+    ```sh
+    mix pleroma.emoji ls-packs [option ...]
+    ```
+
+
+### Options
+- `-m, --manifest PATH/URL` - path to a custom manifest, it can either be an URL starting with `http`, in that case the manifest will be fetched from that address, or a local path
+
+## Fetch, verify and install the specified packs from the manifest into `STATIC-DIR/emoji/PACK-NAME`
+
+=== "OTP"
+    ```sh
+    ./bin/pleroma_ctl emoji get-packs [option ...] <pack ...>
+    ```
+
+=== "From Source"
+    ```sh
+    mix pleroma.emoji get-packs [option ...] <pack ...>
+    ```
+
+### Options
+- `-m, --manifest PATH/URL` - same as [`ls-packs`](#ls-packs)
+
+## Create a new manifest entry and a file list from the specified remote pack file
+
+=== "OTP"
+    ```sh
+    ./bin/pleroma_ctl emoji gen-pack PACK-URL
+    ```
+
+=== "From Source"
+    ```sh
+    mix pleroma.emoji gen-pack PACK-URL
+    ```
+
+Currently, only .zip archives are recognized as remote pack files and packs are therefore assumed to be zip archives. This command is intended to run interactively and will first ask you some basic questions about the pack, then download the remote file and generate an SHA256 checksum for it, then generate an emoji file list for you.
+
+  The manifest entry will either be written to a newly created `pack_name.json` file (pack name is asked in questions) or appended to the existing one, *replacing* the old pack with the same name if it was in the file previously.
+
+  The file list will be written to the file specified previously, *replacing* that file. You _should_ check that the file list doesn't contain anything you don't need in the pack, that is, anything that is not an emoji (the whole pack is downloaded, but only emoji files are extracted).
+
+## Reload emoji packs
+
+=== "OTP"
+    ```sh
+    ./bin/pleroma_ctl emoji reload
+    ```
+
+This command only works with OTP releases.

docs/administration/CLI_tasks/frontend.md

+# Managing frontends
+
+=== "OTP"
+
+    ```sh
+    ./bin/pleroma_ctl frontend install <frontend> [--ref <ref>] [--file <file>] [--build-url <build-url>] [--path <path>] [--build-dir <build-dir>]
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.frontend install <frontend> [--ref <ref>] [--file <file>] [--build-url <build-url>] [--path <path>] [--build-dir <build-dir>]
+    ```
+
+Frontend can be installed either from local zip file, or automatically downloaded from the web.
+
+You can give all the options directly on the command line, but missing information will be filled out by looking at the data configured under `frontends.available` in the config files.
+
+Currently, known `<frontend>` values are:
+
+- [admin-fe](https://git.pleroma.social/pleroma/admin-fe)
+- [kenoma](http://git.pleroma.social/lambadalambda/kenoma)
+- [pleroma-fe](http://git.pleroma.social/pleroma/pleroma-fe)
+- [fedi-fe](https://git.pleroma.social/pleroma/fedi-fe)
+- [soapbox](https://gitlab.com/soapbox-pub/soapbox)
+
+You can still install frontends that are not configured, see below.
+
+## Example installations for a known frontend
+
+For a frontend configured under the `available` key, it's enough to install it by name.
+
+=== "OTP"
+
+    ```sh
+    ./bin/pleroma_ctl frontend install pleroma
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.frontend install pleroma
+    ```
+
+This will download the latest build for the pre-configured `ref` and install it. It can then be configured as the one of the served frontends in the config file (see `primary` or `admin`).
+
+You can override any of the details. To install a pleroma build from a different URL, you could do this:
+
+=== "OTP"
+
+    ```sh
+    ./bin/pleroma_ctl frontend install pleroma --ref 2hu_edition --build-url https://example.org/raymoo.zip
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.frontend install pleroma --ref 2hu_edition --build-url https://example.org/raymoo.zip
+    ```
+
+Similarly, you can also install from a local zip file.
+
+=== "OTP"
+
+    ```sh
+    ./bin/pleroma_ctl frontend install pleroma --ref mybuild --file ~/Downloads/doomfe.zip
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.frontend install pleroma --ref mybuild --file ~/Downloads/doomfe.zip
+    ```
+
+The resulting frontend will always be installed into a folder of this template: `${instance_static}/frontends/${name}/${ref}`.
+
+Careful: This folder will be completely replaced on installation.
+
+## Example installation for an unknown frontend
+
+The installation process is the same, but you will have to give all the needed options on the command line. For example:
+
+=== "OTP"
+
+    ```sh
+    ./bin/pleroma_ctl frontend install gensokyo --ref master --build-url https://gensokyo.2hu/builds/marisa.zip
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.frontend install gensokyo --ref master --build-url https://gensokyo.2hu/builds/marisa.zip
+    ```
+
+If you don't have a zip file but just want to install a frontend from a local path, you can simply copy the files over a folder of this template: `${instance_static}/frontends/${name}/${ref}`.
+

docs/administration/CLI_tasks/general_cli_task_info.include

+Every command should be ran as the `pleroma` user from it's home directory. For example if you are superuser, you would have to wrap the command in `su pleroma -s $SHELL -lc "$COMMAND"`.
+
+??? note "From source note about `MIX_ENV`"
+
+     The `mix` command should be prefixed with the name of environment your Pleroma server is running in, usually it's `MIX_ENV=prod`

docs/administration/CLI_tasks/instance.md

+# Managing instance configuration
+
+{! backend/administration/CLI_tasks/general_cli_task_info.include !}
+
+## Generate a new configuration file
+=== "OTP"
+
+    ```sh
+     ./bin/pleroma_ctl instance gen [option ...]
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.instance gen [option ...]
+    ```
+
+
+If any of the options are left unspecified, you will be prompted interactively.
+
+### Options
+- `-f`, `--force` - overwrite any output files
+- `-o <path>`, `--output <path>` - the output file for the generated configuration
+- `--output-psql <path>` - the output file for the generated PostgreSQL setup
+- `--domain <domain>` - the domain of your instance
+- `--instance-name <instance_name>` - the name of your instance
+- `--admin-email <email>` - the email address of the instance admin
+- `--notify-email <email>` - email address for notifications
+- `--dbhost <hostname>` - the hostname of the PostgreSQL database to use
+- `--dbname <database_name>` - the name of the database to use
+- `--dbuser <username>` - the user (aka role) to use for the database connection
+- `--dbpass <password>` - the password to use for the database connection
+- `--rum <Y|N>` - Whether to enable RUM indexes
+- `--indexable <Y|N>` - Allow/disallow indexing site by search engines
+- `--db-configurable <Y|N>` - Allow/disallow configuring instance from admin part
+- `--uploads-dir <path>` - the directory uploads go in when using a local uploader
+- `--static-dir <path>` - the directory custom public files should be read from (custom emojis, frontend bundle overrides, robots.txt, etc.)
+- `--listen-ip <ip>` - the ip the app should listen to, defaults to 127.0.0.1
+- `--listen-port <port>` - the port the app should listen to, defaults to 4000
+- `--strip-uploads-location <Y|N>` - use ExifTool to strip uploads of sensitive location data
+- `--read-uploads-description <Y|N>` - use ExifTool to read image descriptions from uploads
+- `--anonymize-uploads <Y|N>` - randomize uploaded filenames
+- `--dedupe-uploads <Y|N>` - store files based on their hash to reduce data storage requirements if duplicates are uploaded with different filenames
+- `--skip-release-env` - skip generation the release environment file
+- `--release-env-file` - release environment file path

docs/administration/CLI_tasks/oauth_app.md

+# Creating trusted OAuth App
+
+{! backend/administration/CLI_tasks/general_cli_task_info.include !}
+
+## Create trusted OAuth App.
+
+Optional params:
+  * `-s SCOPES` - scopes for app, e.g. `read,write,follow,push`.
+
+=== "OTP"
+
+    ```sh
+     ./bin/pleroma_ctl app create -n APP_NAME -r REDIRECT_URI
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.app create -n APP_NAME -r REDIRECT_URI
+    ```
\ No newline at end of file

docs/administration/CLI_tasks/relay.md

+# Managing relays
+
+{! backend/administration/CLI_tasks/general_cli_task_info.include !}
+
+## Follow a relay
+
+=== "OTP"
+
+    ```sh
+    ./bin/pleroma_ctl relay follow <relay_url>
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.relay follow <relay_url>
+    ```
+
+## Unfollow a remote relay
+
+=== "OTP"
+
+    ```sh
+    ./bin/pleroma_ctl relay unfollow <relay_url>
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.relay unfollow <relay_url>
+    ```
+
+## List relay subscriptions
+
+=== "OTP"
+
+    ```sh
+    ./bin/pleroma_ctl relay list
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.relay list
+    ```

docs/administration/CLI_tasks/robots_txt.md

+# Managing robots.txt
+
+{! backend/administration/CLI_tasks/general_cli_task_info.include !}
+
+## Generate a new robots.txt file and add it to the static directory
+
+The `robots.txt` that ships by default is permissive. It allows well-behaved search engines to index all of your instance's URIs.
+
+If you want to generate a restrictive `robots.txt`, you can run the following mix task. The generated `robots.txt` will be written in your instance [static directory](../../../configuration/static_dir/).
+
+=== "OTP"
+
+    ```sh
+    ./bin/pleroma_ctl robots_txt disallow_all
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.robots_txt disallow_all
+    ```

docs/administration/CLI_tasks/uploads.md

+# Managing uploads
+
+{! backend/administration/CLI_tasks/general_cli_task_info.include !}
+
+## Migrate uploads from local to remote storage
+=== "OTP"
+
+    ```sh
+     ./bin/pleroma_ctl uploads migrate_local <target_uploader> [option ...]
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.uploads migrate_local <target_uploader> [option ...]
+    ```
+
+### Options
+- `--delete` - delete local uploads after migrating them to the target uploader
+
+A list of available uploaders can be seen in [Configuration Cheat Sheet](../../configuration/cheatsheet.md#pleromaupload)

docs/administration/CLI_tasks/user.md

+# Managing users
+
+{! backend/administration/CLI_tasks/general_cli_task_info.include !}
+
+## Create a user
+
+=== "OTP"
+
+    ```sh
+    ./bin/pleroma_ctl user new <nickname> <email> [option ...]
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.user new <nickname> <email> [option ...]
+    ```
+
+
+### Options
+- `--name <name>` - the user's display name
+- `--bio <bio>` - the user's bio
+- `--password <password>` - the user's password
+- `--moderator`/`--no-moderator` - whether the user should be a moderator
+- `--admin`/`--no-admin` - whether the user should be an admin
+- `-y`, `--assume-yes`/`--no-assume-yes` - whether to assume yes to all questions
+
+## List local users
+
+=== "OTP"
+
+    ```sh
+     ./bin/pleroma_ctl user list
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.user list
+    ```
+
+
+## Generate an invite link
+
+=== "OTP"
+
+    ```sh
+     ./bin/pleroma_ctl user invite [option ...]
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.user invite [option ...]
+    ```
+
+
+### Options
+- `--expires-at DATE` - last day on which token is active (e.g. "2019-04-05")
+- `--max-use NUMBER` - maximum numbers of token uses
+
+## List generated invites
+
+=== "OTP"
+
+    ```sh
+     ./bin/pleroma_ctl user invites
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.user invites
+    ```
+
+
+## Revoke invite
+
+=== "OTP"
+
+    ```sh
+     ./bin/pleroma_ctl user revoke_invite <token>
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.user revoke_invite <token>
+    ```
+
+
+## Delete a user
+
+=== "OTP"
+
+    ```sh
+     ./bin/pleroma_ctl user rm <nickname>
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.user rm <nickname>
+    ```
+
+
+## Delete user's posts and interactions
+
+=== "OTP"
+
+    ```sh
+     ./bin/pleroma_ctl user delete_activities <nickname>
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.user delete_activities <nickname>
+    ```
+
+
+## Sign user out from all applications (delete user's OAuth tokens and authorizations)
+
+=== "OTP"
+
+    ```sh
+     ./bin/pleroma_ctl user sign_out <nickname>
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.user sign_out <nickname>
+    ```
+
+## Activate a user
+
+=== "OTP"
+
+    ```sh
+     ./bin/pleroma_ctl user activate NICKNAME
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.user activate NICKNAME
+    ```
+
+## Deactivate a user and unsubscribes local users from the user
+
+=== "OTP"
+
+    ```sh
+     ./bin/pleroma_ctl user deactivate NICKNAME
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.user deactivate NICKNAME
+    ```
+
+
+## Deactivate all accounts from an instance and unsubscribe local users on it
+
+=== "OTP"
+
+    ```sh
+     ./bin/pleroma_ctl user deactivate_all_from_instance <instance>
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.user deactivate_all_from_instance <instance>
+    ```
+
+
+## Create a password reset link for user
+
+=== "OTP"
+
+    ```sh
+     ./bin/pleroma_ctl user reset_password <nickname>
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.user reset_password <nickname>
+    ```
+
+
+## Disable Multi Factor Authentication (MFA/2FA) for a user
+
+=== "OTP"
+
+    ```sh
+     ./bin/pleroma_ctl user reset_mfa <nickname>
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.user reset_mfa <nickname>
+    ```
+
+
+## Set the value of the given user's settings
+
+=== "OTP"
+
+    ```sh
+     ./bin/pleroma_ctl user set <nickname> [option ...]
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.user set <nickname> [option ...]
+    ```
+
+### Options
+- `--admin`/`--no-admin` - whether the user should be an admin
+- `--confirmed`/`--no-confirmed` - whether the user account is confirmed
+- `--locked`/`--no-locked` - whether the user should be locked
+- `--moderator`/`--no-moderator` - whether the user should be a moderator
+
+## Add tags to a user
+
+=== "OTP"
+
+    ```sh
+     ./bin/pleroma_ctl user tag <nickname> <tags>
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.user tag <nickname> <tags>
+    ```
+
+
+## Delete tags from a user
+
+=== "OTP"
+
+    ```sh
+     ./bin/pleroma_ctl user untag <nickname> <tags>
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.user untag <nickname> <tags>
+    ```
+
+
+## Toggle confirmation status of the user
+
+=== "OTP"
+
+    ```sh
+     ./bin/pleroma_ctl user confirm <nickname>
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.user confirm <nickname>
+    ```
+
+## Set confirmation status for all regular active users
+*Admins and moderators are excluded*
+
+=== "OTP"
+
+    ```sh
+     ./bin/pleroma_ctl user confirm_all
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.user confirm_all
+    ```
+
+## Revoke confirmation status for all regular active users
+*Admins and moderators are excluded*
+
+=== "OTP"
+
+    ```sh
+     ./bin/pleroma_ctl user unconfirm_all
+    ```
+
+=== "From Source"
+
+    ```sh
+    mix pleroma.user unconfirm_all
+    ```

docs/administration/backup.md

+# Backup/Restore/Move/Remove your instance
+
+## Backup
+
+1. Stop the Pleroma service.
+2. Go to the working directory of Pleroma (default is `/opt/pleroma`)
+3. Run `sudo -Hu postgres pg_dump -d <pleroma_db> --format=custom -f </path/to/backup_location/pleroma.pgdump>` (make sure the postgres user has write access to the destination file)
+4. Copy `pleroma.pgdump`, `config/prod.secret.exs`, `config/setup_db.psql` (if still available) and the `uploads` folder to your backup destination. If you have other modifications, copy those changes too.
+5. Restart the Pleroma service.
+
+## Restore/Move
+
+1. Optionally reinstall Pleroma (either on the same server or on another server if you want to move servers).
+2. Stop the Pleroma service.
+3. Go to the working directory of Pleroma (default is `/opt/pleroma`)
+4. Copy the above mentioned files back to their original position.
+5. Drop the existing database and user if restoring in-place. `sudo -Hu postgres psql -c 'DROP DATABASE <pleroma_db>;';` `sudo -Hu postgres psql -c 'DROP USER <pleroma_db>;'`
+6. Restore the database schema and pleroma postgres role the with the original `setup_db.psql` if you have it: `sudo -Hu postgres psql -f config/setup_db.psql`. 
+
+  Alternatively, run the `mix pleroma.instance gen` task again. You can ignore most of the questions, but make the database user, name, and password the same as found in your backup of `config/prod.secret.exs`. Then run the restoration of the pleroma role and schema with of the generated `config/setup_db.psql` as instructed above. You may delete the `config/generated_config.exs` file as it is not needed.
+
+7. Now restore the Pleroma instance's data into the empty database schema: `sudo -Hu postgres pg_restore -d <pleroma_db> -v -1 </path/to/backup_location/pleroma.pgdump>`
+8. If you installed a newer Pleroma version, you should run `mix ecto.migrate`[^1]. This task performs database migrations, if there were any.
+9. Restart the Pleroma service.
+10. Run `sudo -Hu postgres vacuumdb --all --analyze-in-stages`. This will quickly generate the statistics so that postgres can properly plan queries.
+11. If setting up on a new server configure Nginx by using the `installation/pleroma.nginx` config sample or reference the Pleroma installation guide for your OS which contains the Nginx configuration instructions.
+
+[^1]: Prefix with `MIX_ENV=prod` to run it using the production config file.
+
+## Remove
+
+1. Optionally you can remove the users of your instance. This will trigger delete requests for their accounts and posts. Note that this is 'best effort' and doesn't mean that all traces of your instance will be gone from the fediverse.
+    * You can do this from the admin-FE where you can select all local users and delete the accounts using the *Moderate multiple users* dropdown.
+    * You can also list local users and delete them individually using the CLI tasks for [Managing users](./CLI_tasks/user.md).
+2. Stop the Pleroma service `systemctl stop pleroma`
+3. Disable pleroma from systemd `systemctl disable pleroma`
+4. Remove the files and folders you created during installation (see installation guide). This includes the pleroma, nginx and systemd files and folders.
+5. Reload nginx now that the configuration is removed `systemctl reload nginx`
+6. Remove the database and database user `sudo -Hu postgres psql -c 'DROP DATABASE <pleroma_db>;';` `sudo -Hu postgres psql -c 'DROP USER <pleroma_db>;'`
+7. Remove the system user `userdel pleroma`
+8. Remove the dependencies that you don't need anymore (see installation guide). Make sure you don't remove packages that are still needed for other software that you have running!

docs/administration/frontends-management.md

+# Managing installed frontends
+
+Pleroma lets you install multiple frontends including multiple versions of same frontend. Right now it's only possible to switch which frontend is the default, but in the future it would be possible for user to select which frontend they prefer to use.
+
+As of 2.6.0 there are two ways of managing frontends - through PleromaFE's Admin Dashboard (preferred, easier method) or through AdminFE (clunky but also works on versions older than 2.6.0).
+
+!!! note
+    Managing frontends through UI requires [in-database configuration](../configuration/howto_database_config.md) to be enabled (default on newer instances but might be off on older ones).
+
+## How it works
+
+When installing frontends, it creates a folder in [static directory](../configuration/static_dir.md) that follows this pattern: `/frontends/${front-end name}/${front-end version}/`, puts contents of the built frontend in there. Then when accessing the server backend checks what front-end name and version are set to be default and serves index.html and assets from appropriate path.
+
+!!! warning
+
+    If you've been putting your frontend build directly into static dir as an antiquated way of serving custom frontend, this system will not work and will still serve the custom index.html you put in there. You can still serve custom frontend builds if you put your build into `/frontends/$name/$version` instead and set the "default frontend" fields appropriately.
+    
+Currently, there is no backup system, i.e. when installing `master` version it _will_ overwrite installed `master` version, for now if you want to keep previous version you should back it up manually, i.e. running `cp -r ./frontends/pleroma-fe/master ./frontends/pleroma-fe/master_old` in your static dir.
+
+## Managing front-ends through Admin Dashboard
+
+Open up Admin Dashboard (gauge icon in top bar, same as where link to AdminFE was),__
+![location of Admin Dashboard icon](../assets/admin_dash_location.png)
+switch to "Front-ends" tab.  
+![screenshot of Front-ends tab](../assets/frontends_tab.png)
+This page is designed to be self-explanatory and easy to use, while avoiding issues and pitfalls of AdminFE, but it's also early in development, everything is subject to change.
+
+!!! warning
+    This goes without saying, but if you set default frontend to anything except >2.6.0 version of PleromaFE you'll lose the access to Admin Dashboard and will have to use AdminFE to get it back. See below on how to use AdminFE.
+
+### Limitations 
+
+Currently the list of available for install frontends is essentially hard-coded in backend's configuration, each providing only one version, with exception for PleromaFE which overrides 'pleroma-fe' to also include `develop` version. There is no way to manually install build with a URL (coming soon) nor add more available frontends to the repository (it's broken).
+
+There is also no way to tell if there is an update available or not, for now you should watch for [announcements](https://pleroma.social/announcements/) of new PleromaFE stable releases to see if there is new stable version. For `develop` version it's up to you whether you want to follow the development process or just reinstall it periodically hoping for new stuff.
+
+## Using AdminFE to manage frontends
+
+Access AdminFE either directly by going to `/pleroma/admin` of your instance or by opening Admin Dashboard and clicking the link at the bottom of the window  
+![link to open old AdminFE](../assets/old_adminfe_link.png)
+
+
+Go to Settings -> Frontend.
+
+### Installing front-ends
+
+At the very top of the page there's a list of available frontends and button to install custom front-end
+
+!!! tip
+    Remember to click "Submit" in bottom right corner to save your changes!
+
+!!! bug
+    **Available Frontends** section lets you _install_ frontends but **NOT** update/reinstall them. It's only useful for installing a frontend once.
+    
+Due to aforementioned bug, preferred way of installing frontends in AdminFE is by clicking the "Install another frontend"  
+![screenshot of admin-fe with instructions on how to install a frontend](../assets/way_to_install_frontends.png)
+and filling in the fields. Unfortunately AdminFE does not provide the raw data necessary for you to fill those fields, so your best bet is to see what backend returns in browser's devtools or refer to the [source code](https://git.pleroma.social/pleroma/pleroma/-/blob/develop/config/config.exs?ref_type=heads#L742-791). For the most part, only **Name**, **Ref** (i.e. version) and **Build URL** fields are required, although some frontends might also require **Build Directory** to work. 
+
+For pleroma-fe you can use either `master` or `develop` refs, or potentially any ref in GitLab that has artifacts for `build` job, but that's outside scope of this document.
+
+### Selecting default frontend
+
+Scroll page waaaaay down, search for "Frontends" section, subtitled "Installed frontends management", change the name and reference of the "Primary" frontend.  
+![screenshot of admin-fe with instructions on how to install a frontend](../assets/primary_frontend_section.png)
+
+
+!!! danger
+    If you change "Admin" frontend name/reference you risk losing access to AdminFE as well.
+    
+!!! warning
+    Don't put anything into the "Available" section as it will break the list of available frontends completely, including the "add another frontend" button. If you accidentally put something in there, click the trashbin icon next to "Available" to reset it and restore the frontends list.

docs/administration/updating.md

+# Updating your instance
+
+You should **always check the [release notes/changelog](https://git.pleroma.social/pleroma/pleroma/-/releases)** in case there are config deprecations, special update steps, etc.
+
+Besides that, doing the following is generally enough:
+
+## For OTP installations
+
+```sh
+# Download the new release
+su pleroma -s $SHELL -lc "./bin/pleroma_ctl update"
+
+# Migrate the database, you are advised to stop the instance before doing that
+su pleroma -s $SHELL -lc "./bin/pleroma_ctl migrate"
+```
+
+## For from source installations (using git)
+
+1. Go to the working directory of Pleroma (default is `/opt/pleroma`)
+2. Run `git checkout <tagged release>` [^1]. e.g. `git checkout v2.4.5` This pulls the [tagged release](https://git.pleroma.social/pleroma/pleroma/-/releases) from upstream.
+3. Run `mix deps.get` [^1]. This pulls in any new dependencies.
+4. Stop the Pleroma service.
+5. Run `mix ecto.migrate` [^1] [^2]. This task performs database migrations, if there were any.
+6. Start the Pleroma service.
+
+[^1]: Depending on which install guide you followed (for example on Debian/Ubuntu), you want to run `git` and `mix` tasks as `pleroma` user by adding `sudo -Hu pleroma` before the command.
+[^2]: Prefix with `MIX_ENV=prod` to run it using the production config file.