Webspace for Flarum

Yolo

Where do you host your Flarum? We are looking for a good Space. What do you think about the offer of Bitpalast?

Hari

Yolo i host @ cloudways they provide managed web hosting. They have plans like $20, 40, ..etc i feel less stressed about managing website at the same time we don't get full permission of our hosting. If i want something i just goto their support desk and ask them to do maintenance for me. They installed my flarum. From last 2 years i don't have any complaints with CW support.

I do also manage couple of flarum's for my friends on digital ocean using plesk but this is always stressful

Valeyard

Yolo Where do you host your Flarum? We are looking for a good Space. What do you think about the offer of Bitpalast?

They don't have access to Composer in the jailed SSH, you would need to check with them first if they can provide this for you as it's required for updating Flarum or adding extensions.

Steer clear of EIG or GoDaddy or companies that use "custom"/"in-house" control panels.

CyberGene After a month of struggle switched to Siteground and I’ve been with them now for 7 months. Never even a single problem, always fast access.

The issue with SiteGround is that they run a custom in-house control panel. For shared hosting you should stick to companies that use Plesk, DirectAdmin, or cPanel. A control panel isn't just an interface for the clients which is how you experience as a shared hosting client, it's for server management. Stability, security, and isolating shared customers from accessing the data of other customers. If something on the back-end goes wrong like database corruption it's totally possible for your sensitive data to end up being visible to other clients, or there may be a serious security vulnerability with the custom panels. A critical RCE exploit affecting every version of MyBB going back to 2009 (13 years) was patched in March 2022. Most people that run forums similar to MyBB run them on stale versions for a very long time. like the blue forum which is vB v.4.2.2. Even tech companies are determined to run stale software that's completely out of security maintenance.

It's the same thing with server control panels, but security is much more important we're talking about the possibility of hacking not just one client's data, but the data of 100's or even 1000's clients that are on the same shared server. So it's critically important for them to have high level of security and low risk of being hacked/exploited. The commercial panels I mentioned achieve this by getting very expensive security audits once a year or so. And op top of that they have bug bounty programs. Does SiteGround get their custom in-house panel audited each year at a cost of $20K+? Who knows it's anyone's guess. Is it under regular development like Plesk is? Who knows that's anyone's guess. Do they have a bug bounty program? Doesn't appear so.

The structure on a shared server is something like this:

/home/customerID001/
/home/customerID002/
/home/customerID003/
/home/customerID004/
/home/customerID005/
/home/customerID006/
/home/customerID007/
/home/customerID008/
/home/customerID009/
/home/customerID010/
/home/customerID011/
/home/customerID012/
/home/customerID013/
/home/customerID014/
/home/customerID015/
/home/customerID016/
/home/customerID017/
/home/customerID018/
/home/customerID019/
/home/customerID020/
/home/customerID021/
/home/customerID022/
/home/customerID023/
/home/customerID024/
/home/customerID025/
/home/customerID026/
/home/customerID027/
/home/customerID028/
/home/customerID029/
/home/customerID030/
/home/customerID031/
/home/customerID032/
/home/customerID033/
/home/customerID034/
/home/customerID035/
/home/customerID036/
/home/customerID037/
/home/customerID038/
/home/customerID039/
/home/customerID040/
/home/customerID041/
/home/customerID042/
/home/customerID043/
/home/customerID044/
/home/customerID045/
/home/customerID046/
/home/customerID047/
/home/customerID048/
/home/customerID049/
/home/customerID050/
/home/customerID051/
/home/customerID052/
/home/customerID053/
/home/customerID054/
/home/customerID055/
/home/customerID056/
/home/customerID057/
/home/customerID058/
/home/customerID059/
/home/customerID060/
/home/customerID061/
/home/customerID062/
/home/customerID063/
/home/customerID064/
/home/customerID065/
/home/customerID066/
/home/customerID067/
/home/customerID068/
/home/customerID069/
/home/customerID070/
/home/customerID071/
/home/customerID072/
/home/customerID073/
/home/customerID074/
/home/customerID075/
/home/customerID076/
/home/customerID077/
/home/customerID078/
/home/customerID079/
/home/customerID080/
/home/customerID081/
/home/customerID082/
/home/customerID083/
/home/customerID084/
/home/customerID085/
/home/customerID086/
/home/customerID087/
/home/customerID088/
/home/customerID089/
/home/customerID090/
/home/customerID091/
/home/customerID092/
/home/customerID093/
/home/customerID094/
/home/customerID095/
/home/customerID096/
/home/customerID097/
/home/customerID098/
/home/customerID099/
/home/customerID100/
/home/customerID101/
/home/customerID102/
/home/customerID103/
/home/customerID104/
/home/customerID105/
/home/customerID106/
/home/customerID107/
/home/customerID108/
/home/customerID109/
/home/customerID110/
/home/customerID111/
/home/customerID112/
/home/customerID113/
/home/customerID114/
/home/customerID115/
/home/customerID116/
/home/customerID117/
/home/customerID118/
/home/customerID119/
/home/customerID120/
/home/customerID121/
/home/customerID122/
/home/customerID123/
/home/customerID124/
/home/customerID125/
/home/customerID126/
/home/customerID127/
/home/customerID128/
/home/customerID129/
/home/customerID130/
/home/customerID131/
/home/customerID132/
/home/customerID133/
/home/customerID134/
/home/customerID135/
/home/customerID136/
/home/customerID137/
/home/customerID138/
/home/customerID139/
/home/customerID140/
/home/customerID141/
/home/customerID142/
/home/customerID143/
/home/customerID144/
/home/customerID145/
/home/customerID146/
/home/customerID147/
/home/customerID148/
/home/customerID149/
/home/customerID150/
/home/customerID151/
/home/customerID152/
/home/customerID153/
/home/customerID154/
/home/customerID155/
/home/customerID156/
/home/customerID157/
/home/customerID158/
/home/customerID159/
/home/customerID160/
/home/customerID161/
/home/customerID162/
/home/customerID163/
/home/customerID164/
/home/customerID165/
/home/customerID166/
/home/customerID167/
/home/customerID168/
/home/customerID169/
/home/customerID170/
/home/customerID171/
/home/customerID172/
/home/customerID173/
/home/customerID174/
/home/customerID175/
/home/customerID176/
/home/customerID177/
/home/customerID178/
/home/customerID179/
/home/customerID180/
/home/customerID181/
/home/customerID182/
/home/customerID183/
/home/customerID184/
/home/customerID185/
/home/customerID186/
/home/customerID187/
/home/customerID188/
/home/customerID189/
/home/customerID190/
/home/customerID191/
/home/customerID192/
/home/customerID193/
/home/customerID194/
/home/customerID195/
/home/customerID196/
/home/customerID197/
/home/customerID198/
/home/customerID199/
/home/customerID200/

