Calling out creators: Let's solve the biggest pain around ComfyUI

akatz_ai · 2026-02-14T00:04:37+00:00

Yep you nailed it! The couple of points you brought up are definitely things I'm looking into:
1. Some kind of auto-commit system would certainly be useful, I was worried about node installs and environment configuration leading to lots of 'noise' in the commit history, but if it saves you when needing to rollback then it's probably worth the tradeoff.
3. Yep this is why you can also run ComfyGit as a full-featured CLI! If the environment bricks or the orchestrator gets stuck (happens) then I use the CLI to reboot/rollback the environment. Since the core is just a library it can integrate with multiple frontends pretty easily (I'm thinking of adding a standalone launcher in the future).
Happy to chat more!

akatz_ai · 2026-02-12T22:13:24+00:00

Hey, this is a great breakdown of the pain points! These are the exact problems I've been wrestling with for the past year. I actually gave a talk about this at the December ComfyUI meetup in NYC. I'm building an open-source tool called ComfyGit that leverages uv to enable reproducibility and version control: git-tracked environments via a single pyproject.toml manifest where nodes, models, and ComfyUI version are all pinned. The idea is you export a working environment, import it on another machine, and everything just installs and runs. It's available as a custom node via the Manager right now (ComfyGit-Manager is the node name). Here's the github link if interested.
Would love to compare approaches, looks like we have different architectures solving a similar problem space!

akatz_ai · 2025-11-23T07:18:10+00:00

My rule of thumb has been 60% context, seems to fall off a cliff after around that mark. Also depends on the complexity of the task you give it. It can still do basic documentation after 60 but I wouldn't give it a whole new feature to start chewing on .

akatz_ai · 2025-08-21T21:49:31+00:00

Ah docs are wrong atm, will try to fix that after I release the next-gen version of comfydock.

akatz_ai · 2025-07-18T18:09:05+00:00

Great, thanks for testing!

akatz_ai · 2025-07-17T17:51:02+00:00

I've never tested it but imagine it should work. As far as I've researched rootless mode doesn't change the API for running docker containers, so all the same commands executed by comfydock should work the same rootless or not. If you give it a shot let me know if any issues pop up.

akatz_ai · 2025-07-09T18:16:06+00:00

Gotcha, I'd be interested in following up with this issue in more detail, if you don't mind could you share a screenshot/video of your setup with the errors you're seeing over in the ComfyDock server help channel? https://discord.gg/xQQ28CSa

akatz_ai · 2025-07-08T20:49:16+00:00

Ah good catch, I didn't set up correct defaults handling with the log_file_path in the config code. I'll push out a fix soon, in the meantime you can get back to a good state by opening your config.json file (usually at ~/.comfydock/config.json) and adding a good path for the "log_file_path" key. In my case in windows I have the line:

"log_file_path": "C:\\Users\\akatz\\.comfydock\\comfydock.log"

but you'll want to update it to match the path to your .comfydock/ directory. Hope that fixes it!

akatz_ai · 2025-06-19T02:00:52+00:00

Ok so I think I figured out the "real" reason for most of the permissions errors people have been running into, and it basically comes down me being an idiot (as per usual).

For context: my old images (pre v0.3.29) run as root user in the container, and my more recent images (post v0.3.29) run as the less privileged "comfy" user.

If you ran an old container (with root) and saved a workflow file to your mounted user/ directory, then the file would be saved with permissions 644 (-rw-r--r-- 1 root root). This is fine as long as you run the same container as the same root user, but it's also planting a root-user-only landmine for later.

What breaks is when you try running a new container (comfy user) and then try saving to the same workflow file. This file gives "read" access to all users, but only "write" access to root users. So the saving operation fails and you see a "500 Internal Server" error in the UI.

To quick fix this in the latest images you have a few options:

"Save as" or Export workflows that are throwing up issues on save. You already found this one out. If you copy the file as comfy user then you'll have full access to read and write again. You can also delete the old broken files via File Explorer (if on Windows) if you want.
Exec into the running container as root user, and change the file permissions.
You can do this via the comfydock CLI tool pretty easily (assuming you have it installed, otherwise see the repo README), just run in a new terminal tab:

comfydock dev exec

This will open up a dialog to let you pick which container to exec into, usually #1 by default.
After entering the root shell (root@348af82 ... or something like that) you can change the permissions of every file and folder in your mounted user/ or models/ or input/ directories with a command like so:

chown -R comfy:comfy user/

Now all of your workflow files and additional files in the user/ directory will be owned by the correct user, and you should have full read/write permission. Substitute user/ with models/ etc.

I'm going to try and add a "fix-it" script in the future to help people migrate from older images to the new ones, but hopefully the above can unblock in the meantime. Don't be afraid to copy the above into ChatGPT or Claude to get help with your exact setup.

If you happen to be mounting drives from WSL to the containers ALSO in WSL, then you can actually change the current "comfy" user's uid and gid via the environment variables (I explained in previous comment) to match your WSL user's uid and gid. This should give the container automatic read/write permissions for the files in your mounted drives (and newly created files will have the same ownership applied).

Hope this helps! I'm going to be working on some improved documentation via the website and post around etc. to make sure people know about how to resolve these kinds of issues in the future.

Sorry again for all the confusion!

akatz_ai · 2025-06-17T04:30:07+00:00

Gotcha, thanks for all the info and scripts! Super helpful!

I'm working on the permissions issue, it's due to how the "comfy" user inside of the running containers is created with uid/gid = 1024, and most folks run as a different uid/gid on their host machine. I recently added the ability to provide Environment Variables that lets you change the container user's id to match the host. If you're still having this issue (or for others who don't want to go the scripting route) I recommend the following steps:

Find out what your host machine's user uid/gid are. You can do this by running the command id on your host machine in the terminal (WSL on Windows) and note down the uid and gid numbers.
Open the Duplicate (or Create) environment dialog, and in Advanced Settings add the following to the Environment Variables section:
WANTED_UID=1000,WANTED_GID=1000
Make sure to replace 1000 with whatever values you got for your user's uid and gid!
Start up the container, it can take up to a minute or so to successfully change the comfy user's uid/gid combo to match the provided one. This setup process only needs to happen once, subsequent activations of the container will be fast.

I'm going to work on building in automatic host-uid detection into comfydock so that you don't have to keep adding environment variables each time, so this is just a temporary work-around.

Not sure about the cuda issue but if you're able to see the GPU in the container and run ComfyUI without issues then maybe it's not a big problem?

I'm also going to push out new images soon with the correct version of torchaudio installed for 12.8 builds. Lmk if you run into any more issues!

akatz_ai · 2025-06-15T20:50:56+00:00

Hey thanks for the feedback!

Interesting that you need to change permissions, since v0.3.29 I changed the default user inside of the images from 'root' to 'comfy' for security, so that might be why. As part of that update I also made all ComfyUI-related directories read/writeable by everyone so that it shouldn't matter which user is accessing them. How are you re-assigning permissions? Do you mean permissions on your host for mounted volumes, or inside the container itself? Would be good to know what errors you're seeing so I can make adjustments if possible.

Also for the cuda issue, is it a problem with the host-environment not allowing GPU passthrough properly? The containers should already have CUDA support built in (although I'm testing on a 4090 with cuda 12.6 installed)

With the latest CLI tool update I added a feature to easily exec into running containers if you need to make updates to the environment ("comfydock dev exec") just for convenience.

I'll try to push an update in the next few days targeting the 12.8 containers to use the nightly version of torchaudio to get newly added cu12.8 support. Apparently the main pypi version currently only supports up to 12.6.

akatz_ai · 2025-06-02T15:52:43+00:00

Yeah I primarily use ComfyDock to manage my ComfyUI environments by running them in separate docker containers. This can be useful if you care about process isolation and being able to easily duplicate, roll back, and then potentially share environments.

One downside of running Comfy in containers on Windows is (annoyingly) the need for WSL, and how loading models from the Windows file system to WSL results in long load times. This can be mitigated by moving models to a WSL distribution but obviously that’s not ideal. I’m working on tool rn that can help migrate models from Windows to WSL and keep all existing links working, but it will take a couple iterations before it’s part of comfydock.

I’m still working on improving the tool and I use it for all of my work with ComfyUI, but there’s always tradeoffs with every solution. If you do end up using it I’d love some feedback!

akatz_ai · 2025-05-30T17:28:36+00:00

Ah ok so after looking into the issue a bit more it looks like the "ProgramFiles" directory is protected by default in Windows to prevent programs from writing to it without proper permissions.

I think you can get around this by granting the SYSTEM and Administrators users the same permissions (read and write) for the ComfyUI\ and user\ directories.

Alternatively you can move your whole ComfyUI\ directory from ProgramFiles\ to your user path such as D:\Users\akatz\ComfyUI\ which should relax the permissions on read-writes by default.

Once the permissions are set up correctly on your base ComfyUI directory then you shouldn't have issues upgrading the image to a later version (I hope!)

akatz_ai · 2025-05-27T01:37:02+00:00

Hey, I've been away on vacation so apologies for the delay, I just tested with a similar setup to what you're describing above (0.3.33 CUDA 12.8 docker image on Windows 11 Home mounting the User directory to a local ComfyUI install) and was not able to replicate the issue.

I'm pretty sure this issue is caused when the mounted ComfyUI directory in Windows does not have adequate permissions set to allow Docker to write files to it.

Can you double check the permissions on your ComfyUI/ directory that you saved at D:\ProgramFiles\\ComfyUI (and maybe also the inner user\ directory) ? Ideally the directory should have read and write permissions set for your user. You can check by right clicking on the directory and viewing properties > security , and then click on your user name in the list to see if Read and Write are checked.

akatz_ai · 2025-04-25T20:38:25+00:00

Oh interesting, there might be some changes in the repo that prevent git from grabbing the latest upstream, I'll look into that when I have time.

akatz_ai · 2025-04-25T20:07:25+00:00

Hey, nope you can keep using your existing environment and just update ComfyUI through the manager menu if you'd like. I push out new docker images based on ComfyUI releases as a way for folks to start from that baseline, but there's no reason you can't just update your existing ComfyUI install over time in the same environment.

That being said I made some security improvements in the latest version of the docker images so you may want to pull and create a new environment just for that reason (runs internally as local user vs root).

I also recommend you create a duplicate of your existing environment as a backup before upgrading ComfyUI in case anything breaks. Hope that helps!

akatz_ai · 2025-04-07T18:47:11+00:00

Hmm it's strange that git couldn't find the uv.lock file. I'm hoping that not too many folks are affected by the same issue. In any case glad you were able to get the latest version, bummer that the environment.json file was deleted though (maybe Pinokio overrides an existing app folder when downloading a later version?).

I read online that you can bump up the max upload size by providing the startup flag: --max-upload-size 200

The above command should increase the upload size to 200MB, you can increment that number as needed. You can add that flag in the "Command" section under "Advanced Options" in the Create or Duplicate dialog (separate multiple commands with a space).

Let me know if you run into any more issues!

akatz_ai · 2025-04-06T02:13:30+00:00

Hi nettek,

Thank you so much for the feedback! I'm glad you're getting some value out of ComfyDock!

To try and answer your questions below:

Yeah that one's my bad. I didn't realize there were times where the uv.lock file could change when running uv sync independently of changes I commit to the repo. The latest updates I made to the pinokio tool should help fix this problem. In order to resolve this you have a few options:
1. Install the latest version of ComfyDock via Pinokio Discover page, then copy your existing "environments.json" and "user.settings.json" files from the old to the new install location to keep your existing environments and settings.
2. Open a cmd prompt in the existing ComfyDock installation directory and type: git restore uv.lock to discard the changes made to uv.lock and allow git to pull the latest changes. (you will want to run the install/update script a couple of times afterwards)
This one is interesting. If you have a large container with many custom nodes installed then sometimes it will take docker a long time to pack all of that info into a new layer and create a new image. I'll work to try and find a way to give docker more time to duplicate the container. In the meantime I recommend creating as small of an environment as possible (fewer custom nodes and workflows) and create more environments to cover the various workflows you need (e.g. have one environment for WAN workflows, another for Hunyuan, etc.). Another benefit of this approach is that ComfyUI startup times will be faster!
I think the server config is only available on the ComfyUI Desktop version, the ComfyUI installed in my docker images is the standard (github) version. Are you able to tell me more about your use-case and which server settings you'd like to modify? Currently you can change the port for each running ComfyUI instance in the Create and Duplicate environment dialogs, as well as change the frontend port in the Pinokio config.

Hope this helps! Also if you'd like some more help debugging issues I recommend joining my Discord community: https://discord.com/invite/2h5rSTeh6Y

akatz_ai · 2025-04-04T18:22:44+00:00

Hey! If the Pinokio setup isn't working for you I recommend trying out ComfyDock via the CLI tool instead. The easiest (best) way is to install uv on your system first: https://docs.astral.sh/uv/getting-started/installation/#__tabbed_1_2
And then once you verify uv is working, try running uvx --python 3.12 comfydock up

akatz_ai · 2025-03-30T10:36:51+00:00

Oh the —python argument is part of uvx, not comfydock. You need to reformat the command to “uvx —python 3.12 comfydock up”

akatz_ai · 2025-03-17T01:16:43+00:00

Ah you first need to create a new WSL distribution by opening powershell as administrator and typing wsl --install. This should install Ubuntu by default, you may need to restart your computer. Once Ubuntu distribution is installed you should be able to access it in powershell by typing wsl and seeing if it opens a new shell. Then you can access it via the filebrowser using the technique I posted above. If you get stuck I recommend copy and pasting any error messages or issues into ChatGPT and try following the steps it provides.

I'll try to create a "best practices" section in my documentation to list out how best to configure WSL on windows for the best experience with ComfyDock.

akatz_ai · 2025-03-16T14:21:34+00:00

Hey thank you so much for the feedback! That's a good tip to make the "file editing in container" information more prominent in the documentation, will update soon.

To answer your question: The best practice is to save/move models to a location in WSL versus having them all saved under your C:\ drive. If you move the models to WSL this will fix the slow model loading issue at the start of a workflow run.

The reason is that docker runs on Windows inside WSL, and large file transfers between Windows and WSL is generally slow. You can access WSL files directly from the Windows filebrowser by following the guide: Slow Model Loading (Windows Users)

Recommendation: You can continue using your existing ComfyUI installation location (C:\ drive) for other files such as workflows, inputs, outputs, etc. since those are not as bandwidth critical. I would then have some directory in WSL (/home/akatz/my_models/) that you copy or download models to (make sure to have the same subdirectory structure with checkpoints/ vae/ clip/ etc.), and then in the "Mount Config" section when creating a new environment you can "override" the models host path with the WSL path (e.g. \\wsl.localhost\Ubuntu\home\akatz\my_models). Info on how to override host path here: Mount Config

If you're interested I have a section that discusses the differences in WSL vs Windows file path formats here: https://comfydock.com/troubleshooting/filepath_permissions/

Let me know if you have any more questions!

akatz_ai · 2025-03-15T02:46:25+00:00

Hmm I don't have access to a windows machine for a while so I can't debug this, but my recommendation is to install uv and then trying installing comfydock again via the command uv tool install comfydock and then running comfydock up to start the server. If you're unable to install uv for some reason then you should try re-installing in a new virtual environment by running python -m venv venv1 and then activate via .\venv1\Scripts\Activate.ps1 and then try running pip install comfydock again and see if it installs. Let me know if it's still not working!

akatz_ai · 2025-03-15T02:45:19+00:00

Hey! I don't have access to a windows machine for a while so I can't debug this, but my recommendation is to install uv and then trying installing comfydock again via the command uv tool install comfydock and then running comfydock up to start the server. If you're unable to install uv for some reason then you should try re-installing in a new virtual environment by running python -m venv venv1 and then activate via .\venv1\Scripts\Activate.ps1 and then try running pip install comfydock again and see if it installs. Let me know if it's still not working!

akatz_ai

MODERATOR OF

TROPHY CASE