From b83181989e4e67ebb8915b6121afc551ef9f3e4e Mon Sep 17 00:00:00 2001 From: Kenny Date: Tue, 12 May 2026 18:35:10 -0400 Subject: [PATCH 1/4] docs: add cloudflare mesh guidance --- .../docs/core/guides/cloudflare-tunnels.mdx | 62 ++++++++++++++++++- 1 file changed, 61 insertions(+), 1 deletion(-) diff --git a/apps/docs/content/docs/core/guides/cloudflare-tunnels.mdx b/apps/docs/content/docs/core/guides/cloudflare-tunnels.mdx index 3e73a13..f9e3310 100644 --- a/apps/docs/content/docs/core/guides/cloudflare-tunnels.mdx +++ b/apps/docs/content/docs/core/guides/cloudflare-tunnels.mdx @@ -216,4 +216,64 @@ This ensures Dokploy includes your domain as a trusted origin automatically. If you access Dokploy through multiple origins (public domain, internal IP, Tailscale), make sure all of them are listed in `BETTER_AUTH_TRUSTED_ORIGINS`. - \ No newline at end of file + + +## Cloudflare Mesh + +Cloudflare Mesh is useful when Dokploy needs private server-to-server connectivity. Keep 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 Mesh for private paths where Dokploy expects a normal IP address and port, such as connecting the Dokploy admin server to remote Dokploy nodes over SSH. + +Do not use Mesh as the public website publishing layer. Public websites and admin panels should continue to use Tunnel routes so Cloudflare can terminate HTTP(S), apply Access and WAF controls, and keep origin ports closed. + +### When to use Mesh + +- Dokploy admin server to remote Dokploy nodes +- Deployments that need SSH access to worker or application servers +- Private service calls between Dokploy-managed machines +- Closing public SSH while preserving Dokploy remote-server management + +### Prerequisites + +Before using Cloudflare Mesh with Dokploy, ensure you have: + +- Cloudflare Zero Trust with Mesh enabled +- Cloudflare One Client/WARP installed on the Dokploy admin server and each remote server +- A Mesh node token created in **Zero Trust** → **Networks** → **Mesh** +- SSH access or console access kept available while testing + + + Verify your 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 open until Mesh and Dokploy remote connectivity are verified. + + +### Setup overview + +1. In Cloudflare Zero Trust, go to **Networks** → **Mesh**. +2. Enable Mesh connections and unique IP addresses for devices. +3. Create a node token. Store it securely and do not commit it to your repository. +4. Install Cloudflare One Client/WARP on the Dokploy admin server and each remote server. +5. Enroll each server with the node token, then connect WARP. +6. Confirm each server receives a Mesh IP, often in the `100.96.0.0/12` range. + +### Update Dokploy remote servers + +After Mesh is connected, update each Dokploy remote server to use the remote server's Mesh IP: + +```txt +Host: +Port: 22 +``` + +From the Dokploy admin server, verify SSH over Mesh before changing firewall rules: + +```bash +ssh root@ hostname +``` + +Then verify in Dokploy that the remote server connects successfully on port `22`. + + + 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. + + + + Only close public SSH in your host or cloud firewall after Mesh SSH and Dokploy remote-server connectivity both work. Keep `sshd` running so the server remains reachable over the Mesh path. + From 3d7d970378f977e7c68acc20e73e8c2db93302ac Mon Sep 17 00:00:00 2001 From: Kenny Date: Tue, 12 May 2026 18:45:36 -0400 Subject: [PATCH 2/4] docs: split cloudflare mesh into guide --- .../docs/core/guides/cloudflare-mesh.mdx | 72 +++++++++++++++++++ .../docs/core/guides/cloudflare-tunnels.mdx | 58 +-------------- apps/docs/content/docs/core/meta.json | 1 + 3 files changed, 75 insertions(+), 56 deletions(-) create mode 100644 apps/docs/content/docs/core/guides/cloudflare-mesh.mdx 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..7698b2b --- /dev/null +++ b/apps/docs/content/docs/core/guides/cloudflare-mesh.mdx @@ -0,0 +1,72 @@ +--- +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. For Dokploy, it is most useful when the Dokploy admin server needs a normal private IP path to remote servers over SSH. + +Keep 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 Mesh for private server-to-server paths where Dokploy expects a regular IP address and port. + +## What is Cloudflare Mesh? + +Cloudflare Mesh connects enrolled devices through Cloudflare Zero Trust and assigns each device a private Mesh IP address, often in the `100.96.0.0/12` range. Dokploy can use that private IP as the host for a remote server while keeping public SSH closed after verification. + +Do not use Mesh as the public website publishing layer. Public websites and admin panels should continue to use Cloudflare Tunnel routes so Cloudflare can terminate HTTP(S), apply Access and WAF controls, and keep origin ports closed. + +## When to use Cloudflare Mesh + +- Dokploy admin server to remote Dokploy nodes +- Deployments that need SSH access to worker or application servers +- Private service calls between Dokploy-managed machines +- Closing public SSH while preserving Dokploy remote-server management + +## Prerequisites + +Before using Cloudflare Mesh with Dokploy, ensure you have: + +- Cloudflare Zero Trust with Mesh enabled +- Cloudflare One Client/WARP installed on the Dokploy admin server and each remote server +- A Mesh node token created in **Zero Trust** → **Networks** → **Mesh** +- SSH access or console access kept available while testing + + + 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 and Dokploy remote connectivity are verified. + + +## Cloudflare Mesh Setup + +This guide assumes you already have Dokploy installed and at least one remote server that Dokploy manages over SSH. + +1. In Cloudflare Zero Trust, go to **Networks** → **Mesh**. +2. Enable Mesh connections and unique IP addresses for devices. +3. Create a node token. Store it securely and do not commit it to your repository. +4. Install Cloudflare One Client/WARP on the Dokploy admin server and each remote server. +5. Enroll each server with the node token, then connect WARP. +6. Confirm that each server receives a private Mesh IP. + +## Update Dokploy remote servers + +After Mesh is connected, update each Dokploy remote server to use the remote server's Mesh IP: + +```txt +Host: +Port: 22 +``` + +From the Dokploy admin server, verify SSH over Mesh before changing firewall rules: + +```bash +ssh root@ hostname +``` + +Then verify in Dokploy that the remote server connects successfully on port `22`. + + + 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. + + + + Only close public SSH in your host or cloud firewall after Mesh SSH and Dokploy remote-server connectivity both work. Keep `sshd` running so the server remains reachable over the Mesh path. + diff --git a/apps/docs/content/docs/core/guides/cloudflare-tunnels.mdx b/apps/docs/content/docs/core/guides/cloudflare-tunnels.mdx index f9e3310..5b7ffc9 100644 --- a/apps/docs/content/docs/core/guides/cloudflare-tunnels.mdx +++ b/apps/docs/content/docs/core/guides/cloudflare-tunnels.mdx @@ -220,60 +220,6 @@ This ensures Dokploy includes your domain as a trusted origin automatically. ## Cloudflare Mesh -Cloudflare Mesh is useful when Dokploy needs private server-to-server connectivity. Keep 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 Mesh for private paths where Dokploy expects a normal IP address and port, such as connecting the Dokploy admin server to remote Dokploy nodes over SSH. +Cloudflare Tunnel and Access are best for public or human-facing entrypoints, such as the Dokploy dashboard, browser-protected tools, human SSH through Access, and public websites. -Do not use Mesh as the public website publishing layer. Public websites and admin panels should continue to use Tunnel routes so Cloudflare can terminate HTTP(S), apply Access and WAF controls, and keep origin ports closed. - -### When to use Mesh - -- Dokploy admin server to remote Dokploy nodes -- Deployments that need SSH access to worker or application servers -- Private service calls between Dokploy-managed machines -- Closing public SSH while preserving Dokploy remote-server management - -### Prerequisites - -Before using Cloudflare Mesh with Dokploy, ensure you have: - -- Cloudflare Zero Trust with Mesh enabled -- Cloudflare One Client/WARP installed on the Dokploy admin server and each remote server -- A Mesh node token created in **Zero Trust** → **Networks** → **Mesh** -- SSH access or console access kept available while testing - - - Verify your 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 open until Mesh and Dokploy remote connectivity are verified. - - -### Setup overview - -1. In Cloudflare Zero Trust, go to **Networks** → **Mesh**. -2. Enable Mesh connections and unique IP addresses for devices. -3. Create a node token. Store it securely and do not commit it to your repository. -4. Install Cloudflare One Client/WARP on the Dokploy admin server and each remote server. -5. Enroll each server with the node token, then connect WARP. -6. Confirm each server receives a Mesh IP, often in the `100.96.0.0/12` range. - -### Update Dokploy remote servers - -After Mesh is connected, update each Dokploy remote server to use the remote server's Mesh IP: - -```txt -Host: -Port: 22 -``` - -From the Dokploy admin server, verify SSH over Mesh before changing firewall rules: - -```bash -ssh root@ hostname -``` - -Then verify in Dokploy that the remote server connects successfully on port `22`. - - - 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. - - - - Only close public SSH in your host or cloud firewall after Mesh SSH and Dokploy remote-server connectivity both work. Keep `sshd` running so the server remains reachable over the Mesh path. - +For private Dokploy server-to-server connectivity, such as remote-server SSH over a private IP, see the [Cloudflare Mesh guide](/docs/core/guides/cloudflare-mesh). 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" ] From 5bfa6d741205afeb8987ce0c91ec5b354b434242 Mon Sep 17 00:00:00 2001 From: Kenny Date: Tue, 12 May 2026 18:55:24 -0400 Subject: [PATCH 3/4] docs: improve cloudflare mesh guide --- .../docs/core/guides/cloudflare-mesh.mdx | 106 +++++++++++++----- 1 file changed, 76 insertions(+), 30 deletions(-) diff --git a/apps/docs/content/docs/core/guides/cloudflare-mesh.mdx b/apps/docs/content/docs/core/guides/cloudflare-mesh.mdx index 7698b2b..4739900 100644 --- a/apps/docs/content/docs/core/guides/cloudflare-mesh.mdx +++ b/apps/docs/content/docs/core/guides/cloudflare-mesh.mdx @@ -5,68 +5,114 @@ description: Learn how to use Cloudflare Mesh for private Dokploy remote-server import { Callout } from 'fumadocs-ui/components/callout'; -Cloudflare Mesh creates a private network between servers that run Cloudflare One Client/WARP. For Dokploy, it is most useful when the Dokploy admin server needs a normal private IP path to remote servers over SSH. +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`. -Keep 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 Mesh for private server-to-server paths where Dokploy expects a regular IP address and port. +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 assigns each device a private Mesh IP address, often in the `100.96.0.0/12` range. Dokploy can use that private IP as the host for a remote server while keeping public SSH closed after verification. +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. -Do not use Mesh as the public website publishing layer. Public websites and admin panels should continue to use Cloudflare Tunnel routes so Cloudflare can terminate HTTP(S), apply Access and WAF controls, and keep origin ports closed. +### Benefits -## When to use Cloudflare Mesh +- **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 -- Dokploy admin server to remote Dokploy nodes -- Deployments that need SSH access to worker or application servers -- Private service calls between Dokploy-managed machines -- Closing public SSH while preserving Dokploy remote-server management + + Mesh is not a replacement for Cloudflare Tunnel routes. 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. + ## Prerequisites -Before using Cloudflare Mesh with Dokploy, ensure you have: +Before setting up Cloudflare Mesh with Dokploy, ensure you have: -- Cloudflare Zero Trust with Mesh enabled -- Cloudflare One Client/WARP installed on the Dokploy admin server and each remote server -- A Mesh node token created in **Zero Trust** → **Networks** → **Mesh** -- SSH access or console access kept available while testing +- 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 - 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 and Dokploy remote connectivity are verified. + 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. ## Cloudflare Mesh Setup -This guide assumes you already have Dokploy installed and at least one remote server that Dokploy manages over SSH. +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. -1. In Cloudflare Zero Trust, go to **Networks** → **Mesh**. -2. Enable Mesh connections and unique IP addresses for devices. -3. Create a node token. Store it securely and do not commit it to your repository. -4. Install Cloudflare One Client/WARP on the Dokploy admin server and each remote server. -5. Enroll each server with the node token, then connect WARP. -6. Confirm that each server receives a private Mesh IP. +### Step 1: Enable Mesh in Cloudflare Zero Trust -## Update Dokploy remote servers +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 -After Mesh is connected, update each Dokploy remote server to use the remote server's Mesh IP: +### Step 2: Create a Mesh node token -```txt -Host: -Port: 22 +In the Mesh settings, create a node token for enrolling servers. + + + 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. + + +### 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 current installation instructions for your server operating system, then confirm `warp-cli` is available. + +### Step 4: Enroll and connect each server + +On each server, enroll the device with your Mesh node token: + +```bash +sudo warp-cli --accept-tos connector new ``` -From the Dokploy admin server, verify SSH over Mesh before changing firewall rules: +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 5: Verify Mesh connectivity + +From the Dokploy admin server, test SSH to the remote server's Mesh IP: ```bash ssh root@ hostname ``` -Then verify in Dokploy that the remote server connects successfully on port `22`. +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: +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`. 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. +## 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. + - Only close public SSH in your host or cloud firewall after Mesh SSH and Dokploy remote-server connectivity both work. Keep `sshd` running so the server remains reachable over the Mesh path. + 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. From 480f9bc726d652dd8679f48c1eff6f39d7556b04 Mon Sep 17 00:00:00 2001 From: Kenny Date: Tue, 12 May 2026 19:25:06 -0400 Subject: [PATCH 4/4] docs: add cloudflare mesh profile guidance --- .../docs/core/guides/cloudflare-mesh.mdx | 24 +++++++++++++++---- .../docs/core/guides/cloudflare-tunnels.mdx | 6 ----- 2 files changed, 20 insertions(+), 10 deletions(-) diff --git a/apps/docs/content/docs/core/guides/cloudflare-mesh.mdx b/apps/docs/content/docs/core/guides/cloudflare-mesh.mdx index 4739900..d0eb1c7 100644 --- a/apps/docs/content/docs/core/guides/cloudflare-mesh.mdx +++ b/apps/docs/content/docs/core/guides/cloudflare-mesh.mdx @@ -22,7 +22,7 @@ Cloudflare Mesh connects enrolled devices through Cloudflare Zero Trust and give - **Cloudflare Zero Trust**: Manage Mesh enrollment and device policy from Cloudflare - Mesh is not a replacement for Cloudflare Tunnel routes. 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. + 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. ## Prerequisites @@ -66,9 +66,25 @@ Install Cloudflare One Client/WARP on: - The Dokploy admin server - Each remote server that Dokploy manages over SSH -Use Cloudflare's current installation instructions for your server operating system, then confirm `warp-cli` is available. +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: Enroll and connect each server +### 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: @@ -84,7 +100,7 @@ sudo warp-cli --accept-tos connect After connecting, confirm the device appears in Cloudflare Zero Trust and has a Mesh IP address. -### Step 5: Verify Mesh connectivity +### Step 6: Verify Mesh connectivity From the Dokploy admin server, test SSH to the remote server's Mesh IP: diff --git a/apps/docs/content/docs/core/guides/cloudflare-tunnels.mdx b/apps/docs/content/docs/core/guides/cloudflare-tunnels.mdx index 5b7ffc9..4f26d7c 100644 --- a/apps/docs/content/docs/core/guides/cloudflare-tunnels.mdx +++ b/apps/docs/content/docs/core/guides/cloudflare-tunnels.mdx @@ -217,9 +217,3 @@ This ensures Dokploy includes your domain as a trusted origin automatically. If you access Dokploy through multiple origins (public domain, internal IP, Tailscale), make sure all of them are listed in `BETTER_AUTH_TRUSTED_ORIGINS`. - -## Cloudflare Mesh - -Cloudflare Tunnel and Access are best for public or human-facing entrypoints, such as the Dokploy dashboard, browser-protected tools, human SSH through Access, and public websites. - -For private Dokploy server-to-server connectivity, such as remote-server SSH over a private IP, see the [Cloudflare Mesh guide](/docs/core/guides/cloudflare-mesh).