diff --git a/docs/platforms/native/advanced-usage/backend-tradeoffs/index.mdx b/docs/platforms/native/advanced-usage/backend-tradeoffs/index.mdx
index 3d229dfb05af8..0a805eb7de21a 100644
--- a/docs/platforms/native/advanced-usage/backend-tradeoffs/index.mdx
+++ b/docs/platforms/native/advanced-usage/backend-tradeoffs/index.mdx
@@ -9,6 +9,8 @@ The Native SDK lets users decide at compile-time between three crash backends:
 * `breakpad`
 * `inproc`
 
+### Why is `crashpad` the default?
+
 Currently, `crashpad` is the default on all desktop platforms because it
 
 * has an external `handler` process that allows for external snapshots and sending crash reports immediately (instead of on the next successful start of your application)
@@ -26,6 +28,9 @@ Currently, `crashpad` is the default on all desktop platforms because it
   * cooperation with Epic's Easy Anti-Cheat
   * CMake build scripts (some users use our backend handler forks solely because of this reason)
 
+<Alert>
+When your deployment scenario should wait for the `crashpad_handler` to finish its work before a shutdown-after-crash (systemd, Docker), in Linux environments since SDK version [0.8.3](https://github.com/getsentry/sentry-native/releases/tag/0.8.3), you can enable the [option `crashpad_wait_for_upload`](/platforms/native/configuration/options/#crashpad-wait-for-upload) to delay application shutdown until the upload of the crash report is completed.
+</Alert>
 ### When shouldn't I use the `crashpad` backend?
 
 Sentry decided on `crashpad` as the default on all platforms because it offers numerous advantages. However, there are use cases where `crashpad` cannot be used or makes distribution or deployment much harder. We provide other backends for situations when
@@ -38,8 +43,6 @@ Sentry decided on `crashpad` as the default on all platforms because it offers n
 
 In the above cases, if you cannot loosen the requirements of your environment, you have to choose an in-process backend (meaning either `breakpad` or `inproc`).
 
-When your deployment scenario should wait for the `crashpad_handler` to finish its work before a shutdown-after-crash (systemd, Docker), you can enable the option [`crashpad_wait_for_upload`](/platforms/native/configuration/options/#crashpad-wait-for-upload) to delay application shutdown until the upload of the crash report is completed.
-
 ### How do I decide between `breakpad` or `inproc`?
 
 Both backends are comparable in how they differ from `crashpad`. However, there are also considerable differences between the two:
diff --git a/docs/platforms/native/advanced-usage/container-environments/index.mdx b/docs/platforms/native/advanced-usage/container-environments/index.mdx
new file mode 100644
index 0000000000000..6033e8b13599e
--- /dev/null
+++ b/docs/platforms/native/advanced-usage/container-environments/index.mdx
@@ -0,0 +1,31 @@
+---
+title: Container Environments
+description: "How to use the Sentry Native SDK in container environments."
+sidebar_order: 2000
+---
+
+## Database Path on a Mounted Volume
+The Sentry Native SDK uses a [database path](https://docs.sentry.io/platforms/native/configuration/options/#database-path) to store events and crash reports. When you are using a containerized environment, you may want to mount a volume to persist the database across container restarts to avoid losing this data.
+
+## Waiting for `Crashpad` to Finish
+Starting with SDK version [0.8.3](https://github.com/getsentry/sentry-native/releases/tag/0.8.3), the [option `crashpad_wait_for_upload`](https://docs.sentry.io/platforms/native/configuration/options/#crashpad-wait-for-upload) allows the application (on Linux) to wait for the `crashpad_handler` to finish before a shutdown-after-crash.
+
+In SDK versions older than 0.8.3, you could use a script similar to the example below to tie container shutdown to the `crashpad_handler` process:
+```bash
+#!/bin/bash
+
+# ./execute-main-app
+
+crashpad_timeout_s=10
+crashpad_process_name=crashpad_handler
+crashpad_pid=$(pgrep -n -f $crashpad_process_name)
+if [ -n "$crashpad_pid" ]; then
+    echo "Waiting for crashpad to finish..."
+    timeout $crashpad_timeout_s tail --pid=$crashpad_pid -f /dev/null
+    if [ $? -eq 124 ]; then
+        echo "The crashpad process did not finish within $crashpad_timeout_s seconds"
+    else
+        echo "The crashpad process finished successfully"
+    fi
+fi
+```