diff --git a/apps/docs/content/docs/core/guides/cloudflare-mesh.mdx b/apps/docs/content/docs/core/guides/cloudflare-mesh.mdx
new file mode 100644
index 0000000..d0eb1c7
--- /dev/null
+++ b/apps/docs/content/docs/core/guides/cloudflare-mesh.mdx
@@ -0,0 +1,134 @@
+---
+title: Cloudflare Mesh
+description: Learn how to use Cloudflare Mesh for private Dokploy remote-server SSH and IP routing.
+---
+
+import { Callout } from 'fumadocs-ui/components/callout';
+
+Cloudflare Mesh creates a private network between servers that run Cloudflare One Client/WARP. This is useful for Dokploy remote servers because Dokploy expects a normal SSH endpoint: an IP address and port `22`.
+
+Use Cloudflare Tunnel and Access for public or human-facing entrypoints, such as the Dokploy dashboard, browser-protected tools, human SSH through Access, and public websites. Use Cloudflare Mesh for private server-to-server paths, such as the Dokploy admin server connecting to remote Dokploy nodes over SSH.
+
+## What is Cloudflare Mesh?
+
+Cloudflare Mesh connects enrolled devices through Cloudflare Zero Trust and gives each device a private Mesh IP address, often in the `100.96.0.0/12` range. After the Dokploy admin server and remote servers are enrolled, Dokploy can use a remote server's Mesh IP as its SSH host.
+
+### Benefits
+
+- **Private Remote SSH**: Connect Dokploy to remote servers without relying on public IPs
+- **Normal IP Endpoint**: Use a private Mesh IP and port `22`, which matches how Dokploy remote servers connect
+- **Reduced Exposure**: Close public SSH after the Mesh path is verified
+- **Server-to-Server Routing**: Support private calls between Dokploy-managed machines
+- **Cloudflare Zero Trust**: Manage Mesh enrollment and device policy from Cloudflare
+
+<Callout type="info">
+  Mesh is not a replacement for [Cloudflare Tunnel routes](/docs/core/guides/cloudflare-tunnels). Public websites and admin panels should continue to use Tunnel and Access so Cloudflare can terminate HTTP(S), apply Access and WAF controls, and keep origin ports closed.
+</Callout>
+
+## Prerequisites
+
+Before setting up Cloudflare Mesh with Dokploy, ensure you have:
+
+- Cloudflare Zero Trust access with Mesh available
+- Dokploy installed and running
+- At least one remote server managed by Dokploy over SSH
+- SSH or console access to the Dokploy admin server and each remote server
+- Cloudflare One Client/WARP installed on every server that should join Mesh
+
+<Callout type="warn">
+  Verify your WARP device profile and split tunnel settings before running `warp-cli connect`. Broad WARP routing can interrupt server connectivity. Keep public SSH or another recovery path available until Mesh SSH and Dokploy remote connectivity are verified.
+</Callout>
+
+## Cloudflare Mesh Setup
+
+This guide walks through the high-level Mesh setup for Dokploy remote servers. Repeat the server-side steps for the Dokploy admin server and each remote server that Dokploy needs to manage.
+
+### Step 1: Enable Mesh in Cloudflare Zero Trust
+
+1. Log in to your [Cloudflare Dashboard](https://dash.cloudflare.com/)
+2. Open **Zero Trust**
+3. Go to **Networks** → **Mesh**
+4. Enable Mesh connections
+5. Enable unique IP addresses for devices
+
+### Step 2: Create a Mesh node token
+
+In the Mesh settings, create a node token for enrolling servers.
+
+<Callout type="info">
+  Keep the Mesh node token secure. It enrolls devices into your private Mesh network and should not be committed to your repository or shared in logs.
+</Callout>
+
+### Step 3: Install Cloudflare One Client/WARP on each server
+
+Install Cloudflare One Client/WARP on:
+
+- The Dokploy admin server
+- Each remote server that Dokploy manages over SSH
+
+Use Cloudflare's [headless Linux Cloudflare One Client tutorial](https://developers.cloudflare.com/cloudflare-one/tutorials/deploy-client-headless-linux/) or the current installation instructions for your server operating system, then confirm `warp-cli` is available.
+
+### Step 4: Configure and verify the WARP device profile
+
+Before connecting WARP on a server, create or verify a dedicated Mesh-node device profile in Cloudflare Zero Trust:
+
+- Use **Traffic and DNS** mode
+- Use [Split Tunnels](https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/configure/route-traffic/split-tunnels/) **Include** mode
+- Include `100.96.0.0/12` for Cloudflare Mesh device IPs
+
+On each server, check the applied WARP settings before connecting:
+
+```bash
+warp-cli --accept-tos settings
+```
+
+Do not run `warp-cli connect` if the expected Mesh profile, Include mode, and `100.96.0.0/12` route are not shown, or if the profile would broadly reroute server traffic.
+
+### Step 5: Enroll and connect each server
+
+On each server, enroll the device with your Mesh node token:
+
+```bash
+sudo warp-cli --accept-tos connector new <MESH_NODE_TOKEN>
+```
+
+Then connect WARP:
+
+```bash
+sudo warp-cli --accept-tos connect
+```
+
+After connecting, confirm the device appears in Cloudflare Zero Trust and has a Mesh IP address.
+
+### Step 6: Verify Mesh connectivity
+
+From the Dokploy admin server, test SSH to the remote server's Mesh IP:
+
+```bash
+ssh root@<REMOTE_SERVER_MESH_IP> hostname
+```
+
+If this fails, keep public SSH or console access available while you check WARP status, Mesh enrollment, device policy, and host firewall rules.
+
+## Update Dokploy Remote Servers
+
+After Mesh SSH works, update the remote server in Dokploy to use the remote server's Mesh IP:
+
+```txt
+Host: <REMOTE_SERVER_MESH_IP>
+Port: 22
+```
+
+Then validate the remote server connection from the Dokploy UI. Dokploy should be able to reach the remote server on the Mesh IP at port `22`.
+
+<Callout type="info">
+  Mesh gives Dokploy a normal private IP endpoint, which is cleaner for Dokploy remote servers than Access SSH patterns that require a client-side `cloudflared access ssh` ProxyCommand.
+</Callout>
+
+## Securing Your Server
+
+Once Mesh SSH and Dokploy remote-server connectivity both work, you can close public SSH in your host or cloud firewall. Keep `sshd` running so the server remains reachable through the Mesh IP.
+
+<Callout type="warn">
+  Do not close public SSH until you have verified both direct Mesh SSH from the Dokploy admin server and Dokploy's remote-server connection. Keep a console or other recovery path available for future network changes.
+</Callout>
diff --git a/apps/docs/content/docs/core/guides/cloudflare-tunnels.mdx b/apps/docs/content/docs/core/guides/cloudflare-tunnels.mdx
index 3e73a13..4f26d7c 100644
--- a/apps/docs/content/docs/core/guides/cloudflare-tunnels.mdx
+++ b/apps/docs/content/docs/core/guides/cloudflare-tunnels.mdx
@@ -216,4 +216,4 @@ This ensures Dokploy includes your domain as a trusted origin automatically.
 
 <Callout type="warn">
   If you access Dokploy through multiple origins (public domain, internal IP, Tailscale), make sure all of them are listed in `BETTER_AUTH_TRUSTED_ORIGINS`.
-</Callout>
\ No newline at end of file
+</Callout>
diff --git a/apps/docs/content/docs/core/meta.json b/apps/docs/content/docs/core/meta.json
index 42f17af..ddc4b6c 100644
--- a/apps/docs/content/docs/core/meta.json
+++ b/apps/docs/content/docs/core/meta.json
@@ -62,6 +62,7 @@
 		"enterprise/audit-logs",
 		"---Guides---",
 		"guides/cloudflare-tunnels",
+		"guides/cloudflare-mesh",
 		"guides/tailscale",
 		"guides/ec2-instructions"
 	]