And then inside each client's folder is public_html/ or www/ and other customer stuff like usually your private key and certificate etc. So you need a very high level of trust in the panel to be isolating you directory from the possibility of being accessed by another client. Linux does set up users with limited permissions, but cuts corners when they make the control panel then it's possible that they can gain access anyway in a variety of ways.

How might this happen? Well an unsophisticated attack may be to try and guess another customer's root path and set a subdomain to use that path, e.g. you create a subdomain s1.example.com and the panel wants to use /home/example.com/public_html/s1 but you tell it instead to use /home/myecommercewebsite.com/public_html/ if it accepts, then it will create a new web server and point it to that folder and give you login credentials and you've successfully hacked into another person's account. You may not even need to guess their folder's name, you may be able to see al the other client's folders in FTP or SSH but just not have the permissions to see inside them - a poorly coded control panel may give you access with the attack described above. Same with databases - you could try to guess the database name of another client if it let you. But if you hack a Flarum website you can just read the database password in the configuration file and then open their database and steal everyone's email address and their associated IP addresses and usernames not to mention their password hashes as well which you can then try to hack.

So my point is that with shared hosting it's very important for security that the panel is actually isolating the clients from each other in a way that prohibits any possibility of them lurching into other client's data whether intentionally or unintentionally. And that is especially true if you're responsible for people's personal data.

SMalt

Yolo
There is ssh access, but without composer. I have moved an existing installation as a test. The backend composer function recognizes the valid composer.json in the public directory of flarum. Flarum works.
But a base installation from scratch will fail. Also an upgrade.
Too bad there is no other way to install flarum. If webhosts are excluded it will harm this good project.

CyberGene

Started on A2, was awfully slow and laggy while we were still 10 people. After a month of struggle switched to Siteground and I’ve been with them now for 7 months. Never even a single problem, always fast access.

almalino

AWS lightsail

MikeJones

almalino AWS lightsail

I am on EC2, whats the difference between AWS lightsail vs EC2?

girefko

Hostiso
They provide amazing customer support, easy installation of Flarum, unlimited shared space & unlimited bandwidth. I'm personally very happy with them. Only €6/month

Hari

girefko redis support?

girefko

Hari Yes I believe so.. https://my.hostiso.com/knowledgebase/6/How-to-enable-redis-caching.html

Prosperous

Liquid Web for me; the best hosting service I have ever used in the ₁₅ years since getting into the whole forum thing.

I am on a shared plan which they don't offer any more (I was one of the last to get the package). Support is provided by them directly from the US and it is honestly second to none. You speak to humans and they are very knowledgeable.

clarkwinkelmann

Valeyard SMalt if you can run php via SSH, you can download the Composer phar package and run it as a standalone php executable. The commands are easier to type when Composer is installed globally but it's not a requirement.

Composer is just a PHP software in the end. The main reason we don't have Composer built into the Flarum web GUI (yet) is because the amount of memory and resources needed are often not available to the web process, but are available to the command line. And the same hostings where you can't adjust the amount of web resources are often the same ones that don't allow command line access, which automatically rule them out for any Composer-based package management even if we had a GUI available.

CyberGene

Valeyard you dismiss SiteGround on the grounds of using a custom control panel. Have you heard of a security breach of their custom panel so far? Recommending against a service just because they use a custom solution that you assume makes it insecure is a long shot IMO.

