benhsm
commented
2 months ago We need to make some adjustments to the application to be able to be able to do mutations properly using clustered LiteFS. This should be fairly simple - I think we just need to ensure that anywhere that there's a database mutation, the backend uses the litefs-js middleware to ensure that the litefs instance on the server has the primary role (this seems to be what later versions of the epic stack do): https://github.com/epicweb-dev/epic-stack/blob/ae5f3055c93f9fda0b30812dd5ca54e259dd1827/app/routes/_auth%zz2B/auth.%24provider.callback.ts#L33
LiteFS Cloud is a separate fly.io service which existed to provide managed backups and point-in-time restores for LiteFS clusters running on fly.io or elsewhere, but that's a separate issue. As it happens, LiteFS Cloud is being sunsetted, but there are alternatives if we want to implement better disaster recovery here.
https://fly.io/docs/litefs/
See #65 and #77 - both of these issues have a root cause of having LiteFS local in our Machine deployments, this makes one node read-only and creates havoc. For now we only run on a single node which is not ideal.
We need you to create a LifeFS cloud for EVS, this should support both our Prod and Staging EVS deployments either separately or multi-tenant on the same deployment so long as you ensure security (one user from one should not be able to access the other and there are different login credentials for access to the DB from both deployments)