Your site was fast until members arrived.
It felt fine while you were building it. Then people logged in, started posting and took lessons at the same time.
Danica LouweUpdated 5 min readDuring a build, only a few people use the site. After launch, many members load personal pages at once, and those mostly can’t be cached, so the server does the work each time. Shared hosting often runs out of room here. Test while logged in, rule out a heavy plugin, then move to managed hosting or your own server, sized for your busiest hour.
Testing never looks like a busy Tuesday.
While you build, a few people click around. After launch, members log in, post and take lessons all at once, and your server has to keep up with all of it together.
Logged-in pages are built fresh
A public page can be saved and handed to everyone. A member’s dashboard shows their own courses, progress and notifications, so the server usually has to build it for them.
Shared hosting runs out of room
You feel it during launch or a webinar, when many people need the server at the same moment. It may have seemed fine a day earlier.
A bigger plan may not be enough
One client was already on their host’s top shared plan, paying around $250 a month, and it was still slow. Moving to their own server fixed it and cost them less.
Sometimes it isn’t the host
One heavy plugin or a page doing too much can slow a site on any server. That’s why this gets checked before anyone pays to move.
Test it the way a member uses it.
Checking your homepage while logged out won’t show you the problem. Use a real member-level account, on your phone as well.
- How long the dashboard, community feed and a lesson take to load when you’re logged in as a member.
- Whether it’s slow all day, or only during a webinar, an email send or a launch.
- How many people are active at once at your busiest. Google Analytics shows active users.
- Whether it started after a particular plugin or update. If so, new hosting may not help.
- What your plan really gives you. Ask your host about CPU limits and how many requests it can run at once.
- Where most members are compared with your server, because distance adds delay.
Rule out a bad plugin, then size hosting for your busiest hour.
There are two sensible routes: managed hosting, where someone else runs the server, or your own server with a tool that makes it manageable. Prices were checked on 6 November 2026, before tax.
- 1
Rule out one heavy plugin
Test on a copy of the site and look for a single plugin or page taking most of the time. Fix that first, because a bigger server won’t cure it.
- 2
Size for your busiest hour
Take your highest number of people active at once and add 30 to 50% on top. The extra is so a good launch doesn’t take the site down overnight.
- 3
No one to run a server? Go managed
Levamo (it was Rapyd Cloud when a client of ours used it) was simple to work with and has chat support. Starter is $35 a month for one site and 25,000 visits. Business is $119 for three sites and 75,000 visits.
- 4
Happy to set one up? Use your own
A server manager like RunCloud ($9 a month) plus a server. Our clients are on Hetzner: CCX13 is about €44 a month, AX42 is €99 plus €49 setup, and AX102 is €259 plus €129 setup. Clients with regular ads or webinars tend to go straight to AX102.
- 5
Test, switch, test again
Move a copy first and test it logged in. Switch at a quiet time, then repeat the checks above so you can see the difference.
The technical version, for your developer
This comes from what we’ve run for clients and checked against current host pages. We used the AX52, which Hetzner no longer lists. AX42 is the closest current size by memory, and we haven’t run it ourselves yet.
- Specs. CCX13: 2 dedicated vCPU, 8 GB RAM, 80 GB NVMe. AX42: 8 cores, 64 GB RAM, 2 x 512 GB NVMe. AX102: 16 cores, 128 GB RAM, 2 x 1.92 TB NVMe. Hetzner’s page showed CCX plans as unavailable when we checked on 6 November 2026, so check stock before planning around one.
- Location. Hetzner’s dedicated AX servers are in Germany and Finland. Its cloud servers also run in the US, in Oregon and Virginia, which may suit a mostly American membership better.
- RunCloud. Essentials covers one server and includes NGINX FastCGI and Redis caching, plus 2 GB of backup storage. Extra storage starts at $2 a month. Connecting a server starts with a terminal command, and it’s straightforward after that.
- Caching. Keep page caching away from logged-in members and use a Redis object cache for them. Exclude cart, checkout and account pages.
- Dedicated servers. Set up disk and uptime alerts. Disks can fail, and you then have to ask the host for a replacement, so someone has to be watching.
- Alternatives. Amazon EC2 is fast, but it bills by usage, and one client’s bill ran over $200 a month. Vultr has worked well for us too, and it’s a useful fallback if Hetzner’s account verification turns you down.
Watch it done
The hosting options we’ve used for membership sites, compared by hand. Recorded in 2024: names and prices have changed since, and the ones on this page are current.
Questions owners ask
Will a caching plugin fix it?
It helps the public pages. Logged-in pages are personal to each member, so they mostly can’t be served from a page cache. Object caching helps there, but it won’t make up for a server that’s out of room.
Do I need a dedicated server?
Not to start with. A smaller cloud server or a managed plan can be enough when only a few hundred people are active at once. A dedicated server makes sense when you run ads or webinars that bring a crowd at the same moment.
Is this only a BuddyBoss problem?
No. A community makes it show up sooner because members are always posting and reacting. A course site with thousands of members can hit the same limit, because each person’s progress and access has to be worked out for them.
Is shared hosting ever fine?
For a small site where only a few members are logged in at once, it can be. The trouble is that it often feels fine right up to launch, so it’s hard to judge from testing alone.
Can we move hosts without losing anything?
Yes, with care. Test on a copy first and switch at a quiet time, then keep that gap short, because anything members do on the old server after the final copy won’t come across.
