Feat js peer dockerfile

[dhuseby]

This adds a Dockerfile for building a Docker image of the js-peer for deployment.

[2color]

The frontend is built into an immutable static site which we deploy to IPFS with GitHub Actions. IPFS gives you all the nice redundancy features by literally just pinning the CID we publish.

Dockerising a static site is an overkill and unnecessary in my view.

[dhuseby]

@2color, so what's the standard procedure for deploying this on a VPS somewhere if it isn't with a Dockerfile?

[dhuseby]

I've been able to get this into both a standalone docker compose stack and a k8s cluster easily using this Dockerfile. I would like to do it the "correct" way so that I can have multiple instances in a cluster that spans the globe and has a single URL entry point. https://universal-connectivity.bootstrap.farm is the cluster I built using this Dockerfile. There are nodes in the US and EU.

[2color]

@2color, so what's the standard procedure for deploying this on a VPS somewhere if it isn't with a Dockerfile?

There are many, because it's just a static web application.

If you want to use Docker, you can use the official nginx or Caddy images

• https://hub.docker.com/_/caddy
• https://www.docker.com/blog/how-to-use-the-official-nginx-docker-image/

Or even better, deploy an IPFS Node and pin the latest CID we publish from this repo.

The point I made is different: deploying the frontend to a different URL doesn't really bring much benefit to this app. If the main deployment fails because of Fleek infra problems, users can always rely on the CID we publish (via the new build-and-deploy workflow) to retrieve it via their IPFS node or via an IPFS gateway.

Another approach is to use one of the many free static hosting services, like Cloudflare pages, GH Pages, netlify, and Vercel to name a few. Static hosting is commodified and

---

There's a lot more benefit to be had from having more than one "bootstrapper" to avoid overwhelming the one that is hardcoded and is a central point of failure. That means that if the bootstrapper is down, you can't find and connect to other peers.

[dhuseby]

@2color all of what you said makes sense. I think the difficulty now is that none of the deployment methods are documented well. At least, I couldn't find the information when I looked. As I understand it, this application is designed to run exclusively in the browser so deploying it to a VPS somewhere doesn't really help the network out since there would have to be browsers running it somewhere.

I guess the thing I could do that would really help out is to deploy a stable IPFS nodes to my cluster of VPS servers and set up Nginx servers that act as IPFS gateways.

Should we create a "contrib" folder and add the Dockerfile there and then update the README.md file for the js-peer to explain how this is deployed and that it's designed to run in the browser and relies on external bootstrappers that are hard coded to bootstrap into the network.

Is there a way to deploy this as a node server? That's something I could deploy on my cluster of VPS's. I haven't looked into it.