Best Flarum Hosting Providers for 2026

Enable OPcache and set correct PHP memory limits before launch

Two PHP configuration settings have more impact on Flarum performance than any other: OPcache and memory_limit. OPcache caches compiled PHP bytecode — verify it is active by creating a temporary phpinfo() page and checking for the “OPcache” section showing “Enabled” status. On Hostinger, OPcache is enabled by default through hPanel; on SiteGround, it is enabled via Site Tools PHP Manager; on Cloudways, it is pre-configured. Set memory_limit to at least 128MB — 256MB recommended for Flarum installations with many extensions. Configure this in a custom php.ini or .user.ini file in your Flarum root directory (memory_limit = 256M) since Flarum’s bootstrap process loads all enabled extensions on every request and each extension increases peak memory consumption. Also set upload_max_filesize and post_max_size to at least 10MB to support image and file uploads in forum posts. After making configuration changes, run php flarum cache:clear via SSH to rebuild Flarum’s Laravel configuration cache and ensure the new PHP settings are reflected in Flarum’s bootstrap environment.

Always use Composer to install and update extensions — never manual file copying

Flarum’s extension architecture uses Composer’s autoloader to register extension classes, routes, and service providers — manually copying extension files into the vendor/ directory without Composer will produce broken installations that fail silently. Every extension installation, update, and removal must go through Composer: composer require flarum-ext/auth-github to install, composer update to update all extensions, composer remove flarum-ext/auth-github to uninstall. Before running composer update in production, always run it in staging first — extension updates occasionally introduce breaking changes that require configuration adjustments, and a broken Flarum installation in production is immediately visible to all community members. On Cloudways, use the staging environment to test extension updates before promoting to production. On SiteGround GrowBig, create a staging subfolder manually or use staging on higher plan tiers. After any composer update, run php flarum migrate to apply any database schema migrations the updated extensions require, then php flarum cache:clear to rebuild the configuration cache. Keep a record of your installed extensions and their versions in a README file in your repository — this simplifies recovery if your composer.json is lost during a server migration.

Harden file permissions and configure Nginx URL rewriting correctly

Flarum has strict file permission requirements that are commonly misconfigured during manual installations. The storage/ directory and its subdirectories must be writable by the web server user (chmod -R 755 storage/ with chown -R www-data:www-data storage/ on Ubuntu), as Flarum writes logs, cache files, and session data here. The public/assets/ directory must also be writable for compiled extension assets. The vendor/ directory and all files above the public/ webroot must not be web-accessible — verify this by attempting to navigate to yourdomain.com/vendor/flarum/core/src/Core.php in your browser, which should return 404. Configure your Nginx or Apache server block with the correct URL rewriting rules — without this, Flarum’s single-page application routing breaks for all URLs except the homepage. Flarum provides the required Nginx configuration in its documentation: location / { try_files $uri $uri/ /index.php?$query_string; }. On Apache with .htaccess, ensure AllowOverride All is set in the Apache configuration. On Cloudways and SiteGround, these rewrite rules are applied correctly during installation — on Hostinger VPS, apply them manually to your Nginx configuration file.

Configure a queue worker for smooth notification delivery

Flarum’s default queue driver is sync — it processes notification emails and background jobs synchronously during the page request that triggers them. On a small forum this is unnoticeable, but as your community grows and posts trigger notifications to hundreds of subscribers, synchronous queue processing adds seconds to response time for active threads. Switching to a proper queue driver eliminates this: configure QUEUE_DRIVER=database in your Flarum config (Flarum stores queue jobs in the jobs database table) and run a queue worker as a persistent background process. On Cloudways, create a supervisor program config in /etc/supervisor/conf.d/ with command=php /path/to/flarum queue:work –tries=3 and set autostart=true. On Hostinger VPS with systemd, create a unit file at /etc/systemd/system/flarum-worker.service with ExecStart=/usr/bin/php /path/to/flarum queue:work and enable it with systemctl enable –now flarum-worker. On SiteGround without persistent processes, schedule php flarum queue:flush as a cron job every minute as a fallback — this processes queued jobs via cron rather than a persistent worker, with a one-minute maximum delay. Cloudways with Redis as the queue driver provides the most responsive notification delivery — jobs are processed within milliseconds of being queued.

Back up database and files before every Composer update

Flarum’s Composer-based update process is more complex than CMS platforms with one-click updates — a failed extension update can leave the forum in a broken state with PHP fatal errors that prevent any page from loading. Before running composer update, create a complete backup: database dump via mysqldump yourdomain_flarum > backup_$(date +%Y%m%d).sql and a compressed archive of your entire Flarum installation including vendor/ (tar -czf flarum_backup_$(date +%Y%m%d).tar.gz /path/to/flarum/). On Cloudways, use the on-demand backup feature to snapshot the entire server before updates. On SiteGround, trigger an on-demand backup via Site Tools Backups before proceeding. Test Composer updates in a staging environment that mirrors production before applying to live — a staging environment with identical extensions and database content is the most reliable way to catch compatibility issues before they affect real community members. After a successful update, verify core forum functionality: post creation, user registration, email notifications, and any custom extensions. Run php flarum doctor via SSH to check for common configuration issues that updates occasionally introduce. Keep your last known-good backup readily accessible — recovery from a failed update is significantly faster if you can restore from a fresh backup rather than debugging broken Composer dependency states.

Monitor database growth and optimise discussion table indexes

Flarum’s database grows with community activity — every post, notification, access token, and session record adds rows to MySQL. On a high-activity forum, the discussions, posts, and notifications tables can reach millions of rows within months of launch, and un-optimised queries against these tables become the primary source of page slowdowns. Run SHOW TABLE STATUS LIKE ‘flarum_%’; in phpMyAdmin periodically to monitor table sizes. The posts table typically grows fastest — ensure MySQL’s full-text index on the content column is intact by running SHOW INDEX FROM flarum_posts;. Flarum’s built-in search queries this index for the native search feature; if the index is missing or fragmented, OPTIMIZE TABLE flarum_posts; rebuilds it. For forums with 100,000+ posts, Flarum’s native MySQL full-text search degrades significantly — consider installing the Flarum Meilisearch extension (available via Composer) which delegates search to a dedicated Meilisearch process running on a VPS, reducing MySQL query load and providing faster, more relevant search results. On Cloudways, Meilisearch can be installed on the server via SSH alongside the Flarum application. On SiteGround and Hostinger shared plans, Meilisearch requires a VPS upgrade. Routinely clear expired access tokens and notifications via php flarum schedule:run to prevent table bloat from accumulating over time.