deploy: 3479599387164aca2613e88d1697191b087e55bc

1 files changed, 60 insertions, 10 deletions

diff --git a/develop/print.html b/develop/print.html
index a1e7e7002d..7f1d209324 100644
--- a/develop/print.html
+++ b/develop/print.html
@@ -5644,20 +5644,20 @@ state events are shared with users:</p>
 <p>To change the default behavior, use the following sub-options:</p>
 <ul>
 <li>
-<p><code>disable_default_event_types</code>: boolean. Set to <code>true</code> to disable the above 
+<p><code>disable_default_event_types</code>: boolean. Set to <code>true</code> to disable the above
 defaults. If this is enabled, only the event types listed in
 <code>additional_event_types</code> are shared. Defaults to <code>false</code>.</p>
 </li>
 <li>
-<p><code>additional_event_types</code>: A list of additional state events to include in the 
-events to be shared. By default, this list is empty (so only the default event 
+<p><code>additional_event_types</code>: A list of additional state events to include in the
+events to be shared. By default, this list is empty (so only the default event
 types are shared).</p>
 <p>Each entry in this list should be either a single string or a list of two
-strings. </p>
+strings.</p>
 <ul>
 <li>A standalone string <code>t</code> represents all events with type <code>t</code> (i.e.
 with no restrictions on state keys).</li>
-<li>A pair of strings <code>[t, s]</code> represents a single event with type <code>t</code> and 
+<li>A pair of strings <code>[t, s]</code> represents a single event with type <code>t</code> and
 state key <code>s</code>. The same type can appear in two entries with different state
 keys: in this situation, both state keys are included in prejoin state.</li>
 </ul>
@@ -6794,6 +6794,33 @@ defaults to the main process.</p>
 <pre><code class="language-yaml">run_background_tasks_on: worker1
 </code></pre>
 <hr />
+<h3 id="update_user_directory_from_worker"><a class="header" href="#update_user_directory_from_worker"><code>update_user_directory_from_worker</code></a></h3>
+<p>The <a href="usage/configuration/../../workers.html#updating-the-user-directory">worker</a> that is used to
+update the user directory. If not provided this defaults to the main process.</p>
+<p>Example configuration:</p>
+<pre><code class="language-yaml">update_user_directory_from_worker: worker1
+</code></pre>
+<p><em>Added in Synapse 1.59.0.</em></p>
+<hr />
+<h3 id="notify_appservices_from_worker"><a class="header" href="#notify_appservices_from_worker"><code>notify_appservices_from_worker</code></a></h3>
+<p>The <a href="usage/configuration/../../workers.html#notifying-application-services">worker</a> that is used to
+send output traffic to Application Services. If not provided this defaults
+to the main process.</p>
+<p>Example configuration:</p>
+<pre><code class="language-yaml">notify_appservices_from_worker: worker1
+</code></pre>
+<p><em>Added in Synapse 1.59.0.</em></p>
+<hr />
+<h3 id="media_instance_running_background_jobs"><a class="header" href="#media_instance_running_background_jobs"><code>media_instance_running_background_jobs</code></a></h3>
+<p>The <a href="usage/configuration/../../workers.html#synapseappmedia_repository">worker</a> that is used to run
+background tasks for media repository. If running multiple media repositories
+you must configure a single instance to run the background tasks. If not provided
+this defaults to the main process or your single <code>media_repository</code> worker.</p>
+<p>Example configuration:</p>
+<pre><code class="language-yaml">media_instance_running_background_jobs: worker1
+</code></pre>
+<p><em>Added in Synapse 1.16.0.</em></p>
+<hr />
 <h3 id="redis"><a class="header" href="#redis"><code>redis</code></a></h3>
 <p>Configuration for Redis when using workers. This <em>must</em> be enabled when using workers.
 This setting has the following sub-options:</p>
@@ -10709,7 +10736,8 @@ worker_log_config: /etc/matrix-synapse/background-worker-log.yaml
 </code></pre>
 <h4 id="updating-the-user-directory"><a class="header" href="#updating-the-user-directory">Updating the User Directory</a></h4>
 <p>You can designate one generic worker to update the user directory.</p>
-<p>Specify its name in the shared configuration as follows:</p>
+<p>Specify its name in the <a href="usage/configuration/config_documentation.html#update_user_directory_from_worker">shared configuration</a>
+as follows:</p>
 <pre><code class="language-yaml">update_user_directory_from_worker: worker_name
 </code></pre>
 <p>This work cannot be load-balanced; please ensure the main process is restarted
@@ -10725,16 +10753,36 @@ worker application type.</p>
 <h4 id="notifying-application-services"><a class="header" href="#notifying-application-services">Notifying Application Services</a></h4>
 <p>You can designate one generic worker to send output traffic to Application Services.
 Doesn't handle any REST endpoints itself, but you should specify its name in the
-shared configuration as follows:</p>
+<a href="usage/configuration/config_documentation.html#notify_appservices_from_worker">shared configuration</a>
+as follows:</p>
 <pre><code class="language-yaml">notify_appservices_from_worker: worker_name
 </code></pre>
 <p>This work cannot be load-balanced; please ensure the main process is restarted
 after setting this option in the shared configuration!</p>
 <p>This style of configuration supersedes the legacy <code>synapse.app.appservice</code>
 worker application type.</p>
+<h4 id="push-notifications"><a class="header" href="#push-notifications">Push Notifications</a></h4>
+<p>You can designate generic worker to sending push notifications to
+a <a href="https://spec.matrix.org/v1.5/push-gateway-api/">push gateway</a> such as
+<a href="https://github.com/matrix-org/sygnal">sygnal</a> and email.</p>
+<p>This will stop the main process sending push notifications.</p>
+<p>The workers responsible for sending push notifications can be defined using the
+<a href="usage/configuration/config_documentation.html#pusher_instances"><code>pusher_instances</code></a>
+option. For example:</p>
+<pre><code class="language-yaml">pusher_instances:
+  - pusher_worker1
+  - pusher_worker2
+</code></pre>
+<p>Multiple workers can be added to this map, in which case the work is balanced
+across them. Ensure the main process and all pusher workers are restarted after changing
+this option.</p>
+<p>These workers don't need to accept incoming HTTP requests to send push notifications,
+so no additional reverse proxy configuration is required for pusher workers.</p>
+<p>This style of configuration supersedes the legacy <code>synapse.app.pusher</code>
+worker application type.</p>
 <h3 id="synapseapppusher"><a class="header" href="#synapseapppusher"><code>synapse.app.pusher</code></a></h3>
 <p>It is likely this option will be deprecated in the future and is not recommended for new
-installations. Instead, <a href="usage/configuration/config_documentation.html#pusher_instances">use <code>synapse.app.generic_worker</code> with the <code>pusher_instances</code></a>.</p>
+installations. Instead, <a href="workers.html#push-notifications">use <code>synapse.app.generic_worker</code> with the <code>pusher_instances</code></a>.</p>
 <p>Handles sending push notifications to sygnal and email. Doesn't handle any
 REST endpoints itself, but you should set
 <a href="usage/configuration/config_documentation.html#start_pushers"><code>start_pushers: false</code></a> in the
@@ -10767,7 +10815,7 @@ shared configuration file to stop the main synapse sending appservice notificati
 <p>Note this worker cannot be load-balanced: only one instance should be active.</p>
 <h3 id="synapseappfederation_sender"><a class="header" href="#synapseappfederation_sender"><code>synapse.app.federation_sender</code></a></h3>
 <p>It is likely this option will be deprecated in the future and not recommended for
-new installations. Instead, <a href="usage/configuration/config_documentation.html#federation_sender_instances">use <code>synapse.app.generic_worker</code> with the <code>federation_sender_instances</code></a>. </p>
+new installations. Instead, <a href="usage/configuration/config_documentation.html#federation_sender_instances">use <code>synapse.app.generic_worker</code> with the <code>federation_sender_instances</code></a>.</p>
 <p>Handles sending federation traffic to other servers. Doesn't handle any
 REST endpoints itself, but you should set
 <a href="usage/configuration/config_documentation.html#send_federation"><code>send_federation: false</code></a>
@@ -10831,7 +10879,9 @@ worker_listeners:
 worker_log_config: /etc/matrix-synapse/media-worker-log.yaml
 </code></pre>
 <p>Note that if running multiple media repositories they must be on the same server
-and you must configure a single instance to run the background tasks, e.g.:</p>
+and you must specify a single instance to run the background tasks in the
+<a href="usage/configuration/config_documentation.html#media_instance_running_background_jobs">shared configuration</a>,
+e.g.:</p>
 <pre><code class="language-yaml">media_instance_running_background_jobs: &quot;media-repository-1&quot;
 </code></pre>
 <p>Note that if a reverse proxy is used , then <code>/_matrix/media/</code> must be routed for both inbound client and federation requests (if they are handled separately).</p>