ComfyUI Remote Mac: Node Environment Acceptance Checklist

A ComfyUI remote Mac opens in your browser, but the first workflow fails with missing nodes, an unavailable model, or a broken Python dependency.

Fastest fix: accept the environment only after checking the base system, PyTorch backend, ComfyUI startup, model paths, custom nodes, workflow output, restart recovery, and remote security in that order.

This runbook is for you if you are preparing to rent a remote Mac for ComfyUI and need to catch delivery problems immediately. It also suits team administrators maintaining shared workflows and creators who frequently move ComfyUI between machines.

Last updated August 10, 2026. Technical details were checked against the ComfyUI installation documentation, Apple’s PyTorch and Metal guide, and official ComfyUI documentation.

Start with the handover record, not the browser

Before opening ComfyUI, collect the information that defines what was actually delivered. A remote Mac handover is incomplete if you do not know which macOS release, chip architecture, Python environment, ComfyUI revision, model location, and access method you received.

Do not infer the machine from a product label. Record the output from the machine itself:

sw_vers
uname -m
system_profiler SPHardwareDataType
python3 --version
git --version

The architecture check matters because Apple Silicon and Intel environments can expose different Python wheels, acceleration backends, and custom-node behavior. The official ComfyUI installation guidance supports Apple Silicon, but it still requires a compatible Python and PyTorch setup rather than a visual confirmation from the Mac desktop. (ComfyUI installation documentation)

Storage is a hidden failure point. Check the actual free space instead of accepting a nominal storage description. Model files, preview outputs, temporary downloads, Python packages, and node dependencies may use different directories. A workflow can fail even when the main ComfyUI folder looks healthy.

Remote access also needs a clear boundary. SSH may be enough for logs, updates, and scripted checks. Screen sharing is useful when a node depends on the graphical interface, but it creates a wider operational surface than a terminal-only workflow. Record the approved access method, account owner, password-handling process, and recovery contact before acceptance.

For related planning, use Macstripe’s configuration and order guide to document the software stack and access requirements before requesting a remote environment.

If you cannot identify the runtime, storage location, account owner, or access method, pause acceptance and request a complete handover record.

Verify the Python and PyTorch layer in a clean shell

The next checkpoint is the environment underneath ComfyUI. Do not rely on the Python command that happens to work in a graphical launcher. Activate the intended virtual environment and capture the interpreter path:

which python
python --version
python -c "import sys; print(sys.executable)"
python -c "import torch; print(torch.__version__)"

The objective is not to chase a particular version number. The objective is to prove that ComfyUI, PyTorch, and custom-node dependencies use the same isolated environment. ComfyUI’s dependency guidance explains that custom nodes may require incompatible versions of the same Python package. One node can require an exact release while another asks for a newer minimum release. (ComfyUI dependency documentation)

On Apple Silicon, test the MPS backend directly:

python - <<'PY'
import torch

print("torch:", torch.__version__)
print("mps built:", torch.backends.mps.is_built())
print("mps available:", torch.backends.mps.is_available())

if torch.backends.mps.is_available():
    x = torch.ones(1, device="mps")
    print(x)
PY

Apple’s PyTorch guidance explains how to verify MPS support on Apple Silicon and notes that the backend is still subject to framework and operator limitations. Treat the result as a backend checkpoint, not as proof that every ComfyUI node will run without changes. (Apple PyTorch and Metal guide)

A common bad handover looks successful because python main.py starts, while a later custom node invokes a different interpreter. Save the shell history, pip list, and the ComfyUI startup log. These records are more useful than a screenshot of the interface because they expose import paths, package warnings, fallback behavior, and failed node loads.

Launch ComfyUI and preserve the startup evidence

Start ComfyUI from the environment you just tested. Keep the terminal output visible or redirect it to a dated log file:

python main.py 2>&1 | tee comfyui-startup.log

The acceptance condition is not simply “the page loads.” Check all of the following:

• The server starts without import exceptions.
• The expected ComfyUI directory is used.
• The expected Python interpreter is shown or can be confirmed.
• Custom nodes are listed as loaded rather than skipped.
• The frontend loads without a fallback or missing-package warning.
• The output directory can receive a test file.
• The service is reachable through the agreed remote access path.

For a shared environment, record the ComfyUI revision and frontend state instead of allowing silent updates. A workflow can remain visually intact while a changed frontend, node API, or dependency alters how it behaves. Pinning the software state gives you a reference point when a node later becomes incompatible.

