The Codenvy at
beta.codenvy.com is running the same workspaces that are within Eclipse Che. So if you can build / run workspaces within Eclipse Che it will work within Codenvy.
Whether you are using Che or Codenvy, each workspace is given a full allocation of a container. So the resource consumption is tied to the number of concurrent workspaces that are running at the same time. The older generation of Che - Eclipse Che 3.x, had a different model like you are suggesting. In that model, the projects were stored externally, and build / run requests were run against a pool of docker containers just for the duration of that request execution. Users could concurrently access the browser IDE and we could get 100s of concurrent users using the same VM. You can, in fact, get the 3.x version and use it this way.
This architecture -- while very efficient with resources -- was very problematic:
1. Project files had to be mounted / copied into each builder / runner on every execution. This takes time. Developers - when they press "compile" do not want to wait the 3 seconds of overhead for it to start.
2. There were certain artifacts created within the builders / runners that were not part of the project, but developers needed them to be. So there were problems on how to get the resources out.
3. All sorts of security problems.
So we have evolved to the current architecture where every workspace is fully isolated from others, each worksapce has its own IDE, and each workspace has a full project set where the developer can have full control over it. And we deal with the runtime overhead up front.
We are working on a Project API that will allow people to configure Che to allow users to do read / write actions to some files without having a workspace running. Only when a user initiates a command, such as build, would we start the workspace's runtimes. For large environments, this could offer some savings on resources by delaying when workspaces are started. We hope to have something like this out in a few quarters.
But for your specific scenario, if you are looking for a login system, you can implement your own or use Codenvy's. The workspaces are identical. Then within Che & the workspace, you can implement mounting to have the various file systems map to an S3 bucket if you wanted. The files that you need to worry about are the /workspaces, the /projects, and then within the container of each workspace, if there is protected data, you need to mount that too.
