3 ms·

Wholeheartedly agree. On-prem is still a major market to play in and have worked on many consulting engagements architecting software that plays nicely. Just cu

Wholeheartedly agree. On-prem is still a major market to play in and have worked on many consulting engagements architecting software that plays nicely. Just curious - how do you guys deploy Flagsmith on-prem? I'm still trying to find a nice deployment pattern that aligns well with both client and vendor.

dabeeeenster 1y ago
99% of the time Kubernetes. Just hand over enterprise docker images and helm charts. If that's what you were asking?
- xet7 1y ago
  WeKan https://wekan.github.io https://wekan.github.io has Helm Chart here: https://artifacthub.io/packages/helm/wekan/wekan https://artifacthub.io/packages/helm/wekan/wekan
PunchyHamster 1y ago
From one deploying stuff on prem: Absolute best scenario is single binary with embedded static files (Go is very good at that) that just takes config and/or CLI options (preferably both if it isn't too complex of a config) and works. Or static file that just needs to be pointed at database with certain version It can be easily run on VM, it can be easily made with container, it can be easily made into package, or ran in cloud with cloud DB service. All those options are a plus, but the fact it is a single binary makes it easier to make a package or container out of it and deliver that to customers. Second best is .deb package that deploys a single service or a container that just exposes a port and that's it. DB-wise there is a temptation to provide a bunch of containers that have all of app's dependencies (DB etc.) but that's a LOT of work on both side. On supplier side you have ton of stuff you need to take care of, providing method to do consistent backups, caring about log rotation, handling service restarts if something fails etc. and lastly procedures to recover it from the backup And on client side they can't just do same database backup they do for every single other database they know, they have to take app's custom way of backing up and integrate it, or just "copy whole container and hope for best". It can be worth it, if your setup is complex enough that asking client to install those dependencies would be a big obstacle (and especially if you need to use different versions than available under Debian/Ubuntu stable), but if you are just deploying container with app and plain PostgreSQL db without using anything special that would need latest version, just let user ship their own DB. Also supporting "small" deployment with just SQLite backend is great for demoing stuff to management
- airstrike 1y ago
  Thank you for this
- rollcat 1y ago
  How do you feel about SQLite, especially re: backup/restore? Do you just copy the live DB+WAL around, do you bring the service down first, perhaps ZFS snapshots, any horror stories?
  - xet7 1y ago
    SQLite streaming backups: https://litestream.io https://litestream.io
- xet7 1y ago
  Maybe Kanboard that has SQLite support, packaged with FrankenPHP ? https://frankenphp.dev https://frankenphp.dev

dabeeeenster 1y ago

99% of the time Kubernetes. Just hand over enterprise docker images and helm charts. If that's what you were asking?

xet7 1y ago
WeKan https://wekan.github.io https://wekan.github.io has Helm Chart here: https://artifacthub.io/packages/helm/wekan/wekan https://artifacthub.io/packages/helm/wekan/wekan

PunchyHamster 1y ago

From one deploying stuff on prem: Absolute best scenario is single binary with embedded static files (Go is very good at that) that just takes config and/or CLI options (preferably both if it isn't too complex of a config) and works. Or static file that just needs to be pointed at database with certain version It can be easily run on VM, it can be easily made with container, it can be easily made into package, or ran in cloud with cloud DB service. All those options are a plus, but the fact it is a single binary makes it easier to make a package or container out of it and deliver that to customers. Second best is .deb package that deploys a single service or a container that just exposes a port and that's it. DB-wise there is a temptation to provide a bunch of containers that have all of app's dependencies (DB etc.) but that's a LOT of work on both side. On supplier side you have ton of stuff you need to take care of, providing method to do consistent backups, caring about log rotation, handling service restarts if something fails etc. and lastly procedures to recover it from the backup And on client side they can't just do same database backup they do for every single other database they know, they have to take app's custom way of backing up and integrate it, or just "copy whole container and hope for best". It can be worth it, if your setup is complex enough that asking client to install those dependencies would be a big obstacle (and especially if you need to use different versions than available under Debian/Ubuntu stable), but if you are just deploying container with app and plain PostgreSQL db without using anything special that would need latest version, just let user ship their own DB. Also supporting "small" deployment with just SQLite backend is great for demoing stuff to management

airstrike 1y ago
Thank you for this
rollcat 1y ago
How do you feel about SQLite, especially re: backup/restore? Do you just copy the live DB+WAL around, do you bring the service down first, perhaps ZFS snapshots, any horror stories?
- xet7 1y ago
  SQLite streaming backups: https://litestream.io https://litestream.io
xet7 1y ago
Maybe Kanboard that has SQLite support, packaged with FrankenPHP ? https://frankenphp.dev https://frankenphp.dev