Hosting for a WordPress Community Site: What It Actually Needs

A WordPress community site needs a host that runs WordPress 6.9 or newer, PHP 8.1 or newer, MySQL 5.7+ or MariaDB 10.3+, and pretty permalinks. Once BuddyNext Pro and the media and integration plugins are active, set the PHP memory_limit to at least 512 MB. Those are the floor for BuddyNext. Past the floor, a community differs from a brochure site in one way that decides everything else: most of its traffic is logged in, and a page cache can’t help much with that.

We make BuddyNext, so we can speak for its needs. We don’t name hosts, rank them or quote prices here, because plans change and the right one depends on your member count. This guide describes what to look for and how to tell when your current plan has run out.

What are the real requirements?

These come from the BuddyNext plugin and docs. They apply to any community that runs on it.

A few details that save time:

• Memory. With BuddyNext, its Pro layer and the media and integration plugins all active, PHP’s 128 MB default can run out in the middle of a request. The member sees a failed page. WordPress Tools > Site Health flags a low limit. Set it in php.ini, or with WP_MEMORY_LIMIT in wp-config.php.
• Permalinks. BuddyNext can’t run on Plain links such as ?p=123. If your site uses them, a notice in wp-admin offers a button that switches to Post name links in one click.
• PHP version. 8.1 is the minimum. A host still stuck on an older version can’t run it.
• Theme. BuddyNext draws its own community interface, so your theme supplies only the header, footer and fonts. Hosting doesn’t change that.

The plugin’s readme lists slightly older database floors (MySQL 5.7.8, MariaDB 10.2.7). Use the higher numbers above and you’ll be fine on either.

For setup steps, see Installing BuddyNext.

Why do community sites need different hosting from a brochure site?

A brochure site serves the same page to everyone. A page cache saves that page once and hands out copies, so the server does almost no work per visit. That’s why cheap hosting handles a blog with thousands of readers.

A community doesn’t work that way. A member’s feed, inbox, notification count and profile actions are built for them alone. If a cache served one member’s feed to another, that would be a privacy bug. So caching plugins skip logged-in pages, and every logged-in request runs PHP and hits the database.

BuddyNext marks those pages as uncacheable itself, so you don’t maintain an exclusion list. Guests still get cached copies of public pages such as Explore, open spaces and public profiles. That helps your search traffic. It does nothing for the people who are inside, and they are the ones you’re building the site for.

Two consequences follow:

1. Load grows with active members, not with page views. Ten thousand readers of a blog is cheap. Two thousand members each refreshing a feed is not.
2. The resources that matter change. Disk speed and bandwidth stop being the whole story. PHP workers, memory and a fast shared cache take over.

Our post on what makes a community feel fast looks at this from the member’s side.

What is a PHP worker, and why does it matter?

A PHP worker handles one request at a time. If your plan gives you four workers, the fifth simultaneous request waits in line. On a brochure site, requests finish in a few milliseconds and the queue never forms. On a community, each logged-in request does more work, so workers stay busy longer.

You’ll see this as pages that are fine at 10 a.m. and slow at 8 p.m., when members are on together. It also shows when a member posts and a dozen others open the new post at once.

BuddyNext’s free plugin checks for new activity by polling. The notification bell asks every 30 seconds while idle, and the feed checks for new posts every 60 seconds. Every open tab therefore sends regular small requests. Those are cheap, but they add up with many members online, and they need workers to answer them.

Hosts name this limit differently: workers, processes, concurrent PHP requests or entry processes. Ask the host for the number and what happens when it’s reached. Some queue the request, and some return an error page.

Do you need Redis or Memcached?

Eventually, yes. A persistent object cache keeps the results of expensive lookups in memory between requests. Without one, WordPress throws away its cached values at the end of every request, so each request starts from nothing.

BuddyNext caches unread counts, the member directory, the first page of the feed and rate-limit counters through the WordPress object cache. Its docs say that without a persistent cache, the caching code still runs and is still correct, but it never saves a query on the next request. They give a worked figure: at 100,000 members polling every 30 seconds, unread counts alone would be roughly 3,300 count queries per second. That’s a docs example of scale, not a promise about your site.

What this means for you:

• It’s a recommendation, not a requirement. BuddyNext works without a persistent object cache. It’s just slower, and the gap widens with active members.
• Below a few thousand members it rarely matters. BuddyNext doesn’t nag you before then.
• Rate limiting gets weaker without one. Counters can’t be shared between requests, which is a correctness issue as much as a speed one.
• Fixes in recent releases mention it. BuddyNext’s changelog includes fixes for sites on Redis or Memcached, such as comments appearing right away instead of after several minutes. If you run a cache, keep the plugin up to date.

