Cloudron Forum

Thanks for clarifying, James. We’ll stick with PostgreSQL packaged inside our Django app. That setup has passed our tests for separate migration and runtime roles, backup and restore, cloning, and a PostgreSQL version update.

Thanks, James! We have meanwhile tested PostgreSQL packaged directly inside our Django app, including separate migration/runtime roles, full Cloudron backup/restore, cloning and a PostgreSQL version update. We’ll continue with this approach for now.
Could you also confirm whether the shared PostgreSQL addon currently has a supported lifecycle for custom roles, or whether that remains outside its supported scope?

Hello Cloudron team,

We are developing a custom Django app and need separate PostgreSQL
migration and runtime identities. The runtime must not own tables
or be able to alter/delete protected audit records.

Is there an officially supported way to provision and preserve
these identities with the shared PostgreSQL addon, including
updates, cloning and full restore onto a fresh server?

We found earlier forum replies indicating that custom roles are
not managed or preserved by the addon. Is that still the case
on Cloudron 10.1.5?

As an alternative, we have successfully tested a package-internal
PostgreSQL instance using persistentDirs, backupCommand and
restoreCommand, including full Cloudron backup/clone and same-app
restore with synthetic data.

For this requirement, which approach does Cloudron recommend:
the shared addon, or a package-internal PostgreSQL instance?
Are there lifecycle limitations we should account for?

Thank you,
Cyril Brunner
L’ALTRO Design