docs: describe the single binary and plugin sideloading

docs/DeveloperManuals/DeveloperSetup.md

@@ -121,10 +121,38 @@ For provisioning, customizing, and creating dashboards, please refer to our [Gra
 
 ## Compiling
 
-    - Compile all plugins: `make build-plugin`
-    - Compile specific plugins: `PLUGIN=<PLUGIN_NAME> make build-plugin`
-    - Compile server: `make build`
-    - Compile worker: `make build-worker`
+`make build` produces a single `bin/lake` binary: the framework, the API and every official plugin are compiled into it.
+
+```sh
+cd backend
+make build
+```
+
+While iterating you usually do not want all of them. `DEVLAKE_PLUGINS` takes a comma-separated list:
+
+```sh
+DEVLAKE_PLUGINS=jira,gitlab make build
+```
+
+To build plugins as shared objects instead — to sideload them into an existing binary, or to ship a server without any plugin compiled in — use:
+
+```sh
+make build-plugin                              # every plugin
+DEVLAKE_PLUGINS=jira,gitlab make build-plugin  # a subset
+```
+
+The output lands in `bin/plugins/<name>/<name>.so`.
+
+## Sideloading plugins
+
+A released `lake` binary already contains every official plugin, and it still accepts extras. Any `.so` found under `PLUGIN_DIR` (default `bin/plugins`) is opened at startup and registered on top of the compiled-in set, so you can add a custom plugin — or replace an official one — without rebuilding DevLake.
+
+Two things to know before you try it:
+
+- The `.so` has to be built with `go build -buildmode=plugin` against the **same DevLake version, Go toolchain, build flags and dependency versions** as the binary that loads it. Go rejects a plugin whose copy of a shared package differs, so build it in the matching `lake-builder` image rather than on your host.
+- A plugin that fails to load is logged and skipped. The server keeps running without it, so check the log after adding one.
+
+The plugin entry point (`PluginEntry`, implementing `plugin.PluginMeta`) and the interfaces a plugin can implement are described in the [plugin development manual](https://github.com/apache/devlake/blob/main/backend/DevelopmentManual.md).
 
 ## References
 

docs/GettingStarted/DockerComposeSetup.md

@@ -174,6 +174,21 @@ config-ui:
 
 6. Final step: `docker compose up -d`
 
+### Can I add my own plugin to the DevLake image?
+
+The `apache/devlake` image ships a single binary that already contains every official plugin, so there is nothing to install for the supported data sources. If you need one that is not included, build it as a shared object and mount it into the container:
+
+```yaml
+devlake:
+  ...
+  volumes:
+    - ./plugins:/app/bin/plugins
+```
+
+The directory is scanned at startup and each `<name>.so` is registered on top of the built-in plugins; one that reuses an existing plugin's name replaces it. A plugin that fails to load is logged and skipped, and the server keeps running without it.
+
+The plugin has to be built against the same DevLake release and Go toolchain as the running image, or it will be rejected at load time — build it in the matching `lake-builder` image rather than on your host. See [Sideloading plugins](../DeveloperManuals/DeveloperSetup.md#sideloading-plugins) for the details.
+
 ## Troubleshooting
 
 If you run into any problem, please check the [Troubleshooting](/Troubleshooting/Installation.md) or [create an issue](https://github.com/apache/devlake/issues)

docs/GettingStarted/Environment.md

@@ -8,6 +8,20 @@ This document explains how to set environment variables for Apache DevLake and w
 
 ## Environment Variables
 
+### PLUGIN_DIR
+
+Directory scanned at startup for shared-object plugins (`.so`). The released binary already contains every official plugin; anything found here is loaded on top of that set, which makes this the directory to use for a custom or third-party plugin.
+
+| Environment Variable | Description                                                                          | Default Value |
+| -------------------- | ------------------------------------------------------------------------------------ | ------------- |
+| `PLUGIN_DIR`         | Directory scanned for sideloaded `.so` plugins. A missing directory is not an error.  | `bin/plugins` |
+
+- In the Docker image, mount your plugins over `/app/bin/plugins`.
+- A plugin that fails to load — usually a toolchain or dependency mismatch — is logged and skipped; the server keeps running without it.
+- A sideloaded plugin whose name matches an official plugin overrides it, and the override is logged as a warning.
+
+See [Sideloading plugins](../DeveloperManuals/DeveloperSetup.md#sideloading-plugins) for how to build one.
+
 ### ENABLE_SUBTASKS_BY_DEFAULT
 
 This environment variable is used to enable or disable the execution of subtasks.