What I can say is there’s no power on earth that can make me use A2 again who use the “recommended” cPanel. There’s more to a hosting than some vague theories. And even the most audited software is not immune from security breaches.

Valeyard

clarkwinkelmann Composer is just a PHP software in the end. The main reason we don't have Composer built into the Flarum web GUI (yet) is because the amount of memory and resources needed are often not available to the web process, but are available to the command line.

Oh right, thanks for the clarity.

Valeyard

I'm transposing this response from another thread as it has to do with security:

clarkwinkelmann And the same hostings where you can't adjust the amount of web resources are often the same ones that don't allow command line access, which automatically rule them out for any Composer-based package management even if we had a GUI available.

I for one don't want it in the admin gui - forum admins are not server admins. We need security by design.

This is why with email for example the SRS (Sender Rewriting Scheme) allows you to authenticate emails you forward, even though you're not an authorised party and could be spoofing the SRS if you were determined enough to. It's hardly a 100% secure scheme - however the security is in the fact that only the server administrator has the ability to set it up.

In a similar way you don't want forum admins who have a different skill set to a server admin to have the ability to run back-end commands that may break something or may create problems or security vulnerabilities. Also if someone hacks an administrator's account (which is far more likely than hacking the server) then if they have access to running any commend-line back-end commands that's a serious problem for security, even if it is limited to only PHP & Composer. They could discover your database password, and then dump the database and steal it. Note that the MyBB RCE exploit patched in v1.8.30 required administrative access to the forum to exploit and it was graded as a HIGH RISK security vulnerability.

If you ever wish to have the ability to upgrade core or plugins or to install new ones, it should be done through a non-core extension that explicitly installs and upgrades the extensions and does nothing else. If such an extension were to be created it could be bundled with the Softaculous version of Flarum and should be self-uninstallable for those who wish to remove it and use SSH. Furthermore it should create an extra userclass called "Server Admin" and rename regular admins to "Forum Admin" and then that way you can separate which of your Forum Admins can have access to that extension/functionality.

I know that sounds like a lot, but doing it any other way is a bad idea IMHO.

SMalt

clarkwinkelmann if you can run php via SSH, you can download the Composer phar package and run it as a standalone php executable.

Unfortunately this is exactly not possible, besause they don't have access to Composer in the jailed SSH.

Composer itself is available and can be clicked in the customer backend (PLESK). If a valid composer.json is recognized, the composer runs.
As I said, I was able to move an existing Flarum installation from a vserver to the webspace in the test environment.
What content does a composer.json need to get a Flarum base installation? Is that even possible?

luceos

CyberGene I agree with you. I've built and maintained a custom in-house control panel for over 5 years and it has never seen one single security breach. I must say the tech behind it was rather excellent and based on the enormous experience the CTO back then had though. Each server connected had a little daemon that could execute very specific tasks (set up a website, configure a user etc) which it has to retrieve from the control panel , the control panel could only ping that server to start executing tasks. Using an encrypted connection with certificate verification made it even better. Not all custom built things are bad. I can't imagine a party like siteground relying on a poorly secured control panel honestly.

I also like to point out that CloudLinux is a great OS for running servers with hosting. It isolates websites perfectly, better than the usual Linux. You can't just access another docroot even if that is set to be 7777.

clarkwinkelmann

SMalt if you have access to php command in the jailed SSH (can try running php -v to verify), you can download the Composer executable and run php /path/to/composer.phar [command]. I would be very surprised if the host gives access to php but somehow fingerprints executable files to detect Composer. If php isn't available via SSH then indeed there will be no way to run Composer this way.

SMalt

clarkwinkelmann

Then the question of the topic creator is answered. Bitpalast is not suitable for Flarum.

luceos

MikeJones lightsail seems to be the hosting for dummies 🙈 With EC2 you have more control, but it is also more complex. Lightsail seems to group services (database, redis etc) onto one node for instance, with EC2 this is up to you. EC2 as such looks more like a bare VM hosting service, whereas lightsail takes away much of that gritty server management.

disclaimer: I have zero experience with either of those, but that's what I gathered from https://aws.amazon.com/free/compute/lightsail-vs-ec2/

almalino

luceos
Sounds pretty much correct. I am an expert in normal AWS/EC2 as I use them at work. But for my own servers I use lightsail. The reason?

Lightsail is twice cheaper for the same service. Sure you can "reserve" EC2 for 3 years to get the same price or use "Savings plan". But as a person I am not ready to commit to 3 years "reservation" and prefer Lightsail billing model that is just 2 times cheaper.
Lightsail has all mandatory bare bones for EC2/RDS = easy server start with multiple OSes, elastic IP, snapshots, SSH etc. It is more than enough to host Flarum.

IMHO using EC2 for Flarum is like using a sledgehammer to crack a nut

luceos

almalino Lightsail has all mandatory bare bones for EC2/RDS = easy server start with multiple OSes, elastic IP, snapshots, SSH etc. It is more than enough to host Flarum.

It's like docker-compose then, but without the files and just a ux for easier management? Thanks for the clarification.