The discussion revolves around the best approach for test and production instances of Discourse. PackElend is considering two options: using the same server behind a reverse proxy or multisite configuration. However, pfaffman advises against multisite for a test server, as it can cause issues with plugin upgrades. Instead, pfaffman recommends using a separate server or multiple discourse instances on the same server.
For backup and migration purposes, pfaffman suggests using an S3 backup bucket, which can be more cost-effective than DigitalOcean’s solution. PackElend inquires about automatically pushing backups to S3 from DigitalOcean, and pfaffman suggests using a shared backup volume.
sam recommends minimizing fuss and complication by getting two separate droplets, but PackElend shares their experience of encountering issues with a single droplet and email verification, ultimately deciding to start from scratch with a mailgun account.
Hello,
I’m about to create a discourse instance on a Digital Ocean cloud server as per the guide.
For the beginning, we are using discourse in a slim/default configuration but extending step by step. For familiarizing we would like to use the test instance occasionally.
What approach is smarter doing so
Another goal of this exercise is to familiarising with:
backup
relocating
migrating content
migrating settings
migrating single discussions
a use case is that we discuss something in the prod. instance, move the forum content (entire database), test it on the test instance and move the discussion back to podc. by single discussion export/import and copying the changed settings as may we test and approved a plugin.
Multisite does no good for a test server. If you upgrade to test if there’s a broken plugin, both sites are hosed.
Same server behind reverse proxy is OK, but lots of trouble; it it’s not hard for you, then one of the “multiple discourse instances” solutions could be good for you. The easiest is a separate server and have them both share an S3 backup bucket so that it’s easy to restore data from the production site to the dev site to see how things look. That’ll also convince you that you can crank up a new server with the most recent backup.