3.6 KiB
uBrowserSync
The uncomplicated browser sync server is an implementation of the xbrowsersync server API with no external dependencies.
Being written in Go, the server is a standalone statically linked binary; it uses the local filesystem as the datastore by default and can be built for any operating system and hardware platform supported by the Go compiler, making it ideal for resource constrained self-hosting scenarios.
Why
xBrowserSync is a great tool for privacy minded people. The problem with the official server code is about the software stack. It's written in NodeJS and requires MongoDB for storing data. I don't use NodeJS or MongoDB for anything else on my VPS so adding a self-hosted xBrowserSync API server would pull in a lot of code and require a lot of additional resources.
The xBrowserSync API is simple enough to make writing a new server an almost trivial exercise. This was the perfect opportunity for me to improve my Go programming skills. I'm still very far from being an expert Go developer but it was worth my time.
How
Building
You can get prebuilt binaries for a number of platforms from the gitlab repository in the "Download artifacts" section. To build from source, just run:
go install ./cmd/ubsserver
It is also possible to build a very basic Docker container image by running:
docker build -t ubsserver -f docker/ubsserver/Dockerfile .
Running
To run the binary you just built:
~/go/bin/ubsserver
It will start the API server listening on port 8090 and using the data directory under $PWD as the datastore.
You can change the listening address using the -listen flag (e.g.: -listen :9999 will listen on port 9999 on all
addresses).
Similarly, you can change the datastore using the -store flag. The store is defined in the format
driver_name:driver_args where driver_name is the name of the store driver while driver_args contains
driver-specific settings.
Currently, only two drivers are implemented:
- mem: a volatile RAM-backed datastore only useful for testing and debugging. It does not take any arguments.
- fs: the default driver: it stores sync data in json files in the directory specified as the argument (default is
data)
If you built the container image, you can run the containerised version:
docker run -it --rm -v /tmp/data:/data -p 8888:8090 localhost/ubsserver
You can replace /tmp/data with the name of the directory where you want to store sync data and 8888 with the port
where you want to expose the API service.
Roadmap
There are a few missing features that I would like to add.
Hig priority:
- Enforce storage limit: it's missing in the current implementation, but it must be implemented to prevent abuse
Nice to have:
- Rate limiting: currently it can be enforced by a reverse proxy in front of the API server but would be nice to have it as part of the server itself
- Front page: serving a static HTML page on
/, perhaps with some simple JS to show the service status, should be fairly straightforward and would improve the end user experience. The main blocker here is my lack of design skills to craft a half decent looking front page - Migration tool: a tool able to pull your current sync from a server and push it to a different one might come handy; the main hurdle is that it would require decrypting the payload and re-encrypting it because the sync ID is used as the IV in the AES-GCM encryption process
License
The code is released under the "Unlicense" public domain license. See UNLICENSE for more details.