One server for 2 Discourse communities?

It is better than DigitalOcean and the likes so yes, it is a good thing.

It was okay, but I have also highlighted the constraints, the sites were really low traffic and low activity, if you expect significant activity on these sites, You need more resources, discourse resource utilisation increases as you receive more activities.

This really boils down to whether you have a need to isolate some sites from others or not. Commercial discourse hosting are usually just large multisite clusters with some special sauce on top to accommodate their billing system etc.

Well, unless you have some advanced configuration in place, all the sites will share the credentials of the parent site. i.e. without some advanced configuration in place, if the parent site is configured for noreply@example.com as its noreply email. It will be used by all the child sites too. You will need some additional setup if you want unique emails per site.

Largely depends on what you classify as “issues”

1 Like

Single app.yml for multisite is doable but I would recommend moving to 2 container install (separate web and data) for a multisite.

You’ll have to persevere through some challenges, change paths in the yml files and then spin them up. Essentially like /var/discourse-a has its own config and /var/discourse-b has its own.

Just to note these are quite technically involved concepts, You really need some experience with discourse and its inner workings to be able to host multisite. If you feel nervous about it, maybe consider a managed hosting for discourse or have someone set it up for you professionally. It’ll significantly reduce your headache over time. Consider posting in Marketplace if you have a budget.

3 Likes

Yes, but that’s why I was saying that over time I can always upgrade to a higher plan with more resources. It was never my plan to stay on that… plan… for a long time. I’m just trying to avoid unnecessary costs when testing the waters, you know?

Can you point out a few reasons why I would want them separated, other than the server resources? Right now, I don’t see a good reason to have them in separate servers, but I’m always willing to learn a few different perspectives on things I don’t know yet.

That’s a very interesting point, that I didn’t know about. So it seems that it is indeed something that has been done and it works. Good to know.

What do you mean by parent site? Wouldn’t each installation be independent? Which one would be considered parent?

I’m a bit confused, because when I look at the app.yaml file, there’s a dedicated part for the brevo email and credentials. You said that I can go the route of having individual app.yaml files per community. So, wouldn’t that mean that each community would have their own Brevo credentials, including the notifications email?

Things that will prevent me from backing up properly, or notification emails not being sent properly, things like that. Again, as a non-expert, and still new to Discourse, there are things that other people might see as an issue, but I don’t see it yet.

Yes, that’s what I was thinking. The only shared thing would be the server itself. Everything else would work as a separate installation, hence the question about the email, above.

I think the most challenging steps for me, were already taken, which was to dive deep into installing Discourse a few months ago. I had zero knowledge about it. I didn’t even know what “docker” meant. At this point, I have a much clearer perspective, while still consider myself a “basic Discourse user” when it comes to self-hosting. And with the help of both this community and ChatGPT/Claude, I’ve been able to learn a bit more and take notes on how things work and are installed. I’m ok with challenges, and let’s be honest: this is really just installing software. It’s not that I’m building a nuclear bomb :laughing: If something goes wrong, delete everything, back to a single installation per server. All good :slight_smile:

As I mentioned, I have my own community installed already, so I believe that the hardest part is already out of the way. I’m good at following instructions and asking questions, so as I try things, I can always pause and do some research, take notes, etc.

My goal now is more about understanding the mechanics of it, the pros and cons, what is possible and what’s not, so I can make some good decisions that I won’t regret later on that will require me to spend too much time fixing things, you know?

So, all this information you guys are sharing today is super valuable, because it’s giving me a good idea of what to think about. Especially when you mentioned that the managed hosting offered by Discourse’s team is a multisite. That really made me see that this is possible. Maybe requires a few more steps, but everything can be done.

Really appreciate your feedback :raising_hands:

3 Likes

You’ll first have to decide whether you want a single multisite or a single server hosting multiple standalone sites. I’ll hold off to answering anything you’ve asked above before you decide on one vs the other. There is a lot to understand, merely installing discourse on a vm does not automatically make you eligible for multisite hassle, for example it took me 3 years to perfect the multisite install experience for myself. Granted the documentation was not very clear on a lot of things and I had to FTFO a lot of things to get it right. And I am using discourse since 2016-17 (almost 9-10 years at this point)

So please take a step back, and rethink what you’re trying to achieve and then we can focus on achieving that.

Once again, be mindful that installing discourse is not the biggest hurdle, there is still a lot to learn and even after 9 years of using and deploying discourse, I still consider myself as learning new things every single day.

2 Likes

This was always my goal. I don’t see any advantage, for what I’m building, to have a single multisite. My goal is to just save costs by using one server with independent installations.

And I understand what you mean about things being complex. That’s why I was saying that even though I was able to install it and now being able to understand some of the concepts, I consider myself a basic user when it comes to installation.

After making music for close to 35 years, I’m still learning new things every day, so that’s all good. I’m good with learning every day, and I never expect not to :slight_smile: That’s why I’m here in this community. To learn new things with you guys.

