### Description We have a customer who wants to use Workspaces in air-gapped environment. They have been largely successful. The primary challenge they are facing is that the injected VS Code fork is downloading assets from a CDN dynamically which they want to avoid. The goal of this epic is to tackle all challenges that a customer would face as part of running Workspaces in an air-gapped environment. ### GitLab VS Code fork asset serving challenge We inject [GitLab fork of VS Code(not Web IDE) into the workspaces](https://docs.gitlab.com/ee/architecture/blueprints/remote_development/#accessing-the-web-ide-from-the-workspace)(we don't consistently use the terminology). VS Code fork requires certain assets which it used to fetch from vscode.net . We have published these assets on our CDN which we use in Web IDE and Workspaces currently([source](https://gitlab.com/gitlab-org/gitlab-web-ide-vscode-fork/-/blob/3eaa3c733b190b306089e14836495d613b73659c/product.json#L33)). This problems affects both ~"Category:Web IDE" and ~"Category:Remote Development" . Potential solution is - Allow them to configure their own assets serving. - Since it would be a pain to package this in default GitLab installation, by default both Web IDE and Workspaces would use GitLab CDN for these assets. - However, we can give them to ability to bring their own CDN and then configure Web IDE and Workspaces to use that CDN (just like we allow them to configure which extensions marketplace to use). - To make it easy for brining their own CDN, we could create a separate repository/NPM-package which has assets and steps on how to publish it to common CDN providers (maybe even GitLab pages? :wink: ). They would perform the steps to publish it to the CDN and them configure Web IDE and Workspaces to use that CDN.