To avoid constant removal of the sqlite database, I created a fly.io volume for it.
I have not been able to test it though, so once this is merged we might have surprises. Also worth mentioning that once this is deployed, the currently db will be nuked. What we could do is do a get call on eahc of the ids you know exist in the current db (/loadConfig, and loadStyles), save them somewhere in a text file, given they're just json and then run saveConfig again once the new db is deployed.
With volumes, the db will not be nuked any more. However, it won't be easy to access like a file system, only via the app. If we want this, we might want to switch to an online solution like firebase; but keepingin mind it will require more setup for customers who might want to run this locally.
To avoid constant removal of the sqlite database, I created a fly.io volume for it.
I have not been able to test it though, so once this is merged we might have surprises. Also worth mentioning that once this is deployed, the currently db will be nuked. What we could do is do a get call on eahc of the ids you know exist in the current db (
/loadConfig, andloadStyles), save them somewhere in a text file, given they're just json and then runsaveConfigagain once the new db is deployed.With volumes, the db will not be nuked any more. However, it won't be easy to access like a file system, only via the app. If we want this, we might want to switch to an online solution like firebase; but keepingin mind it will require more setup for customers who might want to run this locally.