Hello all,
If you are building/maintaining Glide projects for a Client, I’d be curious to understand the backup methods used for apps in production, especially on the data part. Do you automate the process of exporting table data through any means, or do it manually and store it in a cloud storage? Or, taking app backup is the option you follow?
If you can share what has worked, where to be cautious, any best practices that you follow, it’ll be awfully helpful. Thanks !
We usually just duplicate the app periodically, or when we deploy a big feature, but obviously that can’t be automated.
If you want automation, I think the best option is using Make, then query all rows from all relevant tables and export them to CSV files.
Time-based actions might come soon though, and it will change the game.
I think Thinh’s answer is currently the most realistic. I do the same. On occasion, either periodically or prior to major updates, I duplicate the app manually.
Thanks @ThinhDinh and @nathanaelb . Let me follow your footsteps then!
Hi, just found this thread, very good information for a beginner like myself. When you say you “duplicate” the app before doing major updates are you then keeping the data or copying the data?
Could someone explain the workflow a bit more detailed on how you work with apps in production, backups, when releasing new features etc.?
This would be very helpful, thank you!
I duplicate the app/project and select the option where the data is duplicated as well. I don’t feel the need to do a data export on top of that, but that would be even better.
I usually create 3 folders in the team:
I might adapt the names of these folders slightly.
I use emojis and the words “Live” and “Published” because another admin or member of the team might not be familiar with the usual terminology. “Live” is clear in any language and “Published” is the same term used by Glide when publishing an app. In fact the various development environments are somewhat new to me too: Development → Staging → Testing → Production.
In my setup I put Development-Staging-Testing together into “Develop & Test”. And I added another folder for backups. This setup works for me: it’s simple enough and I’ve gotten used to it.
At the end of a session of work usually on an app in the “Develop & Test” folder, I’ll duplicate the app, prepend the date and time to it (2024-10-07 10:00 App Name) and move the duplicate to the backups folder. I then also rename the app in the “Develop & Test” folder with again the current date and time.
If the changes to the app are minor and I know exactly what I’m doing, I might make changes to the (live and published) app in production directly.
When an app in development becomes much more advanced that the (live) app in production and the time has come, I will copy the production URL of the app in production, unpublish the app in production, publish the most advanced app in development and paste the production URL, and move this app in development to the production folder since it is now the published version of the app. In short, this is a URL swap. I have avoided this in past but more recently have been doing this a lot, and it works fine.
Basically for a given project/app, I only ever have one published version in the live in production folder.
The one annoying part with this approach is that if the app in production (live published) was also set up with a domain name, this has to be set up anew.
Curious to hear what others do.
Thank you very much for your detailed explanation. My only question with using this approach would be when duplicating the app and copying the data as well. The Glide docs says:
Copying the data is helpful for:
Creating a backup (or snapshot) of the current app and its data
Creating a new app that is similar to the original but not linked in any way
Wouldn’t that mean that if you spent time on adding new features to an app in your Development folder while the users are using the version in the Production folder, then the data in your Development version would not be up to date when it is time to move it to Production?
Hope my question makes sense 
Yes, if you create a duplicate app as well as duplicate the data…and you make updates to the duplicate…it’s much harder to integrate back into a live environment because the database connected to the duplicate app is not in sync with the live app, and swapping tables is not easy or fun.
If you create a duplicate of the app, but do not duplicate the data, then the database is shared between both apps, and you need to be much more careful. Basic columns and data will still sync between both apps, but computed columns will not. You just need to be careful if you start to mess around with any basic columns in the duplicate app that are used by the live app.
Yes, correct.
If you are doing it that way (which I do), then you need to migrate the production data to the new version of the App when you swap it out. Possible, but extremely fiddly.
Yes very good point. Jeff and Darren have already answered.
I suppose it depends on what type of backup you’re looking for: an absolute backup that has nothing to do with any others versions, or a backup that in a way is backup of an app in staging.
I might start doing both, I like the idea.
EDIT: In the initial phase of development before the app is in production, I think it can make sense to duplicate with separate tables. That’s what I do, because I’m always worried that I’ll break something major and I want to be able to revert back to a clean and stable backup. When the app is in production and being used by users, then I think it makes sense, like Jeff and Daren pointed out, to duplicate with linked tables. The paranoid in me will still do a duplicate with separate tables on top just in case 