A clean startup log is your first diagnostic artifact; save it before installing anything else.

If the interface opens but the terminal reports skipped nodes, missing dependencies, or frontend fallback messages, do not proceed to workflow acceptance. Fix the foundation first. Updating only the ComfyUI repository without updating its dependencies can leave the interface, templates, or node documentation out of sync.

Map model directories and test persistence

A workflow depends on more than its JSON file. It may require checkpoints, VAE files, LoRA files, ControlNet assets, input images, output folders, and custom-node resources. ComfyUI documents model locations as separate dependencies, and its model guidance explains how external model directories can be connected through extra_model_paths.yaml. (ComfyUI model path documentation)

Inspect the actual directories used by the delivered instance:

find ComfyUI/models -maxdepth 2 -type d
ls -la ComfyUI/models/checkpoints
ls -la ComfyUI/models/vae
ls -la ComfyUI/models/loras

If your team shares models between multiple ComfyUI instances, verify the external path configuration instead of copying files blindly. Copy the example configuration, rename it to extra_model_paths.yaml, define the relevant base and subdirectories, and restart ComfyUI before testing the paths. Back up any existing configuration before changing it.

How do you verify that a remote environment keeps model paths after a restart?

Record the configured path, load one model from each required category, restart ComfyUI, and load the same workflow again. A path that works only during the first session is not accepted. Check both read access and write access: model folders need to be readable, while output and cache folders must be writable by the account running ComfyUI.

Use a small test asset first. You do not need to download a large model merely to prove that the directory mapping works. The test should show that:

• The loader node can see the expected file.
• The selected model remains available after restarting.
• The workflow does not silently switch to another similarly named file.
• The output folder receives the generated artifact.
• A shared account can read the model without changing ownership manually.

Storage permissions are another hidden cost. If files were copied by an administrator account, the ComfyUI user may be able to list the directory but not write previews, metadata, or generated outputs. Test file creation as the same account that launches the service.

Install ComfyUI Nodes in dependency batches

Custom nodes should be installed according to workflow dependency, not according to an unverified “must-have” ranking. The right node for your team is the one required by a defined workflow and compatible with the delivered Python, PyTorch, frontend, and ComfyUI state.

The safest sequence is:

• Import the target workflow before installing everything.
• Record every missing node name.
• Group nodes by the workflow that requires them.
• Install one small batch.
• Restart ComfyUI.
• Run a minimal test.
• Save the commit, package output, and startup log.
• Continue only when the previous batch passes.

ComfyUI Manager can help detect missing nodes and install registered packages, while manual Git installation is useful when you need a specific repository revision or a package that is not available through the Manager interface. The official custom-node guidance also stresses that dependencies must be installed inside the correct ComfyUI environment. (ComfyUI custom-node documentation)

What should you check after installing a custom node?

Check that the node appears in the search interface, loads without a startup exception, exposes the expected inputs, and completes a minimal operation. Then inspect the terminal for dependency warnings. A node can appear in the interface while failing only when it imports a secondary library during execution.

Keep a simple node manifest:

Node package:
Repository:
Commit:
Install command:
Requirements file:
Python environment:
Workflow tested:
Result:
Known limitation:

This record is particularly important for shared teams. A later update can change a node’s dependency requirements, replace a frontend component, or remove a node class that an older workflow expects.

Do not install all requested nodes in one command. If the final environment fails, you will not know which package caused the conflict. Batch installation gives you a rollback point and makes the acceptance record useful to the next administrator.

What if a ComfyUI workflow is missing nodes?

First determine whether the missing node is native or custom. For a custom node, use the Manager’s missing-node detection if the package is registered. If it is not available there, inspect the workflow author’s repository and install the required revision manually. Do not install every result with a similar name. Confirm the class name, repository, dependencies, and license before adding it to a shared machine.

For a native node, compare the workflow’s expected ComfyUI state with the delivered revision. Updating the application may solve the problem, but it can also introduce new dependency changes. Save the current environment before making that decision.

Run the fixed workflow before handover

A fixed workflow is the central acceptance test. It should represent the smallest real task your team expects to perform and should include the full path from input to saved output:

• Load the required model.
• Load the required text or image input.
• Execute the sampler or processing stage.
• Apply any required custom-node operations.
• Save the output to the agreed directory.

