Is Theia multi-tenant in any way?

[original thread by dehru]

Theia can server multiple clients. Each client gets own running instances of language servers, VS Code extensions with own state of dirty editors and so on. But at the same time several clients using the same backend will see each other processes like terminals, debug sessions and so on. If you don’t want such sharing you will need to give each client own backend what products like Gitpod, Google Cloud Shell or Eclpise Che do.

@dehru also consider that Theia is meant to be use to produce desktop application as well as Cloud applications. On the desktop (Electron) it’s assumed that the user has already authenticated and will have exclusive use of this application.

So what we have is the smallest common denominator to satisfy both those use-cases.


Thanks Anton and Marc. Let me be less vague.

I am evaluating how to use Theia as a potential framework for a multi-tenant web code editor. As such I am comparing it to how other web-based code editors, like GitPod, Coder, Che, are doing it. The current requirement is for both soft multi-tenancy (users from the same trusted company) and hard multi-tenancy (users from the different companies). The degree of isolation is different for each.

At this point, I am trying to figure out how much of our tenancy requirements can be accomplished with just Theia ( the source at ). So I’d like to understand a bit more about Theia’s webserver.

What requirements does Theia’s webserver fulfill (and what it doesn’t)? / What was it built to accomplish?

And to follow up on that question, to support our multi-tenancy requirements, if I’m going to need to:

  1. Replace it with our own?

  2. Augment it with BackendApplicationContributions?

  3. Build a wrapper around each instance of Theia (like what Anton suggested)?

If anyone else is using Theia this way ( soft and hard multi-tenancy ) and are willing and able to share what they are doing, that would be appreciated too!

Hi @dehru . As far as I understand, the built-in web server is used (only?) to serve the frontend application in vanilla Theia. Using option 2, you should be able to make it do more, with your own contribution(s).

Here’s an old issue with some interesting information, that could maybe help you:

Alternatively, you can use strategy #3 and so have each instance of Theia serve only one user; then the multi-tenancy would be implemented in the “wrapper” layer above. So far this seems to be the popular way to go.

What requirements does Theia’s webserver fulfill (and what it doesn’t)? / What was it built to accomplish?

Theia’s backend first dispatch the frontend (html/js files), and then also provide services over Websockets and RPC protocol for the frontend to use.

You can see the backend as a slave to the frontend, as the IDE actually runs in your browser. The backend has as little state as possible, but I wouldn’t say that it is stateless.

e.g. The backend allows the frontend to ask for disk content, or anything that would exists on the host and that the IDE would need to access.
edit: Another important example: The backend also makes the bridge frontend <–(websocket)–> backend <–(stdio)–> processes.
As stated, the IDE lives in the frontend, but the language servers live on the backend’s host, hence the bridge.

Replacing the backend is possible on paper, but not sure about it being actually viable. We do declare the JSON-RPC “protocol” in files under /src/common/*-protocol.ts, but I wonder if just providing a service answering all of these definitions would be enough to have a different backend (say one written in C++ for instance).

Now about contributing express middlewares, it would certainly allow you to auth the users before accessing the app, but not sure how proper user restriction between the different “sessions” would actually work, as most implementations are written with single tenancy in mind?

I think the simpliest solution is to have one backend instance per user indeed.


I do appreciate you all taking your time to respond.

The github issue link Marc posted does suggest there’s been some experimentation with Option #2 in the community. I’m hoping someone can share their experience with that approach vs #3. seems to be about authentication, not about isolation of a user access on backend to underlying filesystem, OS resources like processes, git and so on. It probably can be done to some extent by rebinding Theia services like FileSystem and restricting access based on user token or something like that. But, for example, any Theia/VS Code extension on backend can use Node.js (or other runtime via child processes) for filesystem access. How you can restrict access via such runtimes, replacing Node.js?

It’s easier to solve the issue of isolated environments outside of Theia (so it works for all runtimes) and then deploy Theia in such env depending on a case, i.e. for soft multi-tenancy it could be ok to deploy in the same env, if users are fine to share os resources and filesystem. For hard multi-tenancy, it’s better to give each user own env.

[Max Hillaert]

So what exactly are the user-experience effects of sharing a backend if language servers are replicated for each user.
I noticed that preferences were changing underneath us when colleagues and I were concurrently accessing the Theia instance. That seems easily fixable by swapping some service in the container I presume, so get it from a
The filesystem is shared, but we are intending to swap the backend service out for a code repo REST service, running in our cloud. Not sure how much we can reuse , and how we pass the authentication token to our new backend file system service, yet, but seems solvable.
Other than this, I couldn’t obviously see anything weird and annoying. Granted we didn’t get much time.

I’m trying to establish what else would change underneath users resulting in bad user experience of sharing same theia backend? You say terminals are shared. Would terminals in one client popup in another client?

Would terminals in one client popup in another client?

It should not.

Generally the primary use case was so far that each user has own backend and shares it only for collaborative work. I.e. we plan to allow seeing all debug sessions and so on. Sounds like you would prefer to avoid such features.

Hi @max-hillaert