Is it possible to support multiple users ?

[oumad]

Would it be possible to support multiple users? something similar to how A1111/forge/fooocus does it using gradio? we can basically have a list of credentials file reading the user/password pairs.

Our goal is to provide some minimal privacy for users sharing the same instance of ComfyUI, when they login we can retrieve their username to modify the output path to something like "output/[username]/date...". We do the same thing for Loras folder, so users get to have their own loras individually on the same instance.

Would this be possible to achieve using this custom node ?

Thank you.

[liusida]

My suggestion and best practice is to use docker to isolate different ComfyUI instance.

You can try my docker image: https://hub.docker.com/layers/sidaliu/comfyui/comfy-cli/images/sha256-0274da457d48876b6ecd37765870b1ab1c988b94ac8bfc4cd517310ed066808a?context=repo

An example of using it via docker compose is here: https://github.com/liusida/ComfyUI-dockers (main file: docker-compose.yml)

[liusida]

FYI: this image: sidaliu/comfyui:comfy-cli uses comfy-cli to install brandnew ComfyUI instances in docker containers.

[oumad]

The only issue with that is queue management, for example with the other UIs that are gradio based, since users share the GPU instance, if they generate an image at the same time, they get in a queue as opposed to having their inference time slowed down, this is why we didn't go towards multi instance path. So far this has worked for us perfectly on A1111, Forge, Fooocus. We just need to achieve the same with ComfyUI.

[liusida]

Yes. queue management will be a pain.

ComfyUI is very versatile, especially with ComfyUI-Manager, people can install custom nodes that can do basically anything, including running dangerous programs on server. What's your thought on that? Provide only limited functionalities instead of the full fledged ComfyUI?

[liusida]

I've shared my ComfyUI instance with my friend earlier, and he's changed the basic UI by installing some translation nodes! That's why I started using docker.

[liusida]

I was thinking about a restricted mode recently: https://github.com/comfyanonymous/ComfyUI/issues/3740

But I'm not quite sure if this is the right direction.

[oumad]

Yes. queue management will be a pain.

ComfyUI is very versatile, especially with ComfyUI-Manager, people can install custom nodes that can do basically anything, including running dangerous programs on server. What's your thought on that? Provide only limited functionalities instead of the full fledged ComfyUI?

Yeah I did consider that, the solution I had in mind for now is simply to disable ComfyUI-Manager when running a shared instance, just like with A1111 you have the option to not allow non localhost users to install extensions and change important settings. Infact, with A1111 it's the default behavior until you add this argument --enable-insecure-extension-access

[liusida]

ComfyUI-Manager is just one major way to modify the server. Other nodes can do this too, like this very node, ComfyUI-Login, also modifies some of the core system... If we don't allow users to use their favorite nodes, ComfyUI becomes much less attractive.

Need to come up with a better solution. I'll sleep on it.

[oumad]

In our specific case it is really not that important, because we plan to provide our artists with specific pre-made workflows. Advanced users who will want to tinker and make new workflows (or import them from internet), will usually have an installed instance locally. So just like with A1111 we locked things like extensions, models, controlnets... we plan to do the same with ComfyUI, so we really don't mind having an instance with precise custom nodes that we maintain for all the users. In fact in our case we plan to go further by exposing these specific workflows through a simplified UI (for now we're thinking of using mixlab for this).

The solution you try to find seems to be more suited for online services that are geared to power users who just don't have the GPUs to do the work, like this one https://comfy.icu/ which for now I think they also maintain specific versions of the most commonly used custom nodes.

[liusida]

Thanks for sharing your use case. I think a frozen/restricted mode can be helpful in your case.

It might be like that: if there is a specified .yml file, say frozen.yml, the system will enter a frozen mode. The system will exam each workflow so that only nodes on the whitelist can be executed. And no custom nodes can be installed under frozen mode. But the users can still adjust the links and provided nodes, adjusting the parameters, so they can generate their own version of art.

Do you think this might help? Do you still need multiple usernames/passwords for this use case?

[liusida]

or should i call it the guest mode?

[oumad]

That's a nice idea, and I like all those names "frozen", "restricted", "guest". The user/password input for me is necessarily especially for output and LoRA directories, we want each artist to have their own output folder (an artist can have access rights to their output folder only, but the instance can write to all of them), it will look like output/username/... same thing for Loras, it would look like models/username/loras (or models/loras/username). This is how we provide a required amount of privacy to our artists.