A forum's load is set by its members' habits, not by a marketing calendar. Capacity is decided by the peak hour of a community's day, and the peaks are predictable right up until they are not. We operate the layer that has to hold under both.
A community's traffic concentrates. Evenings, a breaking news event, a thread that catches fire, a migration that brings a spike of returning members — the busiest hour of a forum's week can be several times its average, and the timing is not chosen by anyone running the site. Sizing for the average produces a platform that is comfortable most of the time and unavailable exactly when its audience is present, which is the failure it will be judged on.
The site works but not reliably, and you need infrastructure sized for how the community actually behaves rather than for a specification someone guessed at.
You want consistent infrastructure and a consistent operating standard across installations rather than a different arrangement on each.
You have been doing this yourself and you need it to be somebody's actual responsibility, with documentation, before something fails while you are away.
Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.
A forum that is slow at six in the evening is unavailable to most of its audience most days. The judgement members and advertisers make is formed in those hours, not across the monthly average.
Query cost and storage grow with history, and attachment sets only ever grow. Capacity that was comfortable at one size becomes abruptly inadequate at another rather than declining gradually, which removes the warning a gradual decline would have given.
Posts lost, sessions dropped and periods of unavailability cost participation. That is not recoverable by restoring a backup, because it is a behavioural cost rather than a data one.
Without baseline instrumentation, whether the forum feels slow is the only available signal, and it arrives after the problem is established rather than before.
Each of these is work we carry out, not an area we advise on.
What is running, at which versions, on what specification, with which extensions and what the current load profile looks like. Established from the environment rather than from its documentation, because on community platforms those frequently disagree.
Sizing derived from observed peak behaviour rather than from average traffic, with headroom estimated for the events a community actually produces — a viral thread, a migration bringing members back, a news event in the forum's subject.
Web server, application runtime and database configuration tuned to the platform's actual query patterns. Community platforms have characteristic hot paths and tuning them generically leaves most of the available improvement unclaimed.
Caching strategy and edge delivery configured with awareness of what a forum can and cannot cache. Logged-in community traffic is largely uncacheable, and a configuration that assumes otherwise produces a cache with almost no hit rate.
Backups sized and scheduled around a community's load, with restore actually tested. On a forum the attachment store usually dominates backup size, which is why its retention is a decision rather than a default.
Availability, response time, resource use and database health, instrumented so a developing capacity problem is visible before it becomes an outage rather than after.
Forum search behaves differently from site search, particularly over long histories. Where the platform delegates search, that layer is part of the platform and is operated as such.
Patching, upgrades, capacity management, incident response and reporting, with an agreed shared-responsibility boundary and a written escalation path.
The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.
Peak-to-average ratio, when peaks occur, how long they last and what drives them. A forum's load shape is its own and it determines every sizing decision — so it is established from observation rather than from a hosting tier.
Application, database and static assets are separated where the load shape justifies it and left together where it does not. On a community platform, the database is usually the tier that decides the ceiling.
Community software has characteristic expensive queries — unread state, search, thread rendering at depth. Tuning those is worth more than generic server optimisation, and profiling is what identifies them.
The configuration is validated against load representative of the busiest period, not against a normal afternoon. Testing at average load confirms that nothing is obviously broken, which is a much weaker statement.
Backups, reindexing and heavy maintenance run when the community is quiet, defined by observed behaviour rather than by a default window.
An environment that is watched occasionally is not managed. The commitment is a cadence of work, a named escalation path and a recurring report, so the community's infrastructure is somebody's actual responsibility.
Documentation is a deliverable, not an afterthought. On most of these engagements a large part of the value is a defect report precise enough for another team to act on.
Engagements where this capability was the substance of the work rather than a line item.
Since 2019, Soludome has managed infrastructure and platform operations for one of Spain's largest online communities. The work covers server and performance optimisation, CDN architecture, load balancing and site security under sustained traffic.
Since 2021, Soludome has managed infrastructure, site performance and technical SEO across GuzziTech and RideMalibu as a connected web estate. The engagement includes dedicated infrastructure and continuing operational ownership.
These overlap at the edges. Sending you to the right page is more useful than having you work it out.
Extensions, templates and upgrade work differ from running the environment.
XenForo developmentThe cutover itself is a project rather than a transfer.
Server migrationQuery plans and template cost are development concerns rather than hosting ones.
Custom XenForo add-on developmentAttack traffic is a security problem before it is a capacity one.
Website securityNo. We operate environments on infrastructure you own or rent directly from a provider, and we do not resell hosting or mark it up. That keeps the commercial relationship and the ability to leave with you, which is the arrangement we would want if we were the buyer. If your requirement is a host rather than an operator, we are not the right answer and we will say so.
Sometimes, and it is worth establishing which problem you have before buying anything. A community platform can be slow at peak because the machine is genuinely undersized, because a handful of queries are expensive at scale, because caching is configured for traffic that cannot be cached, or because maintenance is running during busy hours. Those have four different fixes and only one of them is hardware. Profiling comes first.
We will confirm that for your specific installation rather than publishing a matrix. Support windows for the operating system, runtime and database move independently, and a published range ages into being misleading. What we will tell you is what your installation is running, whether it is still receiving security updates, and what the upgrade path looks like.
Sometimes, and we have done it — one long-running engagement began with a move to more cost-effective infrastructure without a performance loss. It is not the usual outcome of a capacity review, though, and we will not present it as the goal. The honest position is that a forum's costs are driven by its peak load and its attachment storage, and both are consequences of its success.
By the time a spike arrives, the only thing that can help is having sized for it beforehand. We watch for developing pressure, keep headroom against observed peaks, and will tell you what the platform can absorb and what it cannot. What we cannot do is create capacity instantly, and a page that implies otherwise is describing an autoscaling story that community software rarely supports well.
Yes, and that is the usual starting point rather than a fresh build. The work begins with an inventory and a measured load profile, then a tested restore. Most inherited forum environments are broadly sound and undocumented; the valuable part of the first month is usually the document nobody had rather than the changes nobody had made.
Describe what is happening rather than what you think the cause is. If we are not the right people for it, we will say so.