To see whether you have one, open BuddyNext > Platform > Tools > Object cache, or WordPress Tools > Site Health > Info > Caching. With WP-CLI, wp eval 'var_dump( wp_using_ext_object_cache() );' prints true when a persistent cache is active.

The docs list the usual choices:

Ask any host you’re considering whether Redis or Memcached is included, optional or unavailable. The answer tells you how much room you’ll have to grow.

What kinds of hosting can run a community?

Each kind trades cost against control. None is right for everyone.

Shared hosting

Many sites share one server and its resources. It’s the lowest-cost way to start and needs no server skills. The limits are shared CPU, memory and workers, and often no persistent object cache. A small or new community can live here. An active one tends to hit the ceiling first on logged-in page speed.

Managed WordPress hosting

The host specializes in WordPress and handles updates, backups, security and caching for you. Plans usually state a worker count and may include Redis or Memcached as an option. It’s a good fit if you’d rather run a community than a server. Check the plan’s limits on workers and memory, and whether its page cache correctly skips logged-in pages.

VPS or cloud servers

You rent a slice of a server, or a cloud instance, and configure it yourself or through a control panel. You get dedicated resources and the freedom to install Redis, tune PHP and run a system cron. You also get the work: patching, monitoring and restoring from backups. It suits teams with someone who can do that, or who pay someone to.

A hosted platform with hosting bundled

Hosted community platforms such as Skool and Circle run the servers for you, so there’s no hosting decision at all. In exchange, your members and content live on the vendor’s system. This is a different model, not a type of WordPress hosting. We compare the two in self-hosted versus hosted community platforms, and the self-hosted community platform guide covers what you take on when you choose it.

Where should media files live?

Community sites collect uploads fast: avatars, cover images, photos, video, shared files. Disk space and bandwidth are the first things people notice.

Think about three questions:

• How much disk does the plan include, and what happens at the limit? Photo and video communities grow quickly.
• Is bandwidth metered? Large files served from the web server count against it.
• Do you want files on a CDN or object storage? Offloading media moves storage and delivery off the web server.

BuddyNext limits profile images by default: a 4 MB cap for avatars and 5 MB for covers, plus limits on pixel count and longest side. Developers can change those with filters. For offload, BuddyNext fires an action when an avatar or cover is written to disk, a second when its folder is about to be removed, and a filter on the public URL, so a CDN or offload integration can push, purge and rewrite. Media uploaded through WPMediaVerse is handled by that plugin, so check its documentation for its storage options.

Test your upload limits too. PHP and the web server each have their own maximum upload size, and the lowest one wins. If members report that large photos fail, look there before blaming the plugin.

How do background jobs and cron work?

BuddyNext does a lot of work out of sight: digest emails, cleanups, scheduled posts and outgoing emails. These run as background tasks. Where Action Scheduler is present, jobs run through it so you can see and retry them; otherwise the same hooks run on WP-Cron. BuddyNext never defines DISABLE_WP_CRON and doesn’t require a system cron to be fast.

WP-Cron has a quirk that matters on community hosting. It fires when someone visits the site. A busy community has plenty of visitors, so it works. A quiet one may go hours without a trigger, and digests go late.

Many larger sites switch WP-Cron off and run a real server cron instead, which fires on a schedule whatever the traffic. BuddyNext supports this. The Tools screen under BuddyNext > Platform > Tools checks that background tasks are keeping up. If cron is off and tasks are piling up, it says so and shows the exact server cron line to add. If cron is off but tasks are clearing, it tells you a system cron is already driving them. It reports what it finds and never changes your cron setting itself.

When you compare hosts, ask:

• Can I add a real cron job, and how often can it run?
• Is there a cap on how long a request or process may run?
• Can I see failed or pending scheduled actions?

Large moderation clean-ups also run in the background. In BuddyNext Pro, a selection of more than 50 items in bulk moderation is split into background jobs so it can’t stall on a request timeout.

How should you handle email delivery?

Community email is steady and high-volume: replies, mentions, digests, invitations and renewal notices. Mail sent straight from a web server often lands in spam or never arrives.

BuddyNext’s own advice is to set the From address to an address on a domain you own, and to pair it with an SMTP or email-delivery plugin so a real email provider sends the mail rather than your web server. It sends all its emails through one branded sender identity, and it keeps an email log. A Sent row means BuddyNext handed the message to WordPress, and the trail continues with your SMTP plugin or host. A Failed row shows the error WordPress returned. So when a member says they never got their verification email, check the log before you debug the mail server.

Some hosts restrict or throttle outgoing mail. Ask about limits per hour before you launch an invitation campaign. A bulk CSV invite sends up to 500 rows per upload, and each address is an email.

