unnecessary mock
[akkoma] / docs / configuration / cheatsheet.md
index 507f15b878692ff572c73fe36ab08b76c8009527..ef3cc40e67e23d0c4bd6888ec3c0d53bf0dbc854 100644 (file)
@@ -2,9 +2,11 @@
 
 This is a cheat sheet for Pleroma configuration file, any setting possible to configure should be listed here.
 
-Pleroma configuration works by first importing the base config (`config/config.exs` on source installs, compiled-in on OTP releases), then overriding it by the environment config (`config/$MIX_ENV.exs` on source installs, N/A to OTP releases) and then overriding it by user config (`config/$MIX_ENV.secret.exs` on source installs, typically `/etc/pleroma/config.exs` on OTP releases).
+For OTP installations the configuration is typically stored in `/etc/pleroma/config.exs`.
 
-You shouldn't edit the base config directly to avoid breakages and merge conflicts, but it can be used as a reference if you don't understand how an option is supposed to be formatted, the latest version of it can be viewed [here](https://git.pleroma.social/pleroma/pleroma/blob/develop/config/config.exs).
+For from source installations Pleroma configuration works by first importing the base config `config/config.exs`, then overriding it by the environment config `config/$MIX_ENV.exs` and then overriding it by user config `config/$MIX_ENV.secret.exs`. In from source installations you should always make the changes to the user config and NEVER to the base config to avoid breakages and merge conflicts. So for production you change/add configuration to `config/prod.secret.exs`.
+
+To add configuration to your config file, you can copy it from the base config. The latest version of it can be viewed [here](https://git.pleroma.social/pleroma/pleroma/blob/develop/config/config.exs). You can also use this file if you don't know how an option is supposed to be formatted.
 
 ## :instance
 * `name`: The instance’s name.
@@ -150,8 +152,12 @@ config :pleroma, :mrf_user_allowlist,
 * `authorized_fetch_mode`: Require HTTP signatures for AP fetches
 
 ### :fetch_initial_posts
-* `enabled`: if enabled, when a new user is federated with, fetch some of their latest posts
-* `pages`: the amount of pages to fetch
+
+!!! warning
+    Be careful with this setting, fetching posts may lead to new users being discovered whose posts will then also be fetched. This can lead to serious load on your instance and database.
+
+* `enabled`: If enabled, when a new user is discovered by your instance, fetch some of their latest posts.
+* `pages`: The amount of pages to fetch
 
 ## Pleroma.ScheduledActivity
 
@@ -395,9 +401,10 @@ For each pool, the options are:
 
 Advanced settings for connections pool. Pool with opened connections. These connections can be reused in worker pools.
 
-For big instances it's recommended to increase `max_connections` up to 500-1000. It will increase memory usage, but federation would work faster.
+For big instances it's recommended to increase `config :pleroma, :connections_pool, max_connections: 500` up to 500-1000.
+It will increase memory usage, but federation would work faster.
 
-* `:receive_connection_timeout` - timeout to receive connection from pool. Default: 250ms.
+* `:checkin_timeout` - timeout to checkin connection from pool. Default: 250ms.
 * `:max_connections` - maximum number of connections in the pool. Default: 250 connections.
 * `:retry` - number of retries, while `gun` will try to reconnect if connections goes down. Default: 5.
 * `:retry_timeout` - timeout while `gun` will try to reconnect. Default: 100ms.
@@ -409,7 +416,7 @@ For big instances it's recommended to increase `max_connections` up to 500-1000.
 
 Advanced settings for workers pools.
 
-There's four pools used:
+There are four pools used:
 
 * `:federation` for the federation jobs.
   You may want this pool max_connections to be at least equal to the number of federator jobs + retry queue jobs.