EDIT after resolved: This happened when I open the second Discourse instance, not when I start the server. I have two Discourse directories. I followed the following guide to install it.: [image] Install Discourse on Ubuntu or Debian for Development Developer Guides warning This guide covers installation instructions in a development environment. For a production guide see: Install Discourse in production with the official supported instructions So you want to set up Discourse on Ubuntu or Debian to hack on and develop with? We’ll assume that you work locally and don’t have Ruby/Rails/Postgres/Redis installed on your Ubuntu or Debian system. Let’s begin! Requirements We suggest having at least 4 GB RAM and 2 CPU cores. Current compatibility: O… So, the first one, say, cd ~/discourse bundle exec rails server --binding=0.0.0.0 is running okay, I can sign in, create my topics, etc. Then I run another Dicsourse instance after changing the config/database.yml to use different ‘database’ name and run it on different port: cd ~/discourse2 bundle exec rails server -p --binding=0.0.0.0 It does create those databases additionally. And it runs, sure. But when I visit the first instance that’s been running and refresh, I’m signed out from it. I can log in into the second instance, and start my thing there. And when I log into my first instance, it signs me out from the second instance. And now I’ve tried running Discourse on Docker, it runs, but when I visit localhost and I get the “Register page”, I’m logged out from the running Discourse. I’m not trying to use one account for two instances. How do I keep each account signed-in on its own Discourse instance? (Account ‘foo’ on ‘discourse’ and account ‘bar’ on ‘discourse-2’ instance)

They need to have different host names. Otherwise they try to use the same cookies.

Are these meant to be production instances, or for development purposes?

Correct me if I’m wrong, I’m thinking of Discourse running from a Docker container to be the production instances (or purpose?) and the instances that run from the discourse/discourse repo to be development instance. I tried running two development instances first, then failed (visiting or starting one instance logs me out from currently running one, but I can log in again which would log me out from the newly started/visited instance if I’m already logged in). Then tried with an instance running in development instance, and another from Docker, and the same thing happens. So, I need at least one ‘development purpose’ Discourse to run. And I need one instance for my own personal use. Sure, I could host the personal one of ‘production instance’ on a cloud service, but that would cost me (little amount of) money. Even then, I’m just confused why this is the case when I’m expecting it to just work.

Oh my god. Thank you. I was able to have each account on each instance not interfere each other’s login by using different browser, or different ‘account bounded chrome instance’ (or something).

The following seem to work Using different ‘chrome’ instances (such as the guest window) Using 127.0.0.1 instead of localhost What are some other ways to avoid two servers serving clients with same cookie. Could using ‘alias’ be an example?

Multiple instances. Visiting the second instance signs out the logged in account on the running instance

Development

Stephen (Stephen) March 25, 2019, 7:11am 7

Just use two hostfile entries. They can share the same IP, and won’t suffer from cookie collision.

Topic		Replies	Views
Multiple Discourses, multiple containers, one server Self-hosting	10	10844	September 21, 2021
Odd behavior between different environments Self-hosting	5	914	June 4, 2017
Two Discourses - in containers - interfere with each other? Self-hosting unsupported-install , docker	4	651	August 29, 2023
Multiple subdomain instances of Discourse at the same domain? Self-hosting hosting	7	2811	June 23, 2021
Can I log into multiple instances of discourse simultaneously? Product Support	36	6318	July 22, 2017

Multiple instances. Visiting the second instance signs out the logged in account on the running instance

Related topics