To use ComfyUI remotely without publishing it to the open internet, keep ComfyUI on the host machine and connect your phone through an authenticated private network such as a VPN or tailnet with explicit access controls.
The short answer
Run ComfyUI on the computer that has the models and compute, place that computer and your phone in an authenticated private network, and allow only the users and port required for the interface. The phone opens the private address; the ComfyUI service does not need a public IP or an unauthenticated router port forward.
On the same trusted Wi-Fi network, ComfyUI’s documented listen option can make the interface reachable on the LAN. For access away from home, use a private VPN or tailnet you administer, or a hosted service designed with authentication. Do not turn a LAN setup into public access by forwarding the ComfyUI port directly from your router.
Why direct port forwarding is the wrong default
A public port makes the service reachable by internet scanners and anyone who discovers the address. Depending on the installation, an exposed interface may reveal workflows, prompts, previews, uploaded images, model names, queue actions, custom-node behavior, or API functions.
Adding an obscure port number or hard-to-guess URL is not authentication. If public access is truly required, place the service behind a maintained reverse proxy, TLS, strong authentication, authorization, rate limits, logging, patching, and a clear threat model. Most personal remote workflows do not need that exposure.
A private-network pattern
Install the private-network client on the ComfyUI computer and the phone. Confirm both belong to the intended account or organization, then restrict access so only the required user or device can reach the ComfyUI port. Tailscale Serve is one example that routes an internal web service to authorized tailnet devices while applying tailnet access controls.
Bind ComfyUI only as broadly as that design requires. A private overlay network does not excuse an allow-all policy: review member access, shared devices, expired accounts, device approval, and whether the service should be reachable by every device in the network.
Test the boundary before using private images
First test with non-sensitive content. From mobile data or another external network, confirm the private path works. Then disable or sign out of the private-network client and verify that the same address and port are no longer reachable. Check the router for an accidental port-forward rule and the host firewall for overly broad access.
Review ComfyUI and custom-node logs for requests from unexpected addresses. Keep the operating system, ComfyUI, custom nodes, reverse proxy if used, and private-network client updated. Remove unused nodes and credentials instead of leaving them available behind the network boundary.
Know what still leaves the phone
Remote ComfyUI is not on-device generation. Prompts and source images travel from the phone to the ComfyUI computer through the selected network path; outputs travel back. A private connection protects transport and reachability according to its configuration, while the host still stores or processes the data.
Cloud backup, browser downloads, shared folders, custom nodes, third-party APIs, and model-download tools can create additional data paths. Audit the complete workflow rather than treating a VPN label as a universal privacy guarantee.
PhoneDiffusion availability and article scope
PhoneDiffusion does not run ComfyUI or host, proxy, or authenticate a ComfyUI server. Its supported workflows run on iPhone or iPad with curated on-device model packs after required downloads.
Use remote ComfyUI when you need desktop graphs, arbitrary compatible models, custom nodes, or server compute. Use PhoneDiffusion when the supported on-device workflow and simpler local boundary are the better fit.
Field notes
- Prefer an authenticated private network over exposing the ComfyUI port to the public internet.
- Restrict access by user, device, and port; an overlay network with an allow-all policy is still too broad.
- Test that access fails when the private connection is disabled before uploading sensitive material.
Try it on your phone
- Verify ComfyUI locally on the host computer and save a known-working workflow.
- Install a maintained private-network client on the host and phone.
- Allow only the required identity and ComfyUI port through the private access policy and host firewall.
- Connect from an external network with non-sensitive input, then disconnect the private client and verify access fails.
- Remove router port forwards, review logs, and keep the host, ComfyUI, nodes, and network client updated.
Sources and verification
Primary and maintainer documentation checked for this guide. Product-specific details were reviewed against the current PhoneDiffusion scope.
- ComfyUI — official documentationOfficial overview of ComfyUI as a node-based interface and inference engine, including local and cloud operation.
- ComfyUI — local-network setup for the portable buildOfficial instructions showing that another device can access a ComfyUI server on the local network by enabling its listen option.
- Tailscale — private access to a local web serviceMaintainer documentation for making a local web service available only to authorized devices in a private tailnet.