3 Likes

So If you just want to have multiple discourse sites on the same server, without them sharing the code or container, here is what you can try:

Read the app.yml carefully and understand the mounts section, You’ll need different, predictable mounts for each site, at the minimum You’ll have to edit these directories by hand.

The only time I did this (and I think I did it the most un-ergonomic way) I cloned discourse code in two different directories, which may not be necessary, but I haven’t tried it so I’m not sure.

In each directory I ran ./discourse-setup with some flags to skip connectivity check and rebuilding. That gave me baseline app.yml files. Next step was to edit both files by hand, I changed the mounts, commented the section that exposed ports and added the web.socketed template to let my external nginx take care of ssl and internal forwards.

Then it was as simple as running ./launcher rebuild app in each directory.

Honestly I was not a huge fan of this setup so I gave up after a few months of playing around. But it shows that what you are trying to do is indeed doable, just that you have some figuring out to do.

you might also want to lower the number of workers etc. to let all sites have a fair chance at using the resources, but that’s a thought experiment for when you have the initial ground work laid.

3 Likes

Thank you for the detailed info!
I’m still considering the best option and even if I end up using this option, I still need to figure some stuff out.

You mean this? Because when I searched for the word “mount”, nothing came up, but I assumed it was something related to the volumes?

If so, then that’s where I create different paths like
var/discourse/shared/website1
var/discourse/shared/website2
etc
?

So basically you performed a normal installation in one of the paths, for example:
var/discourse/shared/website1
then copied those files to
var/discourse/shared/website2
?

If that’s the case, why run ./discourse-setup? Wouldn’t that overwrite files?
Wouldn’t it be better to just perform normal installations in both paths? Like two complete separate installations? For someone like me, especially when you mention the “flags” and all that, that’s more things I would have to worry about, and maybe a normal installation would be better, then manually editing the app.yaml files on each path?

EDIT: Never mind. I did some research and I understand what you mean by “clone” in this context. You cloned the repository files. I thought you were saying you installed everything in one “path” and then copied those files to another “path”.

Do you already have a Discourse instance running? You’ve been on this forum for awhile. Are you trying to get a second instance running on a server that has one instance already running on it?

Best way to learn is to have a go. Set up a cheap VPS and try. If you aren’t running an instance already, just get a regular self hosted supported install running and learn you way around. You will have no real visitors and no reason to have to save anything. You can just trash the install and try over and over until you have it down. If you set up two or even three instances all running on a single VPS and they are all getting (virtually) zero traffic I’d bet the cheapest VPS out there would probably run it.

If you get it going, post a tutorial for the rest of us to learn from!

1 Like

Yes, I do. I want to install additional instances.

Since this installation is still new and no users signed up, there’s no issues with that. I will back it up first and try everything on this server. There’s no real risk yet.

Will definitely do that. Hopefully it can help others.

@itsbhanusharma I was asking some more questions to both ChatGPT and Claude, because I was thinking I would like to rename the current instance’s path from “discourse” to the name of the website like “website-name” and both pointed out a few good things. One of them is that since each installation requires 2GB of RAM, if I install 5 total, for example, I would need 10GB, right?

If that’s the case, then this plan would probably be better:

CX43Intel ® / AMD
8 VCPU
16 GB RAM
160 GB NVMe SSD
20 TB Traffic incl.
€ 9.49 / month

Still a very good price for 5 instances, instead of $5 x 5 = $25.

What are you thought regarding the need to have 2GB per instance? Is that accurate in this scenario? Do you think this plan I shared would be a good fit?

Please don’t!

I have multiple incidents of customers causing more harm than good to their discourse sites because they blindly followed chatgpt advice.

This is a bit more nuanced and the kind of thing that’s not as straightforward as putting 2+2 together. And this is largely the reason why going multisite route is a better idea.

once more, I would say stop, take a break, step back a bit and rethink what your needs are. There are good resources available here on meta and the only ai bot I would trust for discourse advice is https://ask.discourse.org

5 Likes

I agree, but check the information by reading the sources the bot provides. This way you’ll also ensure that it didn’t make the links up (it happens!).

6 Likes

That’s a bit extreme… No one is blindly following ChatGPT advice (at least not me), that’s why I’m having this conversation with all of you here. :slight_smile:

I use those tools as tools. They mention things that allow me to see other points of view, then I do research online, or ask questions here in the community. Along the way, they also show me other concepts not strictly related to Discourse, which is also a good thing. The tools are only as good as the person using them.

And I’ve done a lot using tips from ChatGPT and Claude. We can’t dismiss everything they say… blindly :wink:

Do you mind sharing a bit more about this? If the info ChatGPT / Claude is inaccurate, maybe you can enlighten me, as well as others who may read this in the future?

