diff --git a/_config.yml b/_config.yml
index faa6eaa..96e6316 100644
--- a/_config.yml
+++ b/_config.yml
@@ -1,8 +1,14 @@
-title: Just the Docs Template
-description: A starter template for a Jeykll site using the Just the Docs theme!
+title: MOSAIC
+description: WebRTC-based real-time robot control and monitoring system
 theme: just-the-docs
 
-url: https://just-the-docs.github.io
+url: https://acsl-mosaic.github.io
 
 aux_links:
-  Template Repository: https://github.com/just-the-docs/just-the-docs-template
+  GitHub: https://github.com/AutoCompSysLab/MOSAIC
+
+defaults:
+  - scope:
+      path: ""
+    values:
+      layout: default
diff --git a/_includes/toc.html b/_includes/toc.html
new file mode 100644
index 0000000..bc90d08
--- /dev/null
+++ b/_includes/toc.html
@@ -0,0 +1,189 @@
+{% capture tocWorkspace %}
+    {% comment %}
+        Copyright (c) 2017 Vladimir "allejo" Jimenez
+
+        Permission is hereby granted, free of charge, to any person
+        obtaining a copy of this software and associated documentation
+        files (the "Software"), to deal in the Software without
+        restriction, including without limitation the rights to use,
+        copy, modify, merge, publish, distribute, sublicense, and/or sell
+        copies of the Software, and to permit persons to whom the
+        Software is furnished to do so, subject to the following
+        conditions:
+
+        The above copyright notice and this permission notice shall be
+        included in all copies or substantial portions of the Software.
+
+        THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+        EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+        OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+        NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+        HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+        WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+        FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+        OTHER DEALINGS IN THE SOFTWARE.
+    {% endcomment %}
+    {% comment %}
+        Version 1.2.1
+          https://github.com/allejo/jekyll-toc
+
+        "...like all things liquid - where there's a will, and ~36 hours to spare, there's usually a/some way" ~jaybe
+
+        Usage:
+            {% include toc.html html=content sanitize=true class="inline_toc" id="my_toc" h_min=2 h_max=3 %}
+
+        Parameters:
+            * html         (string) - the HTML of compiled markdown generated by kramdown in Jekyll
+
+        Optional Parameters:
+            * sanitize      (bool)   : false  - when set to true, the headers will be stripped of any HTML in the TOC
+            * class         (string) :   ''   - a CSS class assigned to the TOC
+            * id            (string) :   ''   - an ID to assigned to the TOC
+            * h_min         (int)    :   1    - the minimum TOC header level to use; any header lower than this value will be ignored
+            * h_max         (int)    :   6    - the maximum TOC header level to use; any header greater than this value will be ignored
+            * ordered       (bool)   : false  - when set to true, an ordered list will be outputted instead of an unordered list
+            * item_class    (string) :   ''   - add custom class(es) for each list item; has support for '%level%' placeholder, which is the current heading level
+            * submenu_class (string) :   ''   - add custom class(es) for each child group of headings; has support for '%level%' placeholder which is the current "submenu" heading level
+            * base_url      (string) :   ''   - add a base url to the TOC links for when your TOC is on another page than the actual content
+            * anchor_class  (string) :   ''   - add custom class(es) for each anchor element
+            * skip_no_ids   (bool)   : false  - skip headers that do not have an `id` attribute
+            * flat_toc      (bool)   : false  - when set to true, the TOC will be a single level list
+
+        Output:
+            An ordered or unordered list representing the table of contents of a markdown block. This snippet will only
+            generate the table of contents and will NOT output the markdown given to it
+    {% endcomment %}
+
+    {% capture newline %}
+    {% endcapture %}
+    {% assign newline = newline | rstrip %} <!-- Remove the extra spacing but preserve the newline -->
+
+    {% capture deprecation_warnings %}{% endcapture %}
+
+    {% if include.baseurl %}
+        {% capture deprecation_warnings %}{{ deprecation_warnings }}<!-- jekyll-toc :: "baseurl" has been deprecated, use "base_url" instead -->{{ newline }}{% endcapture %}
+    {% endif %}
+
+    {% if include.skipNoIDs %}
+        {% capture deprecation_warnings %}{{ deprecation_warnings }}<!-- jekyll-toc :: "skipNoIDs" has been deprecated, use "skip_no_ids" instead -->{{ newline }}{% endcapture %}
+    {% endif %}
+
+    {% capture jekyll_toc %}{% endcapture %}
+    {% assign orderedList = include.ordered | default: false %}
+    {% assign flatToc = include.flat_toc | default: false %}
+    {% assign baseURL = include.base_url | default: include.baseurl | default: '' %}
+    {% assign skipNoIDs = include.skip_no_ids | default: include.skipNoIDs | default: false %}
+    {% assign minHeader = include.h_min | default: 1 %}
+    {% assign maxHeader = include.h_max | default: 6 %}
+    {% assign nodes = include.html | strip | split: '<h' %}
+
+    {% assign firstHeader = true %}
+    {% assign currLevel = 0 %}
+    {% assign lastLevel = 0 %}
+
+    {% capture listModifier %}{% if orderedList %}ol{% else %}ul{% endif %}{% endcapture %}
+
+    {% for node in nodes %}
+        {% if node == "" %}
+            {% continue %}
+        {% endif %}
+
+        {% assign currLevel = node | replace: '"', '' | slice: 0, 1 | times: 1 %}
+
+        {% if currLevel < minHeader or currLevel > maxHeader %}
+            {% continue %}
+        {% endif %}
+
+        {% assign _workspace = node | split: '</h' %}
+
+        {% assign _idWorkspace = _workspace[0] | split: 'id="' %}
+        {% assign _idWorkspace = _idWorkspace[1] | split: '"' %}
+        {% assign htmlID = _idWorkspace[0] %}
+
+        {% assign _classWorkspace = _workspace[0] | split: 'class="' %}
+        {% assign _classWorkspace = _classWorkspace[1] | split: '"' %}
+        {% assign htmlClass = _classWorkspace[0] %}
+
+        {% if htmlClass contains "no_toc" %}
+            {% continue %}
+        {% endif %}
+
+        {% if firstHeader %}
+            {% assign minHeader = currLevel %}
+        {% endif %}
+
+        {% capture _hAttrToStrip %}{{ _workspace[0] | split: '>' | first }}>{% endcapture %}
+        {% assign header = _workspace[0] | replace: _hAttrToStrip, '' %}
+
+        {% if include.item_class and include.item_class != blank %}
+            {% capture listItemClass %} class="{{ include.item_class | replace: '%level%', currLevel | split: '.' | join: ' ' }}"{% endcapture %}
+        {% endif %}
+
+        {% if include.submenu_class and include.submenu_class != blank %}
+            {% assign subMenuLevel = currLevel | minus: 1 %}
+            {% capture subMenuClass %} class="{{ include.submenu_class | replace: '%level%', subMenuLevel | split: '.' | join: ' ' }}"{% endcapture %}
+        {% endif %}
+
+        {% capture anchorBody %}{% if include.sanitize %}{{ header | strip_html }}{% else %}{{ header }}{% endif %}{% endcapture %}
+
+        {% if htmlID %}
+            {% capture anchorAttributes %} href="{% if baseURL %}{{ baseURL }}{% endif %}#{{ htmlID }}"{% endcapture %}
+
+            {% if include.anchor_class %}
+                {% capture anchorAttributes %}{{ anchorAttributes }} class="{{ include.anchor_class | split: '.' | join: ' ' }}"{% endcapture %}
+            {% endif %}
+
+            {% capture listItem %}<a{{ anchorAttributes }}>{{ anchorBody }}</a>{% endcapture %}
+        {% elsif skipNoIDs == true %}
+            {% continue %}
+        {% else %}
+            {% capture listItem %}{{ anchorBody }}{% endcapture %}
+        {% endif %}
+
+        {% if currLevel > lastLevel and flatToc == false %}
+            {% capture jekyll_toc %}{{ jekyll_toc }}<{{ listModifier }}{{ subMenuClass }}>{% endcapture %}
+        {% elsif currLevel < lastLevel and flatToc == false %}
+            {% assign repeatCount = lastLevel | minus: currLevel %}
+
+            {% for i in (1..repeatCount) %}
+                {% capture jekyll_toc %}{{ jekyll_toc }}</li></{{ listModifier }}>{% endcapture %}
+            {% endfor %}
+
+            {% capture jekyll_toc %}{{ jekyll_toc }}</li>{% endcapture %}
+        {% else %}
+            {% capture jekyll_toc %}{{ jekyll_toc }}</li>{% endcapture %}
+        {% endif %}
+
+        {% capture jekyll_toc %}{{ jekyll_toc }}<li{{ listItemClass }}>{{ listItem }}{% endcapture %}
+
+        {% assign lastLevel = currLevel %}
+        {% assign firstHeader = false %}
+    {% endfor %}
+
+    {% if flatToc == true %}
+        {% assign repeatCount = 1 %}
+    {% else %}
+        {% assign repeatCount = minHeader | minus: 1 %}
+        {% assign repeatCount = lastLevel | minus: repeatCount %}
+    {% endif %}
+
+    {% for i in (1..repeatCount) %}
+        {% capture jekyll_toc %}{{ jekyll_toc }}</li></{{ listModifier }}>{% endcapture %}
+    {% endfor %}
+
+    {% if jekyll_toc != '' %}
+        {% assign rootAttributes = '' %}
+        {% if include.class and include.class != blank %}
+            {% capture rootAttributes %} class="{{ include.class | split: '.' | join: ' ' }}"{% endcapture %}
+        {% endif %}
+
+        {% if include.id and include.id != blank %}
+            {% capture rootAttributes %}{{ rootAttributes }} id="{{ include.id }}"{% endcapture %}
+        {% endif %}
+
+        {% if rootAttributes %}
+            {% assign nodes = jekyll_toc | split: '>' %}
+            {% capture jekyll_toc %}<{{ listModifier }}{{ rootAttributes }}>{{ nodes | shift | join: '>' }}>{% endcapture %}
+        {% endif %}
+    {% endif %}
+{% endcapture %}{% assign tocWorkspace = '' %}{{ deprecation_warnings }}{{ jekyll_toc -}}
diff --git a/_layouts/default.html b/_layouts/default.html
new file mode 100644
index 0000000..3100c63
--- /dev/null
+++ b/_layouts/default.html
@@ -0,0 +1,60 @@
+---
+layout: table_wrappers
+---
+
+<!DOCTYPE html>
+
+<html lang="{{ site.lang | default: 'en-US' }}">
+{% include head.html %}
+<body>
+  <a class="skip-to-main" href="#main-content">Skip to main content</a>
+  {% include icons/icons.html %}
+  {% if page.nav_enabled == true %}
+    {% include components/sidebar.html %}
+  {% elsif layout.nav_enabled == true and page.nav_enabled == nil %}
+    {% include components/sidebar.html %}
+  {% elsif site.nav_enabled != false and layout.nav_enabled == nil and page.nav_enabled == nil %}
+    {% include components/sidebar.html %}
+  {% endif %}
+  <div class="main" id="top">
+    {% include components/header.html %}
+    <div class="main-content-wrap">
+      {% include components/breadcrumbs.html %}
+      <div id="main-content" class="main-content">
+        <div class="content-with-toc">
+          <main class="content-main">
+            {% if site.heading_anchors != false %}
+              {% include vendor/anchor_headings.html html=content beforeHeading="true" anchorBody="<svg viewBox=\"0 0 16 16\" aria-hidden=\"true\"><use xlink:href=\"#svg-link\"></use></svg>" anchorClass="anchor-heading" anchorAttrs="aria-labelledby=\"%html_id%\"" %}
+            {% else %}
+              {{ content }}
+            {% endif %}
+
+            {% if page.has_toc != false %}
+              {% include components/children_nav.html %}
+            {% endif %}
+          </main>
+
+          {% capture toc_content %}{% include toc.html html=content sanitize=true h_min=2 h_max=3 %}{% endcapture %}
+          {% if toc_content != blank %}
+          <aside class="toc-sidebar">
+            <div class="toc-wrapper">
+              <p class="toc-label">On this page</p>
+              {{ toc_content }}
+            </div>
+          </aside>
+          {% endif %}
+        </div>
+
+        {% include components/footer.html %}
+      </div>
+    </div>
+    {% if site.search_enabled != false %}
+      {% include components/search_footer.html %}
+    {% endif %}
+  </div>
+
+  {% if site.mermaid %}
+    {% include components/mermaid.html %}
+  {% endif %}
+</body>
+</html>
\ No newline at end of file
diff --git a/_sass/custom/custom.scss b/_sass/custom/custom.scss
new file mode 100644
index 0000000..3040b5f
--- /dev/null
+++ b/_sass/custom/custom.scss
@@ -0,0 +1,66 @@
+// Two-column layout: content + TOC sidebar
+.content-with-toc {
+  display: flex;
+  align-items: flex-start;
+  gap: 2rem;
+}
+
+.content-main {
+  flex: 1;
+  min-width: 0;
+}
+
+// TOC sidebar
+.toc-sidebar {
+  flex: 0 0 200px;
+  position: sticky;
+  top: 4rem;
+  max-height: calc(100vh - 6rem);
+  overflow-y: auto;
+}
+
+.toc-wrapper {
+  border-left: 2px solid $border-color;
+  padding-left: 1rem;
+  font-size: 0.8rem;
+
+  .toc-label {
+    font-size: 0.75rem;
+    font-weight: 700;
+    text-transform: uppercase;
+    letter-spacing: 0.05em;
+    color: $grey-dk-100;
+    margin-bottom: 0.5rem;
+  }
+
+  ul {
+    list-style: none;
+    padding-left: 0;
+    margin: 0;
+  }
+
+  ul ul {
+    padding-left: 0.75rem;
+  }
+
+  li {
+    margin: 0.3rem 0;
+    line-height: 1.4;
+  }
+
+  a {
+    color: $grey-dk-100;
+    text-decoration: none;
+
+    &:hover {
+      color: $link-color;
+    }
+  }
+}
+
+// Hide TOC sidebar on small screens
+@media (max-width: 1024px) {
+  .toc-sidebar {
+    display: none;
+  }
+}
\ No newline at end of file
diff --git a/docs/config-on-robot.md b/docs/config-on-robot.md
new file mode 100644
index 0000000..1ced2c3
--- /dev/null
+++ b/docs/config-on-robot.md
@@ -0,0 +1,237 @@
+---
+title: Config on Robot
+nav_order: 6
+---
+
+# Config on Robot
+
+The robot-side configuration is a single YAML file (conventionally named `mosaic_config.yaml`) that is passed to `AutoConfigurer::AutoConfigure()` at startup. It has two top-level sections: `server` and `connectors`.
+
+---
+
+## Full Structure
+
+```yaml
+server:
+  ws_url: 'wss://api-mosaic.your-domain.com'
+  auth:
+    type: 'simple-token'
+    robot_id: '<your-robot-uuid>'
+    params:
+      token: '<encrypted-token-from-server>'
+  webrtc:
+    ice_servers:
+      - urls:
+          - 'turn.your-turn-server.com:3478'
+        username: '<turn-username>'
+        credential: '<turn-password>'
+
+connectors:
+  - type: 'opencv-sender-camera'
+    label: 'camera_stream'
+    params:
+      fps: 30
+      camera_id: 0
+      width: 640
+      height: 480
+
+  - type: 'my-sensor-sender'
+    label: 'sensor_data'
+    params:
+      topic_name: '/my/sensor/topic'
+
+  - type: 'my-command-receiver'
+    label: 'cmd_vel'
+```
+
+---
+
+## `server` Section
+
+### `ws_url` (required)
+
+The base URL of your MOSAIC-Server instance. The robot appends `/ws/robot` to form the WebSocket signaling endpoint.
+
+```yaml
+server:
+  ws_url: 'wss://api-mosaic.your-domain.com'
+```
+
+| Value | When to use |
+|:---|:---|
+| `wss://...` | Production (TLS) |
+| `ws://...` | Local development only |
+
+---
+
+### `auth` (required)
+
+Identifies the robot and authenticates it with the server.
+
+```yaml
+auth:
+  type: 'simple-token'
+  robot_id: '<robot-uuid>'
+  params:
+    token: '<encrypted-token>'
+```
+
+| Field | Description |
+|:---|:---|
+| `type` | Authentication scheme. Use `'simple-token'` for the default MOSAIC token auth. |
+| `robot_id` | The UUID of the robot registered on MOSAIC-Server. |
+| `params.token` | The encrypted auth token generated by MOSAIC-Server for this robot. |
+
+The robot UUID and token are obtained from the MOSAIC-Server dashboard when you register a new robot.
+
+---
+
+### `webrtc` (required)
+
+WebRTC ICE server configuration. At minimum a TURN server is required for robots operating behind NAT.
+
+```yaml
+webrtc:
+  ice_servers:
+    - urls:
+        - 'turn.your-domain.com:3478'
+      username: 'your-username'
+      credential: 'your-password'
+```
+
+| Field | Description |
+|:---|:---|
+| `urls` | List of TURN/STUN server URIs. Multiple entries are allowed. |
+| `username` | TURN server username. |
+| `credential` | TURN server password. |
+
+You can list multiple ICE servers under `ice_servers`. WebRTC tries them in order and uses the first one that succeeds.
+
+```yaml
+webrtc:
+  ice_servers:
+    - urls:
+        - 'stun:stun.l.google.com:19302'  # public STUN (no credentials needed — omit username/credential only if your server doesn't require them)
+    - urls:
+        - 'turn.your-domain.com:3478'
+      username: 'user'
+      credential: 'pass'
+```
+
+---
+
+## `connectors` Section
+
+Each entry in the `connectors` list declares one connector. Every entry requires `type` and `label`. Additional key-value pairs go under `params`.
+
+```yaml
+connectors:
+  - type: '<connector-type>'   # required — matches GetConnectorType() of your configurer
+    label: '<channel-name>'    # required — becomes the DataChannel or MediaTrack name
+    params:                    # optional — arbitrary key-value pairs
+      key: value
+```
+
+| Field | Required | Description |
+|:---|:---|:---|
+| `type` | Yes | Identifies which configurer to use. Must match `GetConnectorType()` return value. |
+| `label` | Yes | The DataChannel or MediaTrack name. Must match `connectorId` on the dashboard side. |
+| `params` | No | Free-form key-value map accessible as `connector_config_->params` inside `Configure()`. All values are strings. |
+
+### Built-in Connector Types
+
+| `type` | What it does |
+|:---|:---|
+| `opencv-sender-camera` | Captures from a V4L2 camera via `cv::VideoCapture` and streams video |
+| `connection-check` | Sends periodic heartbeat data; used to verify the connection is alive |
+
+---
+
+## Practical Examples
+
+### Non-ROS Robot (TurtleBot3 without ROS)
+
+```yaml
+server:
+  ws_url: 'wss://api-mosaic.your-domain.com'
+  auth:
+    type: 'simple-token'
+    robot_id: '42082865-34a3-40c1-bea7-e321622d8c39'
+    params:
+      token: '<encrypted-token>'
+  webrtc:
+    ice_servers:
+      - urls:
+          - 'turn.your-domain.com:3478'
+        username: 'user'
+        credential: 'pass'
+
+connectors:
+  - type: 'opencv-sender-camera'
+    label: 'camera_stream'
+    params:
+      fps: 30
+      camera_id: 0
+      width: 640
+      height: 480
+
+  - type: 'turtlebot-sender-laser-scan'
+    label: 'laser_scan'
+
+  - type: 'turtlebot-receiver-teleop'
+    label: 'teleop'
+```
+
+### ROS2 Robot
+
+```yaml
+server:
+  ws_url: 'wss://api-mosaic.your-domain.com'
+  auth:
+    type: 'simple-token'
+    robot_id: '<robot-uuid>'
+    params:
+      token: '<encrypted-token>'
+  webrtc:
+    ice_servers:
+      - urls:
+          - 'turn.your-domain.com:3478'
+        username: 'user'
+        credential: 'pass'
+
+connectors:
+  - type: 'ros2-sender-sensor-Image'
+    label: 'camera_stream'
+    params:
+      topic_name: '/camera/color/image_raw'
+      recordable: 'true'
+
+  - type: 'ros2-sender-sensor-NavSatFix'
+    label: 'gps'
+    params:
+      topic_name: '/gps/fix'
+
+  - type: 'ros2-sender-geometry-PoseWithCovarianceStamped'
+    label: 'map_pose'
+    params:
+      topic_name: '/amcl_pose'
+
+  - type: 'ros2-receiver-geometry-TwistStamped'
+    label: 'cmd_vel'
+    params:
+      topic_name: '/cmd_vel'
+```
+
+---
+
+## Notes
+
+{: .note }
+> All `params` values are parsed as **strings**. Convert them inside your configurer:
+> ```cpp
+> const int fps  = std::stoi(connector_config_->params.at("fps"));
+> const bool rec = connector_config_->params.at("recordable") == "true";
+> ```
+
+{: .note }
+> `label` must match the `connectorId` configured on the dashboard side exactly. A mismatch means the dashboard widget never receives data even though the robot is connected. See [Key Concept](../key-concept#label--connectorid-matching) for details.
\ No newline at end of file
diff --git a/docs/config-on-server.md b/docs/config-on-server.md
new file mode 100644
index 0000000..156fc0e
--- /dev/null
+++ b/docs/config-on-server.md
@@ -0,0 +1,123 @@
+---
+title: Config on Server
+nav_order: 5
+---
+
+# Config on Server
+
+MOSAIC-Server is configured through two mechanisms:
+
+1. **`.env` file** — secrets and database credentials, read by Docker Compose at startup
+2. **Dashboard UI** — ICE/TURN server entries and robot registrations, stored in the database at runtime
+
+---
+
+## `.env` File
+
+Copy the template before first launch:
+
+```bash
+cp deploy/prod/.env-template deploy/prod/.env
+```
+
+Then edit `deploy/prod/.env`:
+
+```bash
+POSTGRES_USER=mosaic
+POSTGRES_PASSWORD=your-strong-password
+POSTGRES_DB=mosaic
+MOSAIC_SECURITY_ENCRYPTION_KEY=your-base64-aes256-key
+```
+
+| Variable | Required | Description |
+|:---|:---|:---|
+| `POSTGRES_USER` | Yes | PostgreSQL username |
+| `POSTGRES_PASSWORD` | Yes | PostgreSQL password |
+| `POSTGRES_DB` | Yes | Database name (default: `mosaic`) |
+| `MOSAIC_SECURITY_ENCRYPTION_KEY` | Yes | AES-256 key used to encrypt robot auth tokens before storing them in the database (Base64-encoded, 32 bytes) |
+
+### Generating the Encryption Key
+
+The encryption key must be a Base64-encoded 256-bit (32-byte) AES key. Generate one with OpenSSL:
+
+```bash
+openssl rand -base64 32
+```
+
+Paste the output as the value of `MOSAIC_SECURITY_ENCRYPTION_KEY`.
+
+{: .note }
+> Never reuse the local development key (`1tcmum10T0aSvjd01iZ/9Vr04nB2GoJIo9gXCLHJKaE=`) in production. Always generate a fresh key.
+
+---
+
+## ICE / TURN Server Configuration
+
+TURN and STUN server entries are stored in the database, not in the `.env` file. They are managed through the MOSAIC-Server dashboard after deployment:
+
+1. Log in to the dashboard as an organization admin.
+2. Navigate to **Settings → ICE Servers**.
+3. Add one or more entries:
+
+| Field | Example | Description |
+|:---|:---|:---|
+| URL | `turn:turn.your-domain.com:3478` | TURN or STUN server URI |
+| Username | `your-username` | TURN credential username (leave blank for STUN-only) |
+| Credential | `your-password` | TURN credential password (leave blank for STUN-only) |
+
+The backend exposes these entries via `GET /api/v1/webrtc/ice-servers`. The dashboard fetches them automatically when initiating a WebRTC session.
+
+{: .note }
+> STUN-only works on open networks. For robots behind NAT (e.g. a mobile robot on a cellular network), a TURN server is required for reliable connections.
+
+---
+
+## Robot Registration
+
+Robots are registered through the dashboard:
+
+1. Log in as an organization admin.
+2. Navigate to **Robots → Add Robot**.
+3. Give the robot a name. The server generates:
+   - A **Robot UUID** — used as `robot_id` in the robot's `mosaic_config.yaml`
+   - An **Auth Token** — used as `params.token` in the robot's `mosaic_config.yaml`
+
+Copy both values into the robot's configuration file. See [Config on Robot](./config-on-robot) for the full YAML format.
+
+---
+
+## Advanced: Application Settings
+
+These settings live in `backend/src/main/resources/application.yml` and can be overridden via environment variables. Most deployments do not need to change them.
+
+| Setting | Default | Environment variable | Description |
+|:---|:---|:---|:---|
+| `server.port` | `9001` | `SERVER_PORT` | Backend HTTP/WebSocket port |
+| `jwt.access-token.expiration-time` | `15552000000` | `JWT_ACCESS_TOKEN_EXPIRATION_TIME` | Access token TTL in milliseconds |
+| `jwt.refresh-token.expiration-time` | `15552000000` | `JWT_REFRESH_TOKEN_EXPIRATION_TIME` | Refresh token TTL in milliseconds |
+| `file.storage.base-path` | `/mosaic-server/storage` | `FILE_STORAGE_BASE_PATH` | Base directory for uploaded files |
+| `file.storage.occupancy-map-path` | `/mosaic-server/storage/occupancy-maps` | `FILE_STORAGE_OCCUPANCY_MAP_PATH` | Directory for occupancy map files |
+
+To override a setting without modifying the source, add the environment variable to the `environment` section of `deploy/prod/docker-compose.yaml`:
+
+```yaml
+services:
+  mosaic-be:
+    environment:
+      SERVER_PORT: "9002"
+      JWT_ACCESS_TOKEN_EXPIRATION_TIME: "3600000"
+```
+
+---
+
+## Services Overview
+
+| Service | Image | Port | Role |
+|:---|:---|:---|:---|
+| `mosaic-be` | `mosaic-be:latest` | `9001` | Spring WebFlux backend (API + WebSocket signaling) |
+| `mosaic-fe` | `mosaic-fe:latest` | `8080` | React frontend served by Nginx |
+| `mosaic-db` | `postgres:17` | internal | PostgreSQL database |
+
+Database schema migrations (Flyway) run automatically when the backend starts. No manual migration step is required.
+
+See [Custom Deployment](./custom-deployment) for the full Docker Compose setup and Nginx reverse proxy instructions.
\ No newline at end of file
diff --git a/docs/contact.md b/docs/contact.md
new file mode 100644
index 0000000..d360b62
--- /dev/null
+++ b/docs/contact.md
@@ -0,0 +1,49 @@
+---
+title: Contact
+nav_order: 10
+---
+# Contact
+
+If you have questions, bug reports, or collaboration inquiries regarding MOSAIC, please reach out through the channels below.
+
+---
+
+## GitHub Issues
+
+For technical questions and bug reports, the preferred channel is GitHub Issues on the relevant repository.
+
+| Repository | Issues |
+|:---|:---|
+| [mosaic-core](https://github.com/ACSL-MOSAIC/mosaic-core) | C++ WebRTC library |
+| [MOSAIC-Server](https://github.com/ACSL-MOSAIC/MOSAIC-Server) | Backend & frontend dashboard |
+| [mosaic-ros2](https://github.com/ACSL-MOSAIC/mosaic-ros2) | ROS2 connector packages |
+| [mosaic-docs](https://github.com/ACSL-MOSAIC/mosaic-docs) | Documentation |
+
+---
+
+## Maintainers
+
+MOSAIC is developed and maintained by the **[YOUR LAB NAME]** at **[YOUR INSTITUTION]**.
+
+| Name | Role | Email |
+|:---|:---|:---|
+| [Your Name] | Lead Developer | your.email@institution.ac.kr |
+| [Collaborator Name] | Contributor | collaborator@institution.ac.kr |
+
+---
+
+## Lab / Research Group
+
+**Your Lab Name**
+Your Institution / Department
+Address Line 1, City, Country
+
+Website: [https://your-lab-website.ac.kr](https://your-lab-website.ac.kr)
+
+---
+
+## General Inquiries
+
+For general inquiries, collaboration proposals, or anything not suited for a GitHub Issue, please email:
+
+**your.email@institution.ac.kr**
diff --git a/docs/contribution.md b/docs/contribution.md
new file mode 100644
index 0000000..a7d6570
--- /dev/null
+++ b/docs/contribution.md
@@ -0,0 +1,123 @@
+---
+title: Contribution
+nav_order: 9
+---
+
+# Contribution
+
+Contributions to MOSAIC are welcome. This page explains how to report issues, propose changes, and submit pull requests across the MOSAIC repositories.
+
+---
+
+## Repositories
+
+| Repository | Language | What it contains |
+|:---|:---|:---|
+| [mosaic-core](https://github.com/ACSL-MOSAIC/mosaic-core) | C++17 | Robot-side WebRTC library |
+| [MOSAIC-Server](https://github.com/ACSL-MOSAIC/MOSAIC-Server) | Java / TypeScript | Backend + frontend dashboard |
+| [mosaic-ros2](https://github.com/ACSL-MOSAIC/mosaic-ros2) | C++ / Python | ROS2 connector packages |
+| [mosaic-docs](https://github.com/ACSL-MOSAIC/mosaic-docs) | Markdown | This documentation site |
+
+---
+
+## Reporting Issues
+
+Before opening an issue, search the existing issues on the relevant repository to avoid duplicates.
+
+When filing a bug report, include:
+
+- A clear description of the problem and the expected behavior
+- Steps to reproduce the issue
+- Your environment (OS, ROS2 distribution, compiler version, etc.)
+- Relevant log output or error messages
+
+For feature requests, describe the use case and why the existing API does not cover it.
+
+---
+
+## Submitting a Pull Request
+
+1. **Fork** the repository and create a branch from `main`:
+
+   ```bash
+   git checkout -b feat/your-feature-name
+   ```
+
+2. **Make your changes.** Keep commits focused — one logical change per commit.
+
+3. **Test your changes** before opening a PR:
+   - mosaic-core: build with `-DBUILD_TESTS=ON` and run the test suite
+   - MOSAIC-Server backend: run `./gradlew test`
+   - MOSAIC-Server frontend: run `npm run lint && npm test`
+
+4. **Open a Pull Request** against the `main` branch. Fill in the PR template with:
+   - What problem this solves or what feature it adds
+   - How it was tested
+   - Any breaking changes
+
+---
+
+## Coding Style
+
+### mosaic-core (C++)
+
+- Follow the existing code style (Google C++ Style as a baseline).
+- Use `snake_case` for variables and functions, `PascalCase` for classes.
+- Keep public headers clean — implementation details go in `.cpp` or via PIMPL.
+- Add unit tests under `test/` for new functionality.
+
+### MOSAIC-Server backend (Java)
+
+- Follow standard Spring Boot conventions.
+- Reactive types (`Mono`, `Flux`) throughout — avoid blocking calls.
+- New database schema changes go in a new Flyway migration file (`V{N}__description.sql`).
+
+### MOSAIC-Server frontend (TypeScript / React)
+
+- Run `npm run lint` and fix all warnings before committing.
+- Follow the existing hook and context patterns when adding new store or channel types.
+- Components go under `src/components/`, hooks under `src/hooks/`.
+
+### mosaic-ros2 (C++ / Python)
+
+- Follow ROS2 coding conventions and `ament_cmake` package structure.
+- Package names use lowercase with hyphens (`mosaic-ros2-sensor`).
+
+---
+
+## Commit Messages
+
+Use the conventional commit format:
+
+```
+<type>: <short summary>
+
+<optional body>
+```
+
+Common types: `feat`, `fix`, `docs`, `refactor`, `test`, `chore`
+
+Examples:
+
+```
+feat: add DataChannelByteReceivable base class
+fix: stop capture thread before joining on disconnect
+docs: add Config on Robot page
+```
+
+---
+
+## Documentation
+
+Documentation lives in the [mosaic-docs](https://github.com/ACSL-MOSAIC/mosaic-docs) repository and is built with Jekyll + Just the Docs.
+
+To preview locally:
+
+```bash
+bundle install
+bundle exec jekyll serve
+```
+
+The site is served at `http://localhost:4000`.
+
+When adding a new page, set the `nav_order` and `parent` front matter fields to place it correctly in the sidebar.
\ No newline at end of file
diff --git a/docs/custom-connector/data-channel-receiver.md b/docs/custom-connector/data-channel-receiver.md
new file mode 100644
index 0000000..1b6a239
--- /dev/null
+++ b/docs/custom-connector/data-channel-receiver.md
@@ -0,0 +1,225 @@
+---
+title: Add Data Channel Receiver
+parent: Add your Custom Connector
+nav_order: 3
+---
+
+# Add Data Channel Receiver
+
+A **Data Channel Receiver** accepts commands or data sent from the operator's dashboard to the robot over a WebRTC DataChannel. Typical uses include velocity commands, mode switches, or any control input.
+
+---
+
+## Class Hierarchy
+
+```
+IDataChannelHandler                      (interface)
+└── ADataChannelHandler                  (abstract base)
+    └── IDataChannelReceivable           (receives raw DataBuffer)
+        └── DataChannelReceivable<T>     (template — deserialize then handle)
+            ├── DataChannelStringReceivable   (T = std::string)
+            ├── DataChannelJsonReceivable     (T = Json::Value)
+            └── DataChannelByteReceivable     (T = std::vector<uint8_t>)
+```
+
+Pick the base class that matches the format your dashboard sends:
+
+| Base class | Input format | When to use |
+|:---|:---|:---|
+| `DataChannelStringReceivable` | Plain UTF-8 string | Simple text commands |
+| `DataChannelJsonReceivable` | JSON object | Structured control data |
+| `DataChannelByteReceivable` | Raw binary | Protobuf or custom binary protocol |
+| `DataChannelReceivable<T>` | Any type | Custom deserialization |
+
+---
+
+## Step 1: Implement the Receiver
+
+Override `HandleData()` with your logic. Deserialization from the raw `DataBuffer` is handled by the base class automatically.
+
+### JSON Example (most common)
+
+```cpp
+#include <mosaic/handlers/data_channel/data_channel_receivable.hpp>
+#include <json/json.h>
+
+class MyCommandReceiver : public mosaic::handlers::DataChannelJsonReceivable {
+public:
+    explicit MyCommandReceiver(const std::string& label)
+        : DataChannelJsonReceivable(label) {}
+
+    void HandleData(const Json::Value& data) override {
+        if (!data.isMember("linear_x") || !data.isMember("angular_z")) {
+            MOSAIC_LOG_ERROR("Invalid command: missing fields.");
+            return;
+        }
+
+        const float linear_x  = data["linear_x"].asFloat();
+        const float angular_z = data["angular_z"].asFloat();
+
+        // Apply the command to your robot
+        robot_.SetVelocity(linear_x, angular_z);
+    }
+
+private:
+    MyRobot& robot_;
+};
+```
+
+### String Example
+
+```cpp
+class MyModeReceiver : public mosaic::handlers::DataChannelStringReceivable {
+public:
+    explicit MyModeReceiver(const std::string& label)
+        : DataChannelStringReceivable(label) {}
+
+    void HandleData(const std::string& data) override {
+        if (data == "autonomous") {
+            robot_.SetMode(Mode::Autonomous);
+        } else if (data == "manual") {
+            robot_.SetMode(Mode::Manual);
+        }
+    }
+};
+```
+
+### Custom Type Example
+
+Use `DataChannelReceivable<T>` when you need to deserialize from a binary format (e.g. Protobuf):
+
+```cpp
+struct MyCommand { float linear_x; float angular_z; };
+
+class MyBinaryReceiver : public mosaic::handlers::DataChannelReceivable<MyCommand> {
+public:
+    explicit MyBinaryReceiver(const std::string& label)
+        : DataChannelReceivable(label) {}
+
+protected:
+    MyCommand ConvertBufferToData(const webrtc::DataBuffer& buffer) override {
+        // Deserialize from the raw buffer (e.g. Protobuf, custom struct)
+        MyCommand cmd;
+        std::memcpy(&cmd, buffer.data.data<uint8_t>(), sizeof(MyCommand));
+        return cmd;
+    }
+
+    void HandleData(const MyCommand& cmd) override {
+        robot_.SetVelocity(cmd.linear_x, cmd.angular_z);
+    }
+};
+```
+
+---
+
+## Step 2: Implement the Configurer
+
+Inherit from `ADCHandlerConfigurer`:
+
+```cpp
+#include <mosaic/auto_configurer/connector/configurable_connectors.hpp>
+
+class MyCommandConfigurer : public mosaic::auto_configurer::ADCHandlerConfigurer {
+public:
+    std::string GetConnectorType() const override {
+        return "my-command-receiver";   // must match the YAML 'type' field
+    }
+
+    void Configure() override {
+        handler_ = std::make_shared<MyCommandReceiver>(connector_config_->label);
+    }
+};
+```
+
+---
+
+## Step 3: Register and Configure
+
+```cpp
+#include <mosaic/auto_configurer/connector/connector_resolver.hpp>
+#include <mosaic/auto_configurer/auto_configurer.hpp>
+
+int main() {
+    mosaic::auto_configurer::ConnectorResolver::GetInstance()
+        .RegisterConfigurableConnector<MyCommandConfigurer>();
+
+    mosaic::auto_configurer::AutoConfigurer auto_configurer;
+    auto_configurer.AutoConfigure("mosaic_config.yaml");
+
+    auto connector = auto_configurer.GetMosaicConnector();
+
+    // HandleData() is called automatically on every incoming message.
+    // No polling required in your main loop.
+
+    std::this_thread::sleep_until(std::chrono::steady_clock::time_point::max());
+    connector->ShuttingDown();
+}
+```
+
+{: .note }
+> `HandleData()` is invoked on the WebRTC network thread. If your handler accesses shared state, protect it with a mutex or use an atomic flag (e.g. `std::atomic<bool>`) to hand off the data to your main loop safely.
+
+---
+
+## Step 4: YAML Configuration
+
+```yaml
+connectors:
+  - type: 'my-command-receiver'
+    label: 'cmd_vel'
+```
+
+---
+
+## Built-in Examples
+
+**TurtleBot3 teleop receiver** (`mosaic-turtlebot3-wo-ros-example`)
+
+Receives `{ "linear_x": 0.5, "angular_z": -0.3 }` from the dashboard and writes the values to a shared context struct that the main loop reads:
+
+```cpp
+void TeleopReceiver::HandleData(const Json::Value& data) {
+    ctx_->teleop->linear_x = data["linear_x"].asFloat();
+    ctx_->teleop->angular_z = data["angular_z"].asFloat();
+    ctx_->teleop_changed->store(true);
+}
+```
+
+**ROS2 Twist receiver** (`mosaic-ros2-geometry`)
+
+Receives a direction string (`"up"`, `"down"`, `"left"`, `"right"`, `"stop"`) and publishes the corresponding `geometry_msgs/Twist` to a ROS2 topic:
+
+```cpp
+void TwistDataChannel::HandleData(const TwistMessage& data) {
+    if      (data.direction == "up")    SendTwist( 2.0,  0.0);
+    else if (data.direction == "down")  SendTwist(-2.0,  0.0);
+    else if (data.direction == "left")  SendTwist( 2.0,  2.0);
+    else if (data.direction == "right") SendTwist( 2.0, -2.0);
+    else if (data.direction == "stop")  SendTwist( 0.0,  0.0);
+}
+```
+
+---
+
+## ROS2: Using `ROS2ADCHandlerConfigurer`
+
+For ROS2 projects, inherit from `ROS2ADCHandlerConfigurer`. The configurer gets access to `mosaic_node_` so you can create publishers inside `Configure()`:
+
+```cpp
+#include <mosaic-ros2-base/configurer/ros2_a_dc_handler_configurer.h>
+
+class MyROS2CommandConfigurer : public mosaic::ros2::ROS2ADCHandlerConfigurer {
+public:
+    std::string GetConnectorType() const override {
+        return "my-ros2-command-receiver";
+    }
+
+    void Configure() override {
+        auto publisher = mosaic_node_->create_publisher<geometry_msgs::msg::Twist>(
+            connector_config_.params.at("topic_name"), 10);
+
+        mosaic_node_->AddPublisher(publisher);
+        handler_ = std::make_shared<MyCommandReceiver>(connector_config_.label, publisher);
+    }
+};
+```
\ No newline at end of file
diff --git a/docs/custom-connector/data-channel-sender.md b/docs/custom-connector/data-channel-sender.md
new file mode 100644
index 0000000..aa7935a
--- /dev/null
+++ b/docs/custom-connector/data-channel-sender.md
@@ -0,0 +1,186 @@
+---
+title: Add Data Channel Sender
+parent: Add your Custom Connector
+nav_order: 2
+---
+
+# Add Data Channel Sender
+
+A **Data Channel Sender** pushes data from the robot to the operator over a WebRTC DataChannel. It is suited for telemetry, sensor readings, GPS coordinates, or any structured data you want to display on the dashboard.
+
+---
+
+## Class Hierarchy
+
+```
+IDataChannelHandler         (interface)
+└── ADataChannelHandler     (abstract base)
+    └── DataChannelSendable (use this)
+        └── YourSender      (your implementation)
+```
+
+---
+
+## Step 1: Implement the Sender
+
+Inherit from `DataChannelSendable` and add a method that calls one of the built-in send helpers.
+
+```cpp
+#include <mosaic/handlers/data_channel/data_channel_sendable.hpp>
+#include <json/json.h>
+
+class MySensor;  // forward declaration of your data source
+
+class MySensorDataChannel : public mosaic::handlers::DataChannelSendable {
+public:
+    explicit MySensorDataChannel(const std::string& label)
+        : DataChannelSendable(label) {}
+
+    // Call this whenever you have new data to send
+    void OnDataReceived(const MySensor& sensor) {
+        if (!Sendable()) return;  // drop if peer is not connected yet
+
+        Json::Value payload;
+        payload["value"] = sensor.value;
+        payload["timestamp"] = sensor.timestamp_us;
+
+        SendJson(payload);
+    }
+};
+```
+
+### Send Methods
+
+`DataChannelSendable` provides four send helpers:
+
+| Method | Data format | Binary flag |
+|:---|:---|:---|
+| `SendString(str)` | UTF-8 string | `false` |
+| `SendStringAsByte(str)` | String as binary blob | `true` |
+| `SendJson(json)` | JSON serialized to string | `false` |
+| `Send(DataBuffer, isAsync)` | Raw `webrtc::DataBuffer` | — |
+
+All methods accept an optional `isAsync` flag (default `false`). When `true`, the buffer is queued and sent via `SendAsync`, which is safer when sending large or frequent data from a background thread.
+
+{: .note }
+> Always check `Sendable()` before sending. It returns `true` only while the DataChannel is in the `kOpen` state. Calls made before the peer connects are silently dropped.
+
+---
+
+## Step 2: Implement the Configurer
+
+Inherit from `ADCHandlerConfigurer` to integrate with the AutoConfigurer system.
+
+```cpp
+#include <mosaic/auto_configurer/connector/configurable_connectors.hpp>
+
+class MySensorConfigurer : public mosaic::auto_configurer::ADCHandlerConfigurer {
+public:
+    std::string GetConnectorType() const override {
+        return "my-sensor-sender";   // must match the YAML 'type' field
+    }
+
+    void Configure() override {
+        handler_ = std::make_shared<MySensorDataChannel>(connector_config_->label);
+    }
+};
+```
+
+---
+
+## Step 3: Register and Send
+
+Register the configurer, run `AutoConfigure()`, then send data from your main loop:
+
+```cpp
+#include <mosaic/auto_configurer/connector/connector_resolver.hpp>
+#include <mosaic/auto_configurer/auto_configurer.hpp>
+
+int main() {
+    mosaic::auto_configurer::ConnectorResolver::GetInstance()
+        .RegisterConfigurableConnector<MySensorConfigurer>();
+
+    mosaic::auto_configurer::AutoConfigurer auto_configurer;
+    auto_configurer.AutoConfigure("mosaic_config.yaml");
+
+    // Retrieve your handler after configuration
+    auto connector = auto_configurer.GetMosaicConnector();
+
+    // Get a typed pointer to your handler
+    // (store it during Configure() for easier access)
+    while (true) {
+        MySensor reading = sensor.Read();
+        my_data_channel->OnDataReceived(reading);
+        std::this_thread::sleep_for(std::chrono::milliseconds(100));
+    }
+
+    connector->ShuttingDown();
+}
+```
+
+{: .note }
+> A convenient pattern is to store the `shared_ptr` to your handler inside the Configurer and expose a getter, so the main loop can retrieve it after `AutoConfigure()`.
+
+---
+
+## Step 4: YAML Configuration
+
+```yaml
+connectors:
+  - type: 'my-sensor-sender'
+    label: 'sensor_data'
+    params:
+      topic_name: '/my/sensor/topic'   # custom params as needed
+```
+
+The `label` becomes the DataChannel name used by the dashboard to identify the stream.
+
+---
+
+## Built-in Example: NavSatFix Sender
+
+`ros2-sender-sensor-NavSatFix` in `mosaic-ros2-sensor` is a complete reference implementation of this pattern. It subscribes to a `sensor_msgs/NavSatFix` ROS2 topic and sends the GPS coordinates as JSON:
+
+```cpp
+// On each message callback:
+Json::Value json;
+json["latitude"]  = msg->latitude;
+json["longitude"] = msg->longitude;
+json["altitude"]  = msg->altitude;
+json["timestamp"] = timestamp_us;
+SendJson(json);
+```
+
+---
+
+## ROS2: Using `ROS2ADCHandlerConfigurer`
+
+For ROS2 projects, inherit from `ROS2ADCHandlerConfigurer` instead of `ADCHandlerConfigurer`. This gives access to the shared `MosaicNode` for creating topic subscriptions.
+
+```cpp
+#include <mosaic-ros2-base/configurer/ros2_a_dc_handler_configurer.h>
+
+class MyROS2SensorConfigurer : public mosaic::ros2::ROS2ADCHandlerConfigurer {
+public:
+    std::string GetConnectorType() const override {
+        return "my-ros2-sensor-sender";
+    }
+
+    void Configure() override {
+        auto channel = std::make_shared<MySensorDataChannel>(connector_config_.label);
+        handler_ = channel;
+
+        subscription_ = mosaic_node_->create_subscription<MySensorMsg>(
+            connector_config_.params.at("topic_name"),
+            10,
+            [channel](MySensorMsg::SharedPtr msg) {
+                channel->OnDataReceived(*msg);
+            });
+
+        mosaic_node_->AddSubscription(subscription_);
+    }
+
+private:
+    std::shared_ptr<rclcpp::Subscription<MySensorMsg>> subscription_;
+};
+```
\ No newline at end of file
diff --git a/docs/custom-connector/index.md b/docs/custom-connector/index.md
new file mode 100644
index 0000000..a6cb5c3
--- /dev/null
+++ b/docs/custom-connector/index.md
@@ -0,0 +1,6 @@
+---
+title: Add your Custom Connector
+nav_order: 7
+has_children: true
+---
+# Add your Custom Connector
\ No newline at end of file
diff --git a/docs/custom-connector/introduction.md b/docs/custom-connector/introduction.md
new file mode 100644
index 0000000..36009d9
--- /dev/null
+++ b/docs/custom-connector/introduction.md
@@ -0,0 +1,185 @@
+---
+title: Introduction
+parent: Add your Custom Connector
+nav_order: 1
+---
+
+# Introduction
+
+A **Connector** is the unit that bridges your robot's data with the MOSAIC dashboard over WebRTC. Each connector wraps a single handler — a video track, a data channel sender, or a data channel receiver — and is described by a `type` field in the YAML configuration file.
+
+mosaic-core ships with a small set of built-in connectors (e.g. `opencv-sender-camera`, `connection-check`). When you need to send custom sensor data, receive custom commands, or stream video from a non-standard source, you implement your own connector.
+
+---
+
+## How It All Fits Together
+
+```
+mosaic_config.yaml
+       │
+       ▼
+  AutoConfigurer                 ← reads YAML, orchestrates everything
+       │
+       ├─ ConnectorResolver      ← maps YAML 'type' → Configurer factory
+       │       │
+       │       └─ YourConfigurer ← creates and wires your Handler
+       │
+       └─ MosaicConnector        ← holds all active connectors, manages WebRTC
+```
+
+---
+
+## ConnectorResolver
+
+`ConnectorResolver` is a **singleton** registry that maps each connector `type` string to a factory that produces the corresponding configurer.
+
+### Built-in Registrations
+
+The resolver pre-registers the following types at startup:
+
+| Type string | Description |
+|:---|:---|
+| `opencv-sender-camera` | Captures frames from a V4L2 camera via OpenCV and streams them |
+| `connection-check` | Sends periodic heartbeat data to verify the connection is alive |
+
+### Registering a Custom Connector
+
+Call `RegisterConfigurableConnector<T>()` on the singleton before `AutoConfigure()` runs:
+
+```cpp
+#include <mosaic/auto_configurer/connector/connector_resolver.hpp>
+
+mosaic::auto_configurer::ConnectorResolver::GetInstance()
+    .RegisterConfigurableConnector<MyCommandConfigurer>();
+```
+
+Internally this stores a `ConfigurableConnectorFactory<T>` for `MyCommandConfigurer`. When the YAML `type` field matches `GetConnectorType()` on your configurer, the factory instantiates and runs it.
+
+---
+
+## AutoConfigurer
+
+`AutoConfigurer` reads the YAML file and drives the full setup sequence.
+
+### AutoConfigure() Flow
+
+```
+AutoConfigure("mosaic_config.yaml")
+    │
+    ├─ 1. ReadConfigs()            — parse YAML into ConnectorConfig objects
+    ├─ 2. CreateMosaicConnector()  — instantiate the MosaicConnector (ICE, TURN, etc.)
+    ├─ 3. ResolveConnectors()      — look up each 'type' in ConnectorResolver
+    ├─ 4. BeforeConfigure()        — pre-configuration hook (e.g. ROS2 node init)
+    ├─ 5. ConfigureConnectors()    — call Configure() on each resolved configurer
+    └─ 6. AfterConfigure()         — post-configuration hook (e.g. register publishers)
+```
+
+`Configure()` on your configurer runs at step 5. By that point `connector_config_` (the parsed YAML block for your connector) is already set, so you can safely read `connector_config_->label` and `connector_config_->params`.
+
+### YAML Structure
+
+```yaml
+mosaic:
+  server_url: 'wss://api-mosaic.your-domain.com/ws/robot'
+  robot_id: 'my-robot'
+  password: 'secret'
+  stun_server_url: 'stun:stun.l.google.com:19302'
+
+connectors:
+  - type: 'my-sensor-sender'      # matched against GetConnectorType()
+    label: 'sensor_data'          # becomes the DataChannel or MediaTrack name
+    params:
+      topic_name: '/my/sensor'    # arbitrary key-value pairs for your configurer
+```
+
+---
+
+## Configurer Types
+
+Choose the base class that matches what your connector does:
+
+| Base class | Connector kind | Detailed guide |
+|:---|:---|:---|
+| `ADCHandlerConfigurer` | Single DataChannel (send **or** receive) | [Data Channel Sender](./data-channel-sender) · [Data Channel Receiver](./data-channel-receiver) |
+| `AMultipleDCHandlerConfigurer` | Multiple DataChannels in one configurer | — |
+| `AMTHandlerConfigurer` | Video / audio MediaTrack | [Media Streamer](./media-streamer) |
+
+For ROS2 projects, use the `ROS2A*Configurer` variants (`ROS2ADCHandlerConfigurer`, `ROS2AMTHandlerConfigurer`) which expose the shared `MosaicNode` for creating publishers and subscriptions.
+
+---
+
+## Minimal End-to-End Example
+
+Below is the shortest possible custom connector — a JSON data channel sender:
+
+**1. The Handler**
+
+```cpp
+#include <mosaic/handlers/data_channel/data_channel_sendable.hpp>
+
+class MySensorChannel : public mosaic::handlers::DataChannelSendable {
+public:
+    explicit MySensorChannel(const std::string& label)
+        : DataChannelSendable(label) {}
+
+    void Send(float value) {
+        if (!Sendable()) return;
+        Json::Value payload;
+        payload["value"] = value;
+        SendJson(payload);
+    }
+};
+```
+
+**2. The Configurer**
+
+```cpp
+#include <mosaic/auto_configurer/connector/configurable_connectors.hpp>
+
+class MySensorConfigurer : public mosaic::auto_configurer::ADCHandlerConfigurer {
+public:
+    std::string GetConnectorType() const override { return "my-sensor"; }
+
+    void Configure() override {
+        channel_ = std::make_shared<MySensorChannel>(connector_config_->label);
+        handler_ = channel_;
+    }
+
+    std::shared_ptr<MySensorChannel> channel_;
+};
+```
+
+**3. main()**
+
+```cpp
+#include <mosaic/auto_configurer/connector/connector_resolver.hpp>
+#include <mosaic/auto_configurer/auto_configurer.hpp>
+
+int main() {
+    auto& resolver = mosaic::auto_configurer::ConnectorResolver::GetInstance();
+    resolver.RegisterConfigurableConnector<MySensorConfigurer>();
+
+    mosaic::auto_configurer::AutoConfigurer auto_configurer;
+    auto_configurer.AutoConfigure("mosaic_config.yaml");
+
+    auto connector = auto_configurer.GetMosaicConnector();
+
+    while (true) {
+        float reading = sensor.Read();
+        my_channel->Send(reading);
+        std::this_thread::sleep_for(std::chrono::milliseconds(100));
+    }
+
+    connector->ShuttingDown();
+}
+```
+
+**4. YAML**
+
+```yaml
+connectors:
+  - type: 'my-sensor'
+    label: 'sensor_data'
+```
+
+The following pages walk through each connector type in detail.
\ No newline at end of file
diff --git a/docs/custom-connector/media-streamer.md b/docs/custom-connector/media-streamer.md
new file mode 100644
index 0000000..8058117
--- /dev/null
+++ b/docs/custom-connector/media-streamer.md
@@ -0,0 +1,212 @@
+---
+title: Add Media Streamer
+parent: Add your Custom Connector
+nav_order: 4
+---
+
+# Add Media Streamer
+
+A **Media Streamer** sends a live video stream from the robot to the operator's browser via a WebRTC MediaTrack. Internally, frames are passed as `cv::Mat` objects and encoded by the WebRTC layer.
+
+---
+
+## Class Hierarchy
+
+```
+IMediaTrackHandler        (interface)
+└── AMediaTrackHandler    (abstract base — use this)
+    └── YourMediaTrack    (your implementation)
+```
+
+`AMediaTrackHandler` also inherits from `Recordable`, which provides optional video-to-file recording.
+
+---
+
+## Step 1: Implement the Media Track
+
+Inherit from `AMediaTrackHandler` and implement `Start()` and `Stop()`. Call `SendFrame()` whenever a new frame is ready.
+
+```cpp
+#include <mosaic/handlers/media_track/media_track_handler.hpp>
+#include <opencv2/opencv.hpp>
+#include <thread>
+#include <chrono>
+
+class MyVideoTrack : public mosaic::handlers::AMediaTrackHandler {
+public:
+    explicit MyVideoTrack(const std::string& track_name)
+        : AMediaTrackHandler(track_name, /* recordable= */ false) {}
+
+    ~MyVideoTrack() override {
+        MyVideoTrack::Stop();
+    }
+
+    void Start() override {
+        if (IsRunning()) return;
+
+        SetRunning(true);
+        SetStopFlag(false);
+        start_time_ = std::chrono::steady_clock::now();
+
+        thread_ = std::make_unique<std::thread>([this]() {
+            while (!GetStopFlag()) {
+                cv::Mat frame = CaptureFrame();   // your capture logic
+                if (!frame.empty()) {
+                    SendFrame(frame, start_time_);
+                }
+                std::this_thread::sleep_for(std::chrono::milliseconds(33)); // ~30 fps
+            }
+        });
+    }
+
+    void Stop() override {
+        if (!IsRunning()) return;
+
+        SetStopFlag(true);
+        if (thread_ && thread_->joinable()) {
+            thread_->join();
+        }
+        thread_.reset();
+        SetRunning(false);
+    }
+
+private:
+    cv::Mat CaptureFrame() {
+        // Return the latest frame as a cv::Mat (BGR format)
+        // e.g. from a camera, sensor, or simulation renderer
+        return cv::Mat();
+    }
+
+    std::chrono::steady_clock::time_point start_time_;
+    std::unique_ptr<std::thread> thread_;
+};
+```
+
+### Key Points
+
+| Method / Field | Description |
+|:---|:---|
+| `Start()` | Called when a WebRTC peer connects. Start your capture thread here. |
+| `Stop()` | Called on disconnect. Join your thread and release resources. |
+| `SendFrame(frame, start_time)` | Encodes and sends the frame to the peer. Call this from inside the loop. |
+| `IsRunning()` / `SetRunning(bool)` | Guards against double-start. |
+| `GetStopFlag()` / `SetStopFlag(bool)` | Use as the loop exit condition. |
+| `recordable` constructor arg | Set `true` to enable video-to-file recording via `Recordable`. |
+
+{: .note }
+> `SendFrame()` expects frames in **BGR** format (OpenCV default). If your source produces RGB or RGBA, convert with `cv::cvtColor` before calling `SendFrame()`.
+
+---
+
+## Step 2: Implement the Configurer
+
+Inherit from `AMTHandlerConfigurer` to wire your track into the AutoConfigurer system.
+
+```cpp
+#include <mosaic/auto_configurer/connector/configurable_connectors.hpp>
+
+class MyVideoConfigurer : public mosaic::auto_configurer::AMTHandlerConfigurer {
+public:
+    std::string GetConnectorType() const override {
+        return "my-video-sender";   // must match the YAML 'type' field
+    }
+
+    void Configure() override {
+        // Read params from the YAML config
+        const auto fps = std::stoi(connector_config_->params.at("fps"));
+
+        handler_ = std::make_shared<MyVideoTrack>(connector_config_->label);
+    }
+};
+```
+
+---
+
+## Step 3: Register and Configure
+
+Register the configurer before calling `AutoConfigure()`:
+
+```cpp
+#include <mosaic/auto_configurer/connector/connector_resolver.hpp>
+#include <mosaic/auto_configurer/auto_configurer.hpp>
+
+int main() {
+    mosaic::auto_configurer::ConnectorResolver::GetInstance()
+        .RegisterConfigurableConnector<MyVideoConfigurer>();
+
+    mosaic::auto_configurer::AutoConfigurer auto_configurer;
+    auto_configurer.AutoConfigure("mosaic_config.yaml");
+
+    auto connector = auto_configurer.GetMosaicConnector();
+
+    // Block until interrupted
+    std::this_thread::sleep_until(std::chrono::steady_clock::time_point::max());
+
+    connector->ShuttingDown();
+}
+```
+
+---
+
+## Step 4: YAML Configuration
+
+```yaml
+connectors:
+  - type: 'my-video-sender'
+    label: 'camera'
+    params:
+      fps: 30
+```
+
+The `label` becomes the WebRTC track name visible on the dashboard. `params` are available inside `Configure()` via `connector_config_->params`.
+
+---
+
+## Built-in Example: OpenCV Camera
+
+mosaic-core ships `opencv-sender-camera`, which is a complete reference implementation of this pattern.
+
+```yaml
+connectors:
+  - type: 'opencv-sender-camera'
+    label: 'camera_stream'
+    params:
+      fps: 30
+      camera_id: 0
+      width: 640
+      height: 480
+```
+
+It opens a V4L2 device with `cv::VideoCapture`, reads frames in a loop, and calls `SendFrame()` — exactly the same structure as the example above.
+
+---
+
+## ROS2: Using `ROS2AMTHandlerConfigurer`
+
+For ROS2 projects, inherit from `ROS2AMTHandlerConfigurer` instead. This gives access to the shared `MosaicNode` for creating subscriptions.
+
+```cpp
+#include <mosaic-ros2-base/configurer/ros2_a_mt_handler_configurer.h>
+
+class MyROS2VideoConfigurer : public mosaic::ros2::ROS2AMTHandlerConfigurer {
+public:
+    std::string GetConnectorType() const override {
+        return "my-ros2-video-sender";
+    }
+
+    void Configure() override {
+        handler_ = std::make_shared<MyVideoTrack>(connector_config_.label, mosaic_node_);
+
+        const auto sub = mosaic_node_->create_subscription<sensor_msgs::msg::Image>(
+            connector_config_.params.at("topic_name"),
+            10,
+            [this](sensor_msgs::msg::Image::SharedPtr msg) {
+                // convert and forward to MyVideoTrack
+            });
+
+        mosaic_node_->AddSubscription(sub);
+    }
+};
+```
+
+The built-in `ros2-sender-sensor-Image` connector follows this exact pattern — see `mosaic-ros2-sensor` for the full implementation.
\ No newline at end of file
diff --git a/docs/custom-deployment.md b/docs/custom-deployment.md
new file mode 100644
index 0000000..19d011e
--- /dev/null
+++ b/docs/custom-deployment.md
@@ -0,0 +1,138 @@
+---
+title: Custom Deployment
+nav_order: 8
+---
+
+# Custom Deployment
+
+This page describes how to deploy **MOSAIC-Server** using Docker Compose.
+
+MOSAIC-Server consists of three services:
+
+| Service | Image | Port | Role |
+|:---|:---|:---|:---|
+| `mosaic-be` | `mosaic-be:latest` | `9001` | Spring WebFlux backend |
+| `mosaic-fe` | `mosaic-fe:latest` | `8080` | React frontend (Nginx) |
+| `mosaic-db` | `postgres:17` | internal | PostgreSQL database |
+
+---
+
+## Prerequisites
+
+- Docker Engine 24+
+- Docker Compose v2
+
+---
+
+## 1. Clone the Repository
+
+```bash
+git clone https://github.com/ACSL-MOSAIC/MOSAIC-Server.git
+cd MOSAIC-Server
+```
+
+---
+
+## 2. Build the Images
+
+**Backend** (Spring WebFlux — multi-stage build with Azul Zulu JDK 21):
+
+```bash
+docker build -t mosaic-be:latest ./backend
+```
+
+**Frontend** (React → Nginx):
+
+```bash
+docker build -t mosaic-fe:latest ./frontend
+```
+
+---
+
+## 3. Configure Environment Variables
+
+```bash
+cp deploy/prod/.env-template deploy/prod/.env
+```
+
+Edit `deploy/prod/.env`:
+
+```bash
+POSTGRES_USER=mosaic
+POSTGRES_PASSWORD=your-strong-password
+POSTGRES_DB=mosaic
+MOSAIC_SECURITY_ENCRYPTION_KEY=your-base64-encoded-aes256-key
+```
+
+| Variable | Description |
+|:---|:---|
+| `POSTGRES_USER` | PostgreSQL username |
+| `POSTGRES_PASSWORD` | PostgreSQL password |
+| `POSTGRES_DB` | Database name (default: `mosaic`) |
+| `MOSAIC_SECURITY_ENCRYPTION_KEY` | AES-256 key for encrypting robot auth tokens (Base64-encoded) |
+
+---
+
+## 4. Run
+
+```bash
+docker compose -f deploy/prod/docker-compose.yaml up -d
+```
+
+Database schema migrations (Flyway) run automatically on backend startup. No manual migration step is required.
+
+### Verify
+
+```bash
+docker compose -f deploy/prod/docker-compose.yaml ps
+```
+
+```
+NAME         STATUS    PORTS
+mosaic-be    running   0.0.0.0:9001->9001/tcp
+mosaic-fe    running   0.0.0.0:8080->80/tcp
+mosaic-db    running
+```
+
+---
+
+## 5. Nginx Reverse Proxy (Production)
+
+In production, place an Nginx reverse proxy in front to handle TLS and route traffic:
+
+- `api-mosaic.your-domain.com` → backend (`localhost:9001`)
+- `mosaic.your-domain.com` → frontend (`localhost:8080`)
+
+WebSocket routes (`/ws/*`) must forward the `Upgrade` header:
+
+```nginx
+location /ws {
+    proxy_pass http://backend;
+    proxy_http_version 1.1;
+    proxy_set_header Upgrade $http_upgrade;
+    proxy_set_header Connection "upgrade";
+    proxy_set_header Host $host;
+    proxy_read_timeout 86400;
+    proxy_send_timeout 86400;
+}
+```
+
+See `deploy/prod/nginx.conf` for the full reference configuration.
+
+---
+
+## Useful Commands
+
+```bash
+# Follow logs
+docker compose -f deploy/prod/docker-compose.yaml logs -f
+
+# Restart a specific service
+docker compose -f deploy/prod/docker-compose.yaml restart mosaic-be
+
+# Stop all services
+docker compose -f deploy/prod/docker-compose.yaml down
+
+# Stop and wipe the database volume
+docker compose -f deploy/prod/docker-compose.yaml down -v
+```
\ No newline at end of file
diff --git a/docs/index.md b/docs/index.md
new file mode 100644
index 0000000..f16ccc4
--- /dev/null
+++ b/docs/index.md
@@ -0,0 +1,6 @@
+---
+title: Home
+layout: home
+nav_order: 1
+permalink: /
+---
\ No newline at end of file
diff --git a/docs/installation/docker.md b/docs/installation/docker.md
new file mode 100644
index 0000000..3a89efe
--- /dev/null
+++ b/docs/installation/docker.md
@@ -0,0 +1,123 @@
+---
+title: Installation with Docker
+parent: Installation
+nav_order: 3
+---
+
+# Installation with Docker
+
+Docker is the recommended way to run mosaic-core on a robot without manually building WebRTC or installing system dependencies.
+
+---
+
+## How It Works
+
+The Dockerfile clones the mosaic-core repository, extracts the pre-built WebRTC tarball, and builds the library — all inside the container. Your application binary is then built on top of it. The final image ships everything needed to run on the robot.
+
+---
+
+## Writing a Dockerfile
+
+Below is the structure used by the TurtleBot3 example. Use it as a template for your own robot application:
+
+```dockerfile
+FROM ubuntu:24.04
+
+ENV DEBIAN_FRONTEND=noninteractive
+
+# Install build dependencies
+RUN apt-get update && apt-get install -y \
+    build-essential cmake git \
+    libboost-all-dev \
+    libjsoncpp-dev libssl-dev libopencv-dev \
+    libcpprest-dev libfmt-dev uuid-dev
+
+# Build yaml-cpp
+ARG YAML_CPP_VERSION=0.9.0
+RUN git clone --depth 1 --branch yaml-cpp-${YAML_CPP_VERSION} \
+    https://github.com/jbeder/yaml-cpp.git /tmp/yaml-cpp && \
+    cd /tmp/yaml-cpp && mkdir build && cd build && \
+    cmake -DYAML_BUILD_SHARED_LIBS=ON .. && \
+    make -j$(nproc) && make install && \
+    rm -rf /tmp/yaml-cpp
+
+# Clone and build mosaic-core
+ARG MOSAIC_CORE_VERSION=v1.1.0
+RUN git clone --depth 1 --branch ${MOSAIC_CORE_VERSION} \
+    https://github.com/ACSL-MOSAIC/mosaic-core.git /workspace/mosaic-core
+
+WORKDIR /workspace/mosaic-core/third_party
+RUN tar -xzf webrtc-tarballs/webrtc-6723-arm64.tar.gz   # or webrtc-6723-x86.tar.gz
+
+WORKDIR /workspace/mosaic-core
+RUN mkdir -p build && cd build && \
+    cmake -DBUILD_PYTHON_BINDINGS=OFF -DBUILD_TESTS=OFF \
+          -DCMAKE_BUILD_TYPE=Release .. && \
+    make install
+
+# Copy and build your application
+WORKDIR /workspace/project
+COPY CMakeLists.txt .
+COPY src ./src
+RUN mkdir -p build && cd build && cmake .. && make
+
+CMD ["build/your_robot_app"]
+```
+
+{: .note }
+> Change `webrtc-6723-arm64.tar.gz` to `webrtc-6723-x86.tar.gz` for x86_64 targets.
+
+---
+
+## Build the Image
+
+**x86_64:**
+
+```bash
+cd docker
+docker compose build
+```
+
+**arm64 (Raspberry Pi / Jetson) — cross-compilation from x86_64 host:**
+
+```bash
+cd docker
+bash build-arm64.sh
+```
+
+The arm64 script uses `docker buildx` with QEMU emulation. The resulting image can be saved and transferred to the target device:
+
+```bash
+docker save your-image:arm64 | gzip > robot-image.tar.gz
+
+# On the target device (Raspberry Pi, Jetson, etc.):
+docker load < robot-image.tar.gz
+```
+
+---
+
+## docker-compose.yml
+
+Mount your config file and expose the hardware device:
+
+```yaml
+services:
+  robot-app:
+    image: your-robot-image:latest
+    container_name: robot-controller
+    volumes:
+      - ./mosaic_config.yaml:/app/mosaic_config.yaml
+    devices:
+      - /dev/ttyACM0:/dev/ttyACM0   # adjust for your hardware
+    privileged: true
+    restart: unless-stopped
+```
+
+---
+
+## Run
+
+```bash
+cd docker
+docker compose up
+```
\ No newline at end of file
diff --git a/docs/installation/index.md b/docs/installation/index.md
new file mode 100644
index 0000000..28ad689
--- /dev/null
+++ b/docs/installation/index.md
@@ -0,0 +1,6 @@
+---
+title: Installation
+nav_order: 3
+has_children: true
+---
+# Installation
\ No newline at end of file
diff --git a/docs/installation/ros2.md b/docs/installation/ros2.md
new file mode 100644
index 0000000..77822ca
--- /dev/null
+++ b/docs/installation/ros2.md
@@ -0,0 +1,187 @@
+---
+title: Installation with ROS2
+parent: Installation
+nav_order: 2
+---
+
+# Installation with ROS2
+
+This guide covers building and installing the **mosaic-ros2** packages, which bridge ROS2 topics to MOSAIC's WebRTC data channels and media tracks.
+
+{: .note }
+> mosaic-ros2 supports **ROS2 Humble** and **ROS2 Jazzy** on Ubuntu 22.04 / 24.04.
+
+---
+
+## Prerequisites
+
+### 1. Install mosaic-core
+
+mosaic-ros2 depends on mosaic-core. Follow the [Installation on Ubuntu](ubuntu.md) guide first to install mosaic-core.
+
+### 2. Install ROS2
+
+Install ROS2 Humble or Jazzy by following the [official ROS2 installation guide](https://docs.ros.org/en/humble/Installation.html). Make sure the ROS2 environment is sourced:
+
+```bash
+source /opt/ros/humble/setup.bash   # or jazzy
+```
+
+### 3. Install Additional Dependencies
+
+```bash
+sudo apt-get install -y \
+  ros-${ROS_DISTRO}-cv-bridge \
+  ros-${ROS_DISTRO}-sensor-msgs \
+  ros-${ROS_DISTRO}-geometry-msgs \
+  libprotobuf-dev \
+  protobuf-compiler \
+  uuid-dev
+```
+
+---
+
+## Package Overview
+
+mosaic-ros2 is organized as a set of ROS2 packages. Clone the repository into your colcon workspace:
+
+```bash
+cd ~/ros2_ws/src
+git clone https://github.com/ACSL-MOSAIC/mosaic-ros2.git
+```
+
+The repository contains the following packages:
+
+| Package | Role |
+|:---|:---|
+| `mosaic-ros2-base` | Core ROS2 integration (`ROS2AutoConfigurer`, `MosaicNode`, `RosLogger`) |
+| `mosaic-ros2-geometry` | Connectors for `geometry_msgs` (Twist, TwistStamped, PoseWithCovarianceStamped) |
+| `mosaic-ros2-sensor` | Connectors for `sensor_msgs` (Image, PointCloud2, NavSatFix) |
+| `mosaic-ros2-bringup` | Main executable and launch files |
+
+---
+
+## Build
+
+Build all packages with colcon:
+
+```bash
+cd ~/ros2_ws
+colcon build --symlink-install --packages-select \
+  mosaic-ros2-base \
+  mosaic-ros2-geometry \
+  mosaic-ros2-sensor \
+  mosaic-ros2-bringup
+```
+
+Source the workspace after building:
+
+```bash
+source ~/ros2_ws/install/setup.bash
+```
+
+---
+
+## Running
+
+### 1. Prepare a Config File
+
+Create a `mosaic_config.yaml` file. See [Config on Robot](../config-on-robot.md) for the full reference.
+
+A minimal example:
+
+```yaml
+server:
+  ws_url: 'wss://your-mosaic-server.com'
+  auth:
+    type: 'simple-token'
+    robot_id: 'your-robot-id'
+    params:
+      token: 'your-token'
+  webrtc:
+    ice_servers:
+      - urls:
+          - 'turn:your-turn-server:3478'
+        username: 'username'
+        credential: 'credential'
+
+connectors:
+  - type: 'ros2-sender-sensor-Image'
+    label: 'camera'
+    params:
+      topic_name: '/camera/color/image_raw'
+
+  - type: 'ros2-receiver-geometry-Twist'
+    label: 'cmd_vel'
+    params:
+      topic_name: '/cmd_vel'
+```
+
+### 2. Launch the Node
+
+```bash
+ros2 launch mosaic-ros2-bringup mosaic_bringup_launch.py \
+  mosaic_config:=/path/to/mosaic_config.yaml \
+  mosaic_log_level:=info \
+  webrtc_log_level:=none
+```
+
+### Launch Arguments
+
+| Argument | Default | Options |
+|:---|:---|:---|
+| `mosaic_config` | `./mosaic_config.yaml` | Path to config YAML |
+| `mosaic_log_level` | `info` | `debug`, `info`, `warning`, `error` |
+| `webrtc_log_level` | `none` | `none`, `verbose`, `info`, `warning`, `error` |
+
+---
+
+## Available Connector Types
+
+### Sender (Robot → Operator)
+
+| Connector Type | ROS2 Message | Description |
+|:---|:---|:---|
+| `ros2-sender-sensor-Image` | `sensor_msgs/Image` | Camera image stream (via MediaTrack) |
+| `ros2-sender-sensor-PointCloud2` | `sensor_msgs/PointCloud2` | LiDAR point cloud (Protobuf over DataChannel) |
+| `ros2-sender-sensor-NavSatFix` | `sensor_msgs/NavSatFix` | GPS coordinates |
+| `ros2-sender-geometry-PoseWithCovarianceStamped` | `geometry_msgs/PoseWithCovarianceStamped` | Robot pose (e.g. AMCL) |
+
+### Receiver (Operator → Robot)
+
+| Connector Type | ROS2 Message | Description |
+|:---|:---|:---|
+| `ros2-receiver-geometry-Twist` | `geometry_msgs/Twist` | Velocity command |
+| `ros2-receiver-geometry-TwistStamped` | `geometry_msgs/TwistStamped` | Stamped velocity command |
+
+---
+
+## Troubleshooting
+
+**`find_package(mosaic-core REQUIRED)` fails**
+
+mosaic-core must be installed system-wide before building mosaic-ros2:
+```bash
+# In the mosaic-core build directory
+sudo make install
+```
+
+**`protoc` not found**
+
+```bash
+sudo apt-get install -y protobuf-compiler
+```
+
+**`cv_bridge` not found**
+
+```bash
+sudo apt-get install -y ros-${ROS_DISTRO}-cv-bridge
+```
+
+**`ROS_DISTRO` not set warning during build**
+
+Source your ROS2 environment before running colcon:
+```bash
+source /opt/ros/humble/setup.bash
+colcon build ...
+```
\ No newline at end of file
diff --git a/docs/installation/ubuntu.md b/docs/installation/ubuntu.md
new file mode 100644
index 0000000..9232317
--- /dev/null
+++ b/docs/installation/ubuntu.md
@@ -0,0 +1,200 @@
+---
+title: Installation on Ubuntu
+parent: Installation
+nav_order: 1
+---
+
+# Installation on Ubuntu
+
+This guide covers building and installing **mosaic-core** — the robot-side C++ library — on Ubuntu.
+
+{: .note }
+> mosaic-core has been tested on **Ubuntu 22.04 (x86_64 / arm64)**.
+
+---
+
+## Prerequisites
+
+### System Dependencies
+
+Install the required packages:
+
+```bash
+sudo apt-get update
+sudo apt-get install -y \
+  git \
+  cmake \
+  build-essential \
+  libssl-dev \
+  libopencv-dev \
+  libjsoncpp-dev \
+  libfmt-dev \
+  libyaml-cpp-dev \
+  libcpprest-dev
+```
+
+### CMake 3.14+
+
+Verify your CMake version:
+
+```bash
+cmake --version
+```
+
+If the version is below 3.14, install a newer version from [cmake.org](https://cmake.org/download/).
+
+---
+
+## 1. Clone the Repository
+
+```bash
+git clone https://github.com/ACSL-MOSAIC/mosaic-core.git
+cd mosaic-core
+```
+
+---
+
+## 2. Set Up WebRTC
+
+mosaic-core depends on Google's WebRTC native library (`libwebrtc.a`). You can either use the **pre-built tarball** (recommended) or **build from source**.
+
+### Option A: Use Pre-built Tarball (Recommended)
+
+Pre-built tarballs for WebRTC branch `6723` are included in the repository.
+
+**x86_64:**
+```bash
+cd third_party
+tar -xzf webrtc-tarballs/webrtc-6723-x86.tar.gz
+cd ..
+```
+
+**arm64:**
+```bash
+cd third_party
+tar -xzf webrtc-tarballs/webrtc-6723-arm64.tar.gz
+cd ..
+```
+
+After extraction, verify the library exists:
+
+```bash
+ls third_party/webrtc/src/out/Default/obj/libwebrtc.a
+```
+
+---
+
+### Option B: Build WebRTC from Source
+
+{: .warning }
+> Building WebRTC from source takes **1–2 hours** and requires ~20 GB of disk space.
+
+**Step 1. Fetch the WebRTC source**
+
+```bash
+cd third_party
+bash webrtc-scripts/fetch_webrtc_source.sh
+cd ..
+```
+
+**Step 2. Build WebRTC**
+
+Run the build script for your architecture:
+
+```bash
+# x86_64
+bash third_party/webrtc-scripts/build_webrtc_x86_64.sh
+
+# arm64
+bash third_party/webrtc-scripts/build_webrtc_arm64.sh
+```
+
+---
+
+## 3. Build mosaic-core
+
+```bash
+mkdir build && cd build
+cmake .. -DCMAKE_BUILD_TYPE=Release
+make -j$(nproc)
+```
+
+### CMake Options
+
+| Option | Default | Description |
+|:---|:---|:---|
+| `BUILD_PYTHON_BINDINGS` | `ON` | Build Python bindings |
+| `BUILD_TESTS` | `ON` | Build unit tests |
+| `BUILD_SHARED_LIBS` | `ON` | Build as shared library |
+
+Example — disable Python bindings and tests:
+
+```bash
+cmake .. -DCMAKE_BUILD_TYPE=Release \
+         -DBUILD_PYTHON_BINDINGS=OFF \
+         -DBUILD_TESTS=OFF
+```
+
+---
+
+## 4. Install
+
+```bash
+sudo make install
+```
+
+This installs:
+- Headers → `/usr/local/include/mosaic/`
+- Library → `/usr/local/lib/`
+- CMake config → `/usr/local/lib/cmake/mosaic-core/`
+
+You can then find the library from another CMake project with:
+
+```cmake
+find_package(mosaic-core REQUIRED)
+target_link_libraries(your_target mosaic::mosaic-core)
+```
+
+---
+
+## 5. Python Bindings (Optional)
+
+If `BUILD_PYTHON_BINDINGS=ON` (default), the Python package is built alongside the C++ library.
+
+Install it in editable mode from the build output:
+
+```bash
+pip install -e build/python
+```
+
+Verify the installation:
+
+```python
+import mosaic_core
+print(mosaic_core.__version__)
+```
+
+---
+
+## Troubleshooting
+
+**`libwebrtc.a` not found**
+
+Make sure the WebRTC tarball was extracted correctly:
+```bash
+ls third_party/webrtc/src/out/Default/obj/libwebrtc.a
+```
+
+**`find_package` fails for a dependency**
+
+Install the missing package via `apt-get`. For example, if `cpprestsdk` is not found:
+```bash
+sudo apt-get install -y libcpprest-dev
+```
+
+**Linker errors with `dl` or `pthread`**
+
+These are system libraries and should always be available on Ubuntu. If missing:
+```bash
+sudo apt-get install -y libc6-dev
+```
\ No newline at end of file
diff --git a/docs/key-concept.md b/docs/key-concept.md
new file mode 100644
index 0000000..ceb4f74
--- /dev/null
+++ b/docs/key-concept.md
@@ -0,0 +1,221 @@
+---
+title: Key Concept of MOSAIC
+nav_order: 4
+---
+
+# Key Concept of MOSAIC
+
+This page explains how the robot side and the dashboard side are connected, and how data moves from a robot connector all the way to a dashboard widget.
+
+---
+
+## The Big Picture
+
+```
+        ROBOT                                  DASHBOARD (Browser)
+┌─────────────────────┐                 ┌──────────────────────────────┐
+│                     │                 │                              │
+│  mosaic-core        │                 │  MosaicProvider              │
+│  ┌───────────────┐  │   WebRTC P2P    │  ┌────────────────────────┐ │
+│  │  Connector    │◄─┼─────────────────┼─►│  Store                 │ │
+│  │  (Handler)    │  │  DataChannel /  │  │  (ReceivableStore /    │ │
+│  └───────────────┘  │  MediaTrack     │  │   SendableStore / ...)  │ │
+│                     │                 │  └────────────┬───────────┘ │
+│  AutoConfigurer     │                 │               │ subscribe() │
+│  ConnectorResolver  │                 │  ┌────────────▼───────────┐ │
+│                     │                 │  │  Widget                │ │
+│                     │                 │  │  (React Component)     │ │
+└─────────────────────┘                 │  └────────────────────────┘ │
+                                        └──────────────────────────────┘
+        │                                              │
+        └──────────────────────────────────────────────┘
+                  Signaling via MOSAIC-Server
+                  (/ws/robot  ←→  /ws/user)
+```
+
+A robot and an operator browser establish a **direct WebRTC peer-to-peer connection**. MOSAIC-Server acts only as the signaling intermediary during connection setup; actual data never passes through the server.
+
+---
+
+## Robot Side: Connectors
+
+On the robot, a **Connector** is a C++ object that either sends data to the dashboard, receives commands from it, or streams video.
+
+| Connector type | Base class | Direction |
+|:---|:---|:---|
+| Data Channel Sender | `DataChannelSendable` | Robot → Dashboard |
+| Data Channel Receiver | `DataChannelReceivable<T>` | Dashboard → Robot |
+| Media Streamer | `AMediaTrackHandler` | Robot → Dashboard (video) |
+
+Each connector is identified by a **label** (e.g. `"sensor_data"`, `"cmd_vel"`, `"camera"`). This label becomes the WebRTC DataChannel name or MediaTrack name, and it must match the `connectorId` configured on the dashboard side.
+
+### How Connectors Are Set Up
+
+The `AutoConfigurer` reads `mosaic_config.yaml` and uses the `ConnectorResolver` to map each `type` field to a registered configurer class. The configurer's `Configure()` method creates the actual handler and sets `handler_`. See the [Custom Connector Introduction](./custom-connector/introduction) page for a full walkthrough.
+
+---
+
+## Dashboard Side: Connector → Store → Widget
+
+### RobotConnector
+
+On the dashboard, a **RobotConnector** object describes one end of a WebRTC channel from the browser's perspective:
+
+```typescript
+class RobotConnector {
+  robotId: string      // which robot
+  connectorId: string  // must match the robot connector's label
+  dataType: MosaicDataType
+}
+```
+
+`MosaicDataType` encodes both the **data format** and the **direction**:
+
+| dataType | Format | Direction |
+|:---|:---|:---|
+| `"json-r2u"` | JSON | Robot → Dashboard |
+| `"json-u2r"` | JSON | Dashboard → Robot |
+| `"json-bi"` | JSON | Bidirectional |
+| `"string-r2u"` | UTF-8 string | Robot → Dashboard |
+| `"string-u2r"` | UTF-8 string | Dashboard → Robot |
+| `"byte-r2u"` | Binary | Robot → Dashboard |
+| `"byte-u2r"` | Binary | Dashboard → Robot |
+| `"media"` | Video/audio | Robot → Dashboard |
+
+The `connectorId` of a `RobotConnector` must exactly match the `label` of the robot-side connector.
+
+### Store
+
+A **Store** is the state container that sits between the WebRTC layer and React components. When a DataChannel receives bytes, the WebRTC connection layer calls `store.notifySubscribers(arrayBuffer)`, delivering the data to every component that has subscribed.
+
+There are four store base classes:
+
+| Store type | Used when | Key API |
+|:---|:---|:---|
+| `ReceivableStore` | Robot → Dashboard (`*-r2u`) | `subscribe(callback)` |
+| `SendableStore` | Dashboard → Robot (`*-u2r`) | `sendData(payload)` |
+| `BidirectionalStore` | Both directions (`*-bi`) | `subscribe()` + `sendData()` |
+| `MediaStreamStore` | Video track (`media`) | Provides `MediaStream` |
+
+Stores are managed by `StoreManager`, which creates them on demand and tracks how many widgets are using each one (reference counting). When all widgets unmount, the store is released.
+
+### Widget
+
+A **Widget** is a React component that calls `useMosaicStore()` to obtain a store, then subscribes to it for live data:
+
+```typescript
+function MySensorWidget({ robotConnector }: Props) {
+  const { getOrCreateStore, releaseStore } = useMosaicStore()
+  const [value, setValue] = useState<number | null>(null)
+
+  useEffect(() => {
+    const store = getOrCreateStore(robotConnector) as ReceivableStore
+
+    const unsubscribe = store.subscribe(async (arrayBuffer) => {
+      const json = JSON.parse(new TextDecoder().decode(arrayBuffer))
+      setValue(json.value)
+    })
+
+    return () => {
+      unsubscribe()
+      releaseStore(robotConnector)
+    }
+  }, [robotConnector])
+
+  return <div>Sensor: {value}</div>
+}
+```
+
+Multiple widgets can subscribe to the same store simultaneously. Each widget gets its own callback and they all receive the same data.
+
+---
+
+## End-to-End Data Flow
+
+### Robot → Dashboard (receiving sensor data)
+
+```
+1. Robot connector calls SendJson(payload)
+        │
+        ▼
+2. WebRTC DataChannel delivers bytes to the browser
+        │
+        ▼
+3. WebRTCConnection.onmessage → store.notifySubscribers(arrayBuffer)
+        │
+        ▼
+4. Every subscribed widget callback fires with the ArrayBuffer
+        │
+        ▼
+5. Widget decodes bytes, updates React state, re-renders
+```
+
+### Dashboard → Robot (sending commands)
+
+```
+1. Widget calls store.sendData(payload)
+        │
+        ▼
+2. SendableStore writes to RTCDataChannel.send()
+        │
+        ▼
+3. WebRTC DataChannel delivers bytes to the robot
+        │
+        ▼
+4. Robot connector's HandleData() is called with the deserialized value
+        │
+        ▼
+5. Robot executes the command
+```
+
+### Video Stream
+
+```
+1. Robot's AMediaTrackHandler calls SendFrame(cv::Mat, start_time)
+        │
+        ▼
+2. WebRTC encodes frame and delivers it as a MediaTrack
+        │
+        ▼
+3. MediaStreamStore provides a MediaStream object
+        │
+        ▼
+4. Widget attaches the MediaStream to an <video> element
+```
+
+---
+
+## Label ↔ connectorId Matching
+
+The most common integration mistake is a mismatch between the robot-side `label` and the dashboard-side `connectorId`. They must be identical:
+
+```yaml
+# mosaic_config.yaml (robot side)
+connectors:
+  - type: 'my-sensor-sender'
+    label: 'sensor_data'      # ← this value
+```
+
+```typescript
+// Dashboard widget (browser side)
+const robotConnector: RobotConnector = {
+  robotId: 'my-robot',
+  connectorId: 'sensor_data',  // ← must match exactly
+  dataType: 'json-r2u',
+}
+```
+
+---
+
+## Connection Lifecycle
+
+Stores expose lifecycle hooks so widgets and stores can react to connection events:
+
+| Event | When it fires |
+|:---|:---|
+| `onBeforeConnected` | Before the WebRTC handshake begins |
+| `onAfterConnected` | DataChannel is open and ready |
+| `onAfterDisconnected` | Peer disconnected |
+| `onAfterConnectionFailed` | Handshake failed |
+
+The `afterConnected()` method on a store is called automatically once the DataChannel is open. This is the right place to start sending periodic data or subscribe to self-generated events (like the built-in `ConnectionCheckingStore` does for its ping/pong heartbeat).
\ No newline at end of file
diff --git a/docs/what-is-mosaic.md b/docs/what-is-mosaic.md
new file mode 100644
index 0000000..30e3463
--- /dev/null
+++ b/docs/what-is-mosaic.md
@@ -0,0 +1,94 @@
+---
+title: What is MOSAIC?
+nav_order: 2
+---
+
+# What is MOSAIC?
+
+MOSAIC is a **WebRTC-based real-time robot control and monitoring system** designed for low-latency, bidirectional communication between robots and operators.
+
+It provides a complete infrastructure — from the robot-side C++ library to the web-based operator dashboard — so you can focus on your robot's application logic rather than building communication pipelines from scratch.
+
+---
+
+## Why WebRTC?
+
+Traditional robot communication stacks (ROS topics over LAN, custom TCP/UDP sockets, etc.) struggle when robots operate over the public internet. Firewalls, NATs, and network instability make reliable low-latency communication difficult.
+
+WebRTC was originally designed for real-time browser video calls. MOSAIC repurposes it for robotics:
+
+- **Peer-to-peer connections** bypass servers after initial handshake, minimizing latency
+- **NAT/firewall traversal** via ICE/STUN/TURN works across the public internet
+- **DataChannels** carry arbitrary binary or text data (sensor readings, commands, etc.)
+- **MediaStreams** carry live video with hardware-accelerated encoding/decoding
+
+---
+
+## System Overview
+
+```
+┌──────────────────────────────────────────────────────┐
+│                  Operator Browser                    │
+│         (MOSAIC-Server Dashboard / React)            │
+└──────┬──────────────────────────────┬────────────────┘
+       │  P2P (WebRTC)                │  P2P (WebRTC)
+       │                              │
+┌──────▼──────┐                ┌──────▼──────┐
+│   Robot A   │                │   Robot B   │
+│ mosaic-core │                │ mosaic-core │
+└──────┬──────┘                └──────┬──────┘
+       │  WebSocket (signaling)       │  WebSocket (signaling)
+       └──────────────┬───────────────┘
+┌─────────────────────▼────────────────────────────────┐
+│                  MOSAIC-Server                       │
+│         (Spring WebFlux + PostgreSQL)                │
+└──────────────────────────────────────────────────────┘
+```
+
+The signaling server (MOSAIC-Server) only brokers the initial WebRTC handshake. Once connected, video and data flow **directly** between each robot and the operator over individual P2P connections.
+
+---
+
+## Components
+
+| Component | Language | Role |
+|:---|:---|:---|
+| **mosaic-core** | C++ / Python | WebRTC client library for robots |
+| **MOSAIC-Server** | Spring WebFlux + React | Signaling server + operator dashboard |
+| **mosaic-ros2** | C++ | ROS2 topic ↔ MOSAIC connector packages |
+| **mosaic-isaac-sim-example** | Python | Isaac Lab simulation example |
+| **mosaic-turtlebot3-wo-ros-example** | C++ | TurtleBot3 example without ROS |
+
+---
+
+## Key Features
+
+**Real-time Communication**
+- Peer-to-peer WebRTC connections with sub-100ms latency
+- Automatic reconnection and connection state management
+
+**Multi-Robot Support**
+- Control and monitor multiple heterogeneous robots simultaneously from a single dashboard
+
+**Live Video Streaming**
+- Camera feeds via WebRTC MediaStream with adaptive quality
+- Multiple streams per robot
+
+**Sensor Data & Commands**
+- Bidirectional data via WebRTC DataChannels
+- Send velocity commands, receive LiDAR scans, GPS, IMU, and more
+
+**Flexible Integration**
+- Works with ROS2, Isaac Lab, or bare-metal C++/Python
+- YAML-based configuration — no code changes needed to add new data streams
+
+---
+
+## Who Is It For?
+
+MOSAIC is aimed at robotics researchers and engineers who want to:
+
+- Monitor and control robots operating **outside the lab** over the public internet
+- Stream **live video** from robots without a dedicated streaming server
+- Build a **custom operator dashboard** without implementing WebRTC from scratch
+- Integrate with **existing ROS2** systems with minimal boilerplate
\ No newline at end of file
diff --git a/index.md b/index.md
deleted file mode 100644
index ca0c545..0000000
--- a/index.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
-title: Home
-layout: home
----
-
-This is a *bare-minimum* template to create a Jekyll site that uses the [Just the Docs] theme. You can easily set the created site to be published on [GitHub Pages] – the [README] file explains how to do that, along with other details.
-
-If [Jekyll] is installed on your computer, you can also build and preview the created site *locally*. This lets you test changes before committing them, and avoids waiting for GitHub Pages.[^1] And you will be able to deploy your local build to a different platform than GitHub Pages.
-
-More specifically, the created site:
-
-- uses a gem-based approach, i.e. uses a `Gemfile` and loads the `just-the-docs` gem
-- uses the [GitHub Pages / Actions workflow] to build and publish the site on GitHub Pages
-
-Other than that, you're free to customize sites that you create with this template, however you like. You can easily change the versions of `just-the-docs` and Jekyll it uses, as well as adding further plugins.
-
-[Browse our documentation][Just the Docs] to learn more about how to use this theme.
-
-To get started with creating a site, simply:
-
-1. click "[use this template]" to create a GitHub repository
-2. go to Settings > Pages > Build and deployment > Source, and select GitHub Actions
-
-If you want to maintain your docs in the `docs` directory of an existing project repo, see [Hosting your docs from an existing project repo](https://github.com/just-the-docs/just-the-docs-template/blob/main/README.md#hosting-your-docs-from-an-existing-project-repo) in the template README.
-
-----
-
-[^1]: [It can take up to 10 minutes for changes to your site to publish after you push the changes to GitHub](https://docs.github.com/en/pages/setting-up-a-github-pages-site-with-jekyll/creating-a-github-pages-site-with-jekyll#creating-your-site).
-
-[Just the Docs]: https://just-the-docs.github.io/just-the-docs/
-[GitHub Pages]: https://docs.github.com/en/pages
-[README]: https://github.com/just-the-docs/just-the-docs-template/blob/main/README.md
-[Jekyll]: https://jekyllrb.com
-[GitHub Pages / Actions workflow]: https://github.blog/changelog/2022-07-27-github-pages-custom-github-actions-workflows-beta/
-[use this template]: https://github.com/just-the-docs/just-the-docs-template/generate