Self hosting Excalidraw - Umbrella issue

So I’m opening the self-hosting thread.

Current architecture

First an architecture overview. Excalidraw is made of three main parts at the moment.

• The client, what you see when you visit excalidraw.com which is this repo
• The sockets server, which powers the collaboration feature, it’s this repo, a Node.js server running socket.io
• The store server, which powers the sharing feature, it’s this repo, a Python server running on GAE with some kind of a DB

At the moment, we are planning on publishing a Docker image of the Excalidraw client only. That means that people will be able to self-host the client but they won’t be able to use sharing/collaboration features because the client will still have to talk to our cloud-hosted backend servers on which there are CORS restrictions.

For now

For the image that we are planning on publishing soon (in the next few days), we have already stripped out the google tag manager but I see the visible sharing/collaboration icons as an issue. People will be frustrated by not understanding why they don’t work.

I suggest we strip them out too on the Docker image only. Temporarily until we have a plan for the rest two services. It’s the best UX we can offer IMO.

For the future

Moving forward we would like people to be able to self-host a full-fledged Excalidraw environment. My suggestion is to publish a Docker image for each of the two backend servers so people can self-host these as well. Having separate images promotes better scalability and also follows the one service/per container practice. They will be easier to maintain and also people can opt-out of a feature if they don’t want to support, e.g. they only want collaboration features but not the storing feature.

Then we will be able to point the client image to specific URLs and it will simply work.

For that to work, the socket server will be much simpler as it has no dependencies. On the other hand, the storing server has a DB dependency which we will have to consider. Ideally, it should be something easy to use and maintain, like a postgres or a redis instance.

We could consider how the future of that service looks like, but for now, we can focus on what it actually needs.

Let me know your thoughts and we can start planning right away.

I should also mention the embedded Excalidraw instance we are working on that would also benefit from being able to connect to a self-host backend server but also have a better UX without icons that don’t work.

Todo

• Dockerize main frontend client
• Dockerize colab server
• Dockerize storage server

[Kiliandeca]

Hi, if someone else is interested I recently worked on self-hosting Excalidraw as a side project and created 2 repositories and Docker images:

• (GitLab) kiliandeca/excalidraw-fork: A fork of Excalidraw react app which supports configuration as runtime environment variable meaning you can use the docker image and change your config without rebuilding the project. I also made some changes to support using an alternative HTTP backend storage server instead of Firebase to store images and collab scenes.
• (GitLab) kiliandeca/excalidraw-storage-backend: Similar to excalidraw-json you can store exported scenes. You can use it with the database of your choice (in memory, redis, mongo, postgres and mysql). It can also be used with my front-end fork to replace Firebase for images and collab scenes.

You can use them with the official excalidraw-room image, I made an example docker-compose file: examples/docker-compose.yml

[kjellkvinge]

just to pitch in an alternative approach. I have experimented with this, and created a bundle - single binary - which will work for selfhosting (on mac/win/linux/rasperry pi) on local network. (currently only link sharing is implemented)

https://github.com/kjellkvinge/excalidrawserver

Is this interesting? It was a fun hack 😃

regards