Is there a guide for scaling flarum to multiple instances?

acpf

I've been testing flarum and I managed to host it in a docker-compose deployment, 1 container for flarum and 1 container for the database.

Everything's been great, straightforward and no issues.

I've been looking around to understand if scaling was possible in case the userbase grows too large, but I have found no guides or steps to take.

Is it possible? I'm guessing the steps would be to move the database to a different node, and then host flarum instances on multiple nodes under a load balancer that each connect to the database node. I'm unsure if there are other assets that need to be shared (if a shared file system would be necessary or every instance can have it's own local file system)

KBExit

I thought there were issues with running Flarum via Docker Container? At one point, I heard that when the server restarts, you lose all extensions since composer rebuilds.
In any case, I doubt your flarum instance will be too big for users and posts. The only measure for scaling I would suggest is to migrate and store files in s3 or equivalent storage options as attachements are what take up the most space. Otherwise, you should be fine, unless your VPS is tiny.
Also you can host your database elsewhere, but I would suggest not to as it would make things more complicating, and depending on how you mange it, may be insecure or inefficient and cause more issues. You want the easiest connection between the two as much as possible.

clarkwinkelmann

KBExit I heard that when the server restarts, you lose all extensions

This might have been an issue with a specific Docker image created by the community. But there's no reason Flarum couldn't run in Docker when properly setup, as it's just "another" PHP app.

These kind of issues are more likely when trying to create a general-purpose Docker image, as obviously there's not just the database you need to persist. But if you create your own images for a specific site, you could actually make the entire PHP code readonly and only deal with the usual stuff like database and file uploads.

At least, that's how I understand it. My experience with Docker is very limited and I never tried running Flarum in a virtual or containerized environment.

Regular web hosting, ideally host-isolated, can get you very far already.

luceos

This older post of mine gives an indication on scalability; luceos

Also, there's the redis extension/plugin. Redis can be used to scale session, queue and cache. I highly recommend using it in scalable hosting environments. PS it's compatible with valkey too.

KBExit

clarkwinkelmann when I was first starting out with Flarum, I contacted PikaPods since they advertised it at one point and then it was removed. Which then forced me to bite the bullet and start from scratch initially.
They told me they had issues with the docker image removing extensions. So I was just basing it off of that. I have no idea how they're operating today.

luceos

KBExit They told me they had issues with the docker image removing extensions.

I have zero experience with pikapods. But when you're talking docker images on a scalable environment, I have a fair amount of experience. The one rule for docker images is that they are supposed to be static, like a snapshot. For docker images to work well you need to install the extensions to disk (with composer) before building the image, then you're able to enable or disable the extension when required.

As a sidenote, but arguably way more important, the biggest issue with Flarum right now is the TextFormatter Formatter class cache. It needs to be written to disk, of every instance. As this cache changes whenever an extension adds or removes parsing, formatting or buttons to the composer (editor) component, you will need to initiate a cascade clear and rebuild on every pod. On the managed Flarum hosting platform we store this class to redis and the database, and check the hash to understand when a flush is required. I wrote about this somewhere, but have no time currently to delve it up.