[FEAT] fully functioning terminal

[LEstradioto]

closes #2298

• Enables Web Terminal to every Command Center
• A new container (terminal-coolify) is added to Coolify Networks to run a node Websocket

How it works:

• The new container is a nodeJs server (though we could improve this later if we want to use PHP only, here is my comments on this)
• A reverse-proxy enables port 6002 without firewall need (just like soketi is working)
• XTerm.js is the front-end Web terminal enhanced with copy/paste, flowcontrol, resizing, mobile ok
• A note about security and about destinations/servers
• The connection happens as usually was done via ssh. Only difference is the RequestTTY=yes option passed by as args. To enable direct connection between socket and terminal using PTY

---

• websocket server and node-pty integration with coolify servers and containers
• reversed-proxy websocket port 6002, no need to firewall anymore
• enables copy/paste on terminal and text selection fixed with css zoom attribute tweak
• FEAT: Implement flow control as recommended by xterm documentation (is this really important?). Consider using socket.io or sockette for better performance and reliability.
• ensure better resizing to xterm (window resize and mobile)
• rethink about getAllActiveContainersUUID()
• Double check security
• Test destinations
• Add it to any other Command center = ExecuteContainerCommand
• Refactor and add it to Prod

[ayntk-ai]

Looks great. I know that this is maybe not possible but adding an extra container to each application deployed is not ideal, could this container just be deployed once on the coolify level? And also each stack/ app and services have their own network for isolation so I am not sure if 'netowork -coolify' will work

[Thijmen]

@ayntk-ai It already looks like it is only one container per Coolify instance. Correct me if I am wrong, @LEstradioto

[LEstradioto]

Yep, it resides with coolify network, so it should be only one per instance. About isolation, I used the same logic implemented before with Command Center sending the commands to containers, but, the difference is the long running attached process with support of Websocket.

Without Websocket, Ive tried to use PHP Eventloops, but I couldnt resolve.

Another way would be to re-use Laravel Pusher/Echo, and soketi, but they dont provide SDK to re-use the same process (that would be perfect because we already have a 'coolify realtime container running')

Anyway still need a separate process

[Thijmen]

Do you think you can add traefik routing as well, so we don't have to open ports on production?
I'm more than happy to take a swing at adding it.

[ayntk-ai]

@ayntk-ai It already looks like it is only one container per Coolify instance. Correct me if I am wrong, @LEstradioto

Really amazing. What about the network settings: In coolify there is a different destionation/network for each service, will this just work with the network -coolify setting and then the Terminal will show up on each container and on the full server?

[LEstradioto]

@Thijmen I tried to route it to avoid open a new port. I can't get it working.
It should be easy to at least forward eg Path Rule '/ws' to terminal container, but Im not understanding how

@ayntk-ai I couldnt test on different sever, but probably would work since main host is like a root/sudo... right?

[ayntk-ai]

@LEstradioto I am not sure, but I think the problem might be that the terminal container needs to be redeployed for each new service/application we spin up, as each of these comes with its own network: network-uuid, this is automatic, and we can also manually add networks to services by selecting predefined networks. Maybe I am wrong and the - coolify network adds all networks automatically created by coolify (which would be nice)

[LEstradioto]

ps.: my styling is awful 😭

Added some milestone to improve at title

[LEstradioto]

@Thijmen I think I did it ! Dont need to open firewall port anymore, reverse proxy seems to work. Tested on localhost only though.

[LEstradioto]

now help wanted about three things:

• here, on dispatch, the ssh command is sent from livewire to JS then sent to websocket, I couldnt hijack the websocket directly on livewire to protect the ssh string, is this a problem?
• is it needed to check for auth before connect to a container? because ssh command do this on its own, doesnt?
• test about what @ayntk-ai said, if on extras destinations, terminal will be re-deployed

[ayntk-ai]

3 things that would be nice for this:

• A full log of all the commands we have run in the terminal (with automatic log rotation and deletion)
• A snippet store -> so we can store most used commands as snippets and easily execute them with one click (not have to retype them every time)
• Run commands on multiple containers at the same time -> could be achieved with the tags system --> But maybe not that smart for security?

[ayntk-ai]

now help wanted about three things:

• here, on dispatch, the ssh command is sent from livewire to JS then sent to websocket, I couldnt hijack the websocket directly on livewire to protect the ssh string, is this a problem?
• is it needed to check for auth before connect to a container? because ssh command do this on its own, doesnt?
• test about what @ayntk-ai said, if on extras destinations, terminal will be re-deployed

I think @LEstradioto could use your help with these above @Thijmen

[LEstradioto]

now help wanted about three things:

• here, on dispatch, the ssh command is sent from livewire to JS then sent to websocket, I couldnt hijack the websocket directly on livewire to protect the ssh string, is this a problem?
• is it needed to check for auth before connect to a container? because ssh command do this on its own, doesnt?
• test about what @ayntk-ai said, if on extras destinations, terminal will be re-deployed

So, answering myself here:

Accessing the container's SSH string requires knowing the container's name/uuid, which is unlikely without prior access. Users on this page can likely modify containers in various ways. Authentication before connection isn't necessary since the route already handles it.

[LEstradioto]

3 things that would be nice for this:

• A full log of all the commands we have run in the terminal (with automatic log rotation and deletion)
• A snippet store -> so we can store most used commands as snippets and easily execute them with one click (not have to retype them every time)
• Run commands on multiple containers at the same time -> could be achieved with the tags system --> But maybe not that smart for security?

Initially, I thought this ideas was useful. However, it seems more suited for a development environment, which is not typical for this kind of terminal, since it would require a better dev setup. This might be better addressed in another pull request or discussions to understand its use cases. I couldn't find a good use for it myself, so I'm unsure.

[Thijmen]

I think @ayntk-ai would make a great product owner, I am absolutely loving the ideas! 🙌

[LEstradioto]

I think it's done!

I would appreciate a review on this, especially the last commit on Docker Compose. I'm not entirely sure if this meets your expectations in all aspects @andrasbacsai 🙏

Regarding destinations, I added servers using the Coolify Dashboard, and everything ran smoothly. I haven't tested with Swarm, but it should work as well. I also didn't test with a new network as @ayntk-ai mentioned earlier. In my tests, Coolify manages everything under one network and isolates by teams only. Am I wrong? I'm probably just tired now. Going to sleep, bye! 🤣

[ayntk-ai]

@LEstradioto I will try it out once it is released. I think you should merge it into next and remove WIP.

[LEstradioto]

Updated OP with a brief "How it works" section to make it easier for @andrasbacsai to review.