Questions on Commercial Use and Running a Customized VS Code (e.g., Cursor-like Build) with code-server #7592
-
|
Hello, and thank you for providing such an excellent project. I am currently using code-server for a product demo and would like to ask a few questions regarding commercial use and custom VS Code builds. My product’s service model is to provide users with an ECS image. Users deploy this image on their own servers and then access the customized VS Code service running inside it through a provided URL. 1. Questions Regarding Commercial UseGiven this deployment model, if I plan to commercialize the product in the future, what additional requirements or work should I consider?
Any guidance on typical best practices or obligations for commercial use of code-server would be greatly appreciated. 2. Running a Customized VS Code (e.g., a Cursor-like Edition) on code-serverI would like to integrate a customized VS Code distribution—such as a fork with UI or functional modifications, or something similar to Cursor—into code-server. Could you provide guidance on the following:
My goal is that:
Thank you very much for your time. I appreciate any further guidance or suggestions from the community. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
No, you can use and deploy code-server however you wish.
The base requirements we have for code-server are 1 GB of RAM and 2 CPU cores, so I would use that as a starting step. I think the points here are good in general: https://coder.com/docs/tutorials/best-practices/scale-coder#workspaces-per-node (technically this is for Coder, not code-server, but from what I can tell Coder might be doing what you are trying to do, or is similar at least).
With Coder, we run code-server in separate Docker containers on a single node and I think this is probably the ideal way to do it. If you need to run multiple instances without containerization, I would run them as separate users and listen on sockets instead of ports. The built-in password authentication should be OK, but personally I would put something in front to handle auth in a case like this, ideally something that unifies with whatever else you might be building (in our case, Coder handles the auth).
I think generally the recommendation would probably be Kubernetes (we do recommend it for Coder), but there are no official recommendations for code-server. As for the rest, it will really depend on your needs I think.
No, firstly each version of code-server only supports a specific version of VS Code. The reason for this is that our patches will generally not cleanly apply from one version to the next, so supporting multiple versions is simply not possible unless we also maintained separate versions of the patches. It might help to think of code-server less like it "bundles" VS Code and more like it forks VS Code. You might be able to swap the underlying VS Code and the patches will still apply successfully, but there is no guarantee. Secondly, you would have to swap in the actual source code, so our patches can apply. This makes building code-server off something like Cursor impossible since Cursor's source is not available (at least not last I checked).
Not as far as I am aware. I think generally I would recommend that your custom VS Code build targets the same version that code-server targets, and it should be mostly OK unless you modify an area that one of our patches also modifies. If you can, it might make the most sense to maintain your custom VS Code changes as patches in a code-server fork alongside our own patches. |
Beta Was this translation helpful? Give feedback.
No, you can use and deploy code-server however you wish.
The base requirements we have for code-server are 1 GB of RAM and 2 CPU cores, so I would use that as a starting step.
I think the points here are good in general: https://coder.com/docs/tutorials/best-practices/scale-coder#workspaces-per-node (technically this is for Coder, not code-server, but from what I can tell Coder might be doing what you are trying to do, or is similar at least).