ComfyUI workflows can be saved as JSON files for versioning and sharing. Keep the original JSON separately from generated images so your team can compare workflow changes rather than relying only on embedded metadata. (ComfyUI workflow documentation)

Run the workflow once with the intended model and input. Save:

• The workflow JSON.
• The generated output.
• The startup log.
• The execution log, if available.
• The node manifest.
• The model path record.
• Any warning or error text.

Do not judge acceptance only by image quality. The handover test is about reproducibility. The same workflow should load the same node classes, locate the same model categories, write to the expected directory, and complete without manual repair.

If a workflow contains missing nodes, ComfyUI may display a missing state after import. Manager can help locate registered nodes, but the tool cannot prove that the selected version is compatible with the rest of your workflow. After installation, run the complete graph rather than stopping once the node names appear.

A useful team rule is to keep one small acceptance workflow under version control. It should be stable enough to run after every node update, Python change, ComfyUI update, or machine restart. If this workflow breaks, stop production changes until the failure is explained.

Reboot, recover, and close the access boundary

The final stage tests whether the environment survives the event that causes many remote setups to fail: a restart.

Before rebooting, save the startup command, environment activation command, model path configuration, node manifest, and workflow file. Then restart the ComfyUI process first. If your delivery scope includes machine reboot recovery, restart the Mac as well and repeat the test after the remote service returns.

Your acceptance record should answer these questions:

• Does ComfyUI start from the intended directory?
• Does the virtual environment activate correctly?
• Are the same custom nodes loaded?
• Are model paths still visible?
• Can the fixed workflow generate an output?
• Does the output directory retain the correct permissions?
• Is the remote port reachable only through the agreed route?
• Are credentials or API keys stored outside shared workflow files?
• Can another authorized team member access the shared directory without changing ownership?

For remote access, keep the service behind the agreed authentication and network boundary. Do not publish a development interface directly to the public internet merely because it makes browser access easier. If the team needs remote API access, document the authentication method, allowed users, port exposure, and credential rotation process.

ComfyUI troubleshooting guidance distinguishes local behavior from remote access and includes API-key considerations for non-localhost access. Use that documentation as a reference when reviewing the final access path. (ComfyUI troubleshooting documentation)

Use this final checklist at handover:

• [ ] The delivered macOS version and chip architecture are recorded from the machine.
• [ ] The available storage and model locations are documented.
• [ ] The account used to run ComfyUI has the required read and write permissions.
• [ ] The Python executable points to the intended isolated environment.
• [ ] PyTorch imports successfully.
• [ ] MPS availability is tested on the delivered Apple Silicon environment.
• [ ] Git and required repository access work.
• [ ] ComfyUI starts from the documented command.
• [ ] The startup log is saved.
• [ ] The frontend loads without an unexplained fallback.
• [ ] Required checkpoints, VAE files, LoRAs, and other assets are visible.
• [ ] External model paths are configured through the documented method.
• [ ] Every required custom node is recorded with its repository and revision.
• [ ] Each node batch passes a minimal execution test.
• [ ] The fixed ComfyUI workflow loads without missing nodes.
• [ ] The workflow completes the model-load, processing, and save-output path.
• [ ] The output artifact is saved in the expected shared directory.
• [ ] ComfyUI is restarted and the workflow is run again.
• [ ] The Mac reboot recovery path is tested if included in delivery.
• [ ] Remote access, credentials, ports, and shared-folder permissions are reviewed.

Choose a remote Mac only when the handover can be repeated

A self-managed local Mac gives you direct hardware access, but it also leaves you responsible for macOS updates, Python isolation, model storage, remote connectivity, account permissions, and recovery after a broken node installation. A generic cloud host may simplify access, yet it can introduce unfamiliar filesystem behavior, changing images, or limited control over the software layer you need to reproduce.

A Macstripe rental is more suitable when you need a temporary Apple Silicon environment, a repeatable ComfyUI setup, or a controlled place to validate a workflow before committing to a longer deployment. It is less suitable for a permanent, high-duty production system that must remain unchanged for months or for workloads requiring direct physical interfaces.

The practical choice is to carry this checklist into the order conversation: specify the model directories, custom-node list, fixed workflow, restart test, remote access method, and rental period. If you need help clarifying those requirements, use Macstripe’s support and contact options before the environment is delivered. You can also review the remote Mac help center when documenting access and recovery procedures.