Arama Yap Mesaj Submit
Request a Callback
+90
X
X

Select Your Currency

Turkish Lira $ US Dollar Euro
X
X

Select Your Currency

Turkish Lira $ US Dollar Euro

Contact Us

Location Halkali merkez neighborhood fatih st ozgur apt no 46 , Kucukcekmece , Istanbul , 34303 , TR
Last technical review · 17.08.2026 · Dokploy Private Edge

Dokploy Network Design: Applications via Cloudflare, Management via Tailscale

Cloudflare Tunnel and Tailscale are not substitutes. One can carry public application traffic to the origin over an outbound tunnel while the other provides private overlay access for operators and nodes.

Production note

Installing Tailscale does not automatically close public SSH; Cloudflare Tunnel does not automatically secure the origin firewall. Remove obsolete inbound paths explicitly.

dokploy cloudflare tunneldokploy tailscaledokploy private network
TECHNICAL IMPLEMENTATION PROFILE
EKA CORE
Dokploy Private Edge

On the same Dokploy host, give each network one purpose: Cloudflare Tunnel for public application ingress, Tailscale for admin/SSH/internal access. Avoid overlapping route and DNS scope.

EdgeCloudflare Tunnel
Checked
MeshTailscale
Checked
0Target public admin ports
Checked
ACLWho can reach what
Checked
Technical guide · production-focused · official sources
Quick answer

On the same Dokploy host, give each network one purpose: Cloudflare Tunnel for public application ingress, Tailscale for admin/SSH/internal access. Avoid overlapping route and DNS scope.

01

Technical scope at a glance

Use Cloudflare Tunnel for application edge and Tailscale for a private management network around Dokploy, with routes, DNS, ACLs, origin access and failure-mode design.

EdgeCloudflare Tunnel

Outbound connectivity model for public web traffic.

MeshTailscale

WireGuard-based overlay for admins and private services.

0Target public admin ports

Moving SSH/panel access to a private overlay can reduce public admin exposure.

ACLWho can reach what

Private-network security depends on identity and policy as much as routes.

On this page

  1. 1. Separate edge and management planes logically
  2. 2. Scope Cloudflare Tunnel ingress by hostname
  3. 3. Add a Tailscale subnet router only when required
  4. 4. Move beyond “inside tailnet equals trusted”
  5. 5. Avoid collisions between public DNS and MagicDNS
  6. 6. Close public management paths after private access works
  7. 7. Define behavior when Tunnel or Tailscale fails
  8. Frequently asked questions
02

1. Separate edge and management planes logically

Even with one NIC, access paths can have separate policy. Public app domains and administrator SSH do not need the same ingress mechanism.

FlowTransportIdentity
User → appCloudflare TunnelApp auth / edge policy
Admin → SSHTailscaleTailnet identity + ACL
Node → nodeTailscale/private routeMachine identity
03

2. Scope Cloudflare Tunnel ingress by hostname

Keep catch-all rules last and do not forward unknown hostnames into origin services.

Use explicit service mappings for each production hostname.
Reject unexpected host headers with a 404 catch-all.
Store the tunnel token as a platform secret.
04

3. Add a Tailscale subnet router only when required

If the host is reachable by its own Tailscale IP, advertising entire Docker/VLAN subnets may create unnecessary access scope.

Command
tailscale status
Command
tailscale ip -4
Command
ip route
Command
ss -lntp
05

4. Move beyond “inside tailnet equals trusted”

Admin laptops, CI runners, monitoring nodes and production servers should not share identical privileges. Use role/tag-based policy.

IdentityPermission
AdminSSH + panel
CIDeploy endpoint only
MonitoringMetrics only
App nodeRequired internal ports
06

5. Avoid collisions between public DNS and MagicDNS

The same short hostname resolving differently in public and private DNS complicates troubleshooting. Use a distinct management namespace.

Use `app.example.com` for the public application.
Use a dedicated internal name for management.
07

6. Close public management paths after private access works

Verify private SSH/panel access from a second admin session before tightening public access. Keep console/BMC recovery for lockout scenarios.

Command
tailscale ping ADMIN_DEVICE
Command
ufw status numbered
Command
ss -lntp | grep -E ":22|:80|:443"
08

7. Define behavior when Tunnel or Tailscale fails

A Cloudflare Tunnel agent failure can affect public applications; Tailscale issues can affect administration. Define separate fallback paths.

FailureImpactFallback
cloudflared downPublic app ingressAgent restart / secondary connector
Tailscale unavailableAdmin/private accessConsole/BMC/break-glass IP
EKA SUNUCU · TECHNICAL

Run public applications and private management under separate network policies

Plan Dokploy origin, Cloudflare Tunnel and a Tailscale management network on Eka Sunucu VPS with minimal public port exposure.

Production principleMeasure → Test → DeployNo fabricated benchmark data.
SRC

Official sources

Primary documentation and technical references used by this guide.

EKA

Related technical guides

Continue with related infrastructure and implementation guides.

FAQ

Frequently asked questions

Dokploy Private Edge

Are Cloudflare Tunnel and Tailscale the same thing?

No. Cloudflare Tunnel can serve public edge/origin connectivity while Tailscale provides private overlay and identity-based access.

Can I close public port 22 when using Tailscale?

After private access and break-glass recovery are validated, public SSH exposure can be reduced according to your topology.

Does Cloudflare Tunnel automatically close 80/443?

No. Tunnel is outbound; existing inbound firewall rules remain until you change them.

Can the Dokploy panel sit behind Cloudflare Tunnel?

There are workable designs, but administrator access still needs an identity layer such as Cloudflare Access/Tailscale/VPN plus a recovery path.

Top