What should your backups include?

Backing up files alone isn’t enough. BuddyNext keeps its own database tables for the feed, spaces, members, messaging, notifications and moderation, so your community lives mostly in the database.

Check these points:

• The database is included, on a schedule that matches how much you can afford to lose. A busy community changes by the minute.
• You’ve tested a restore. A backup you’ve never restored is a guess.
• Uploads are covered, including media offloaded to object storage, which sits outside the plugin’s folder.
• Settings are exported. BuddyNext can export every BuddyNext setting as a JSON file, which helps with staging and recovery. It covers settings only, not content.

BuddyNext also expects restores to be messy. An interrupted update, a restored backup or a moved site can leave a table or column missing. It notices and repairs this the next time you open wp-admin. If your database user isn’t allowed to create or alter tables, the Tools screen lists what’s missing and why, and a button retries once the host fixes it. Deleting the plugin keeps your data by default, and you can choose to wipe it on delete.

Does real-time need its own server?

Only if you want it. Free BuddyNext uses polling, which needs nothing special. BuddyNext Pro’s real-time feature replaces polling with a live connection through a Pusher-compatible server, so notifications, reactions, comments and messages appear at once. You can run that server yourself or use a hosted service.

If you self-host it, the docs say you need a small VPS or container host, a hostname you control, HTTPS (browsers refuse insecure WebSocket connections from an HTTPS site) and Redis for any real deployment. They describe a 1 GB instance as comfortable for a normal community. If the server is unreachable, BuddyNext falls back to polling quietly.

That means real-time is a hosting decision as well as a plugin setting. If you don’t want another server, pick a hosted option and skip the deployment guide.

How do you know it’s time to upgrade?

Use this as a rule of thumb. It’s not a formula, and we’ve kept numbers out on purpose because they depend on your content, theme and plugins. Watch for signs, and move up one step when a few of them show up together.

A new or small community

• Pages load well for logged-in members at the busiest hour.
• Background tasks clear and the Tools screen shows no warnings.
• Nothing here calls for more than a plan that meets the requirements.

A growing community

• Logged-in pages slow down at peak times while public pages stay quick.
• Members report timeouts when posting or uploading.
• The Tools screen warns that no persistent object cache is present.
• You’re near your PHP worker or memory limit.
• Digests or scheduled posts go out late.

A busy community

• Feed and notification loads lag even with an object cache on.
• The queue of scheduled actions grows faster than it clears.
• Email limits delay invitations or digests.
• Disk or bandwidth is climbing from media.
• You want real-time updates, which means another service to run or rent.

When you see these, the order we’d try is: turn on a persistent object cache, then raise memory and workers, then move to a plan or server with more headroom. Plugin Isolation under BuddyNext > Platform is worth a look if one unrelated plugin is slowing community pages. It’s off by default and lets you skip chosen plugins on community routes only.

Also reduce the work: update plugins, remove the ones you don’t use, and check that page-cache plugins skip logged-in pages. The docs on page cache and optimisation plugins list what was tested with WP Rocket, LiteSpeed Cache, W3 Total Cache, WP Super Cache and Autoptimize, and tell you to purge all caches after every BuddyNext update.

What about BuddyBoss and BuddyPress hosting?

People search for “BuddyBoss hosting” and “BuddyPress hosting” as if each needed a special kind. For the most part, they don’t. Both run on WordPress and put the same pressure on a server: logged-in members, a database that grows, background mail and uploads. Look up each vendor’s current stated requirements on its own site, since they change with releases.

What does differ is the plugin set around the community. A site with forums, courses, events and a media library has more code loading per request than a bare social layer. That’s why BuddyNext’s memory advice depends on how many of the family plugins are active. Plugin count and member activity matter more than the brand name on the community plugin.

Checklist before you choose a host

• PHP 8.1 or newer, and a memory_limit you can set to 512 MB or more.
• MySQL 5.7+ or MariaDB 10.3+, and the ability to use pretty permalinks.
• A stated PHP worker count, and what happens when it’s exceeded.
• Redis or Memcached available, even if you don’t switch it on yet.
• A real cron job you can schedule.
• SMTP or an email service, plus the host’s outbound mail limits.
• Disk, bandwidth and upload-size limits that fit your media plans.
• Database backups on a schedule, with a restore you’ve tested.
• A staging site, so you can test updates before members see them.
• A clear route to a bigger plan without migrating again.

If you want to see the hosting-related panels first, the demo sandbox (four hours, asks for your email) shows the Tools screen. Then download the free plugin, run the setup wizard, and check Site Health before you invite anyone. If you’re comparing costs, what a community platform costs to run puts hosting next to the other line items.