Not for my case, for a few reasons (and unless I’m missing something, here they are):

  • I wanna be able to make custom changes, if needed, to each instance, without affecting the others. Not that I will, but I wanna know I can if I want to.
  • In a multisite, if the parent crashes, they all crash, correct?
  • I just like having things independent. It bothers me the idea that 4-5 instances are all connected to something that can fail at some point.

Again, maybe my perspective on how a multisite works is wrong, but from what I understand, it doesn’t seem like a good fit for me.

At the moment, my needs are:

  • Build all communities I need
  • Spend as little money as possible, because I don’t know if those decisions of building those communities are good in the long run or not (been there done that, more than I would like to, spending too much money on “experiments”).

I didn’t know about this tool, so thanks for sharing. Bookmarked it.
I have to say, though, that we shouldn’t blindly (sorry, I had to do it again haha) discard everything ChatGPT or Claude say, even if the Discourse AI bot is more knowledgable, which I believe it is with so much content available on the subject. I use ChatGPT and Claude as well, because sometimes certain things are not just related to Discourse and I always like to learn a bit more about other things.

Regardless, I appreciate your feedback and time. It already helped me a lot.

3 Likes

From what I can make out of this is that You’re knees deep into overthinking your setup.

Fundamentally, You shouldn’t be pursuing the 1000 brilliant new community ideas you have all at once by spinning up as many new discourse (and by extension any other software) instances.

community building is an iterative process and needs focus, if you split your focus between more than one community at a time, You will end up with more on your plate than you can handle.

My suggestions were a food for thought, as I mentioned earlier when I did these experiments these were just that, a bunch of friends doing things because we can.

there is a reason (or two) why these are not common practices? These come with a significant maintenance and management overhead that will cause a lot of headaches and sleepless nights down the line, you have been warned.

given your objectives, I would rest my case with this statement: what you’re trying to achieve is not impossible, but today is not the day to achieve everything that’s possible. Focus on what you have at hand, build your first community, the rest can follow on when the time comes.

As for learning by experimenting, if cutting costs is your primary goal, multisite is the way to go, with all the compromises it presents.

3 Likes

Thanks again for the feedback.

I understand what you mean, and trust me, if I were to build all the communities I needed for everything I’m involved in, we wouldn’t be talking about 4-5, but more like 15.

I was able to end up with 3 that seem to be really important and should be built now. At this point, all 3 need their own space to give users a place to discuss their experiences with products and services I have or am building.

As I said, multisite where they all depend on each other, doesn’t feel right for me and to be honest, the headaches and sleepless nights you mention, are probably more prone to exist in that case (at least for me and my experience in other areas where things were dependent of each other), in a multisite configuration. I don’t know… it’s one of those cases where my gut says “don’t do it” and I’m trusting it. Maybe I’m wrong and I will be proven wrong along the way, but I’m trusting my gut first.

Anyway, thanks again for your time and help. Appreciate it :raising_hands:

2 Likes

Then I’ll wish you luck, sir! All the best for your new adventure.

1 Like

Hello friends and happy new year!

This is a timely topic for me as I am just in the process of adjusting my own setup to save some time and money. I have three small private sites that all get very little traffic but they are all important to me. I also want to be able to spin up more sites to test out new ideas. So multisite I think will be of interest to me.

That said, I just moved one of my sites from digitalocean to hetzner, and was surprised at the cost savings. It’s just $3.49/month for their smallest cx23 offering, which happens to be just about ideal for a single small site. I was paying $15.60 at digitalocean for a similar configuration.

Having read this and other related topics, my main sticking point with multisite is that I want to use direct delivery email for all of my sites, using the site’s domain name as the email domain name so it is easily recognized and trusted by site members. The instructions for setting that up don’t seem to be very straightforward.

So at the minute I am concluding that it might just be best for me to just stick with standalone sites and move them all over to hetzner. I’ll save money but not so much time given how much time twiddling thumbs is involved in setting up standalone sites.

3 Likes

Your can do that but only if they all use the same smtp credentials.

Since your new hetzner is so much cheaper you’ll still come out ahead with three sites than just one at the old rate.

I wouldn’t recommend multisite with just 1gb of ram, and it is more trouble to get it configured, though the new hostname aliases env setting solves one of the biggest issues.

2 Likes

The cx23 has 4gb ram. I’m moving my other two sites to their separate cx23 servers so we’ll see how this plays out, but my feeling is it will be a-ok.

I am confused by this as mail-receiver is just about receiving email and there are no smtp credentials.

Are you talking about incoming or outgoing email? With outgoing email does not each site have its own smtp credentials configured in app.yml?

3 Likes

No. Mail receiver is separate. If you’re using multisite, then there is just one YML file and that’s where the SMTP sending credentials are set. If you’re using mail receiver, you’ve got a different issue, as you need a mail receiver for each site (at least, that’s the only solution I’ve found.

3 Likes