Making PopSpace a standalone deploy

[a-type]

We'd love to evolve PopSpace from a stack which is dependent on various external services to a self-contained, Docker-deployable product which gives you the full experience with no extra setup or bills besides your own hosting.

To do that, we need to move the stack dependencies into a group of deployed containers which all work together, probably using Docker Compose.

Here's the list of things we'd need to internalize:

• Media servers (LiveKit)
• File storage (currently, S3)
• Database (currently, Postgres)

For media services, LiveKit can already be deployed as a solo container, so this should be pretty straightforward! Since we recently released a new version which can connect to LiveKit for media, it should be a matter of including a LiveKit container as part of a Compose deployment and correctly configuring the relevant environment variables.

For file storage, we can just store things on the mounted volume. There's not much need for a robust CDN infrastructure now that PopSpace is a single-team standalone oriented product. The file-upload project was designed to be abstract so that we could swap in different file storage methods like this, but unfortunately it's not used for user file uploads (only wallpapers), so there's some extra work to do to unify the file handling logic in the app before we can swap out the S3 piece.

For the database, we use Prisma - so we could potentially move to SQLite, also on-volume. While SQLite is lightweight, again, scaling is not such a concern for this new phase of the PopSpace product. As long as our existing SQL is compatible with SQLite, it could be an easy drop-in replacement, just a matter of setting up the database and migrating as part of the Docker image.

While we're hoping to get all this done, full disclosure, we're quite busy building PopStage these days, so it may take some time. Community input and contributions are welcome!

[dillfrescott]

I would love to see this happen one day! Sounds awesome! <3

[vbbjandrade]

Hey, just wondering if there has been any progress on this. From what I have seen there is a "sqlite" branch with some of the adjustments mentioned.
My organization has been looking for a solution like PopSpace for a while, but the S3 requirement is keeping us from using it. Thanks!

[a-type]

Oh yeah, I did let that work fall by the side, thanks for reminding me.

That branch is basically ready to go, we did some testing internally. Maybe I'll go ahead and merge it. It covers both a local SQLite db and on-volume file storage.

[a-type]

Ok, I don't have much time at the moment, but here's my checklist...

• Update README with the new local file / SQLite changes
• Build and push the new container image

[a-type]

I should have known better than to make a checklist for myself while on parental leave!

But I did finally get around to updating the README and pushing that new image. The new image should no longer require S3 or Postgres, all you need to do is provide LiveKit or Twilio credentials and expose the necessary ports.

This makes Popspace mostly standalone. In theory we could also support direct WebRTC media and remove the external media service requirement! So I'll leave this issue open, although truthfully I don't think I have time to pursue that in the foreseeable future, and my experience with WebRTC for larger groups indicates it would not scale past like 5 users.

[a-type]

oops, I forgot the original plan was just to run LiveKit locally, too. that might still be feasible! Still, LiveKit's cloud offering is really nice and has a pretty good free tier. I'd recommend checking it out for now!