Somebody has to own the server. If it is nobody in particular, it is owned by whoever notices a problem last. We take responsibility for agreed operations — patching, backups, monitoring and escalation — with the boundary of that responsibility written down before the first change.
A production environment usually drifts into being unmanaged rather than being left unmanaged deliberately. It was set up competently by someone who has since moved on, it works, and it is nobody's assigned responsibility until it fails. The failures that follow are rarely dramatic: an untested backup, a patch that was never applied, a certificate that expired on a Sunday, a disk that filled quietly for six weeks.
Your website matters to revenue and its server has no named owner. You want that responsibility held formally rather than by whoever happens to notice.
Your engineers should be building the product, not chasing certificate renewals and disk usage. You need operations handled with clear escalation and a written boundary.
You have inherited a production environment with no documentation and you need a competent inventory before you can even decide what to change.
Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.
A backup routine that has never been tested is a routine, not a recovery capability. The failure is discovered at the worst possible moment, and it is completely avoidable.
Each version skipped makes the next one harder. Two years of deferral turns a routine update into a project with a deadline set by someone else, usually because support has ended.
An outage is paid for in lost revenue, emergency work at unsocial hours and, frequently, an improvised fix that becomes the next problem. The recurring cost of avoiding it is almost always lower.
When knowledge lives in one person's head, their departure is an incident. Documentation is not administration overhead; it is what makes the environment survivable.
Each of these is work we carry out, not an area we advise on.
Before anything is changed, a written record of what exists: services, versions, scheduled jobs, integrations, DNS, certificates, backup destinations and who holds which access. Most of this does not currently exist for the environments we are asked to take on, and it is the first deliverable rather than an afterthought.
Establishing who can reach the environment, through what, and with what privilege — replacing shared credentials and undocumented keys with named access that can be revoked when someone leaves.
A defined schedule rather than a policy: what is updated, how it is tested, when it is applied, and what the rollback is if it goes wrong.
Confirming that backups exist, that they complete, and — the part that is usually missing — that a restore actually works. Tested restore is the deliverable; a backup log is not evidence.
Availability, resource use, certificate expiry, disk growth and service health, wired to somewhere a human actually reads. Alerting nobody receives is indistinguishable from no alerting.
Web server, database and application-level tuning reviewed against observed load, with headroom estimated in advance rather than discovered during an incident.
A documented, repeatable way to ship a change — including how to reverse it — so releases stop being unrepeatable events whose success depends on the person doing them.
A named route for a problem that exceeds the agreed scope, rather than an informal expectation that someone will notice a message.
A recurring report of what was done, what was found and what needs attention, so the state of the environment is visible to the people funding it rather than inferred from the absence of complaints.
The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.
We do not change a production environment we have not first described. The inventory is written down and reviewed with you, because half of the value of taking on an undocumented server is producing the document nobody had.
A shared-responsibility model is agreed before work starts: what we operate, what remains yours, what the hosting provider owns, and where each ends. Most managed-server disputes are disagreements about this table that were never made explicit.
A tested restore is established early, because until it exists every other change carries avoidable risk. This is usually the least glamorous part of onboarding and the most valuable.
Alerting is set up so that it reaches a human, and then the alerts are actually reviewed. Monitoring that produces noise nobody reads is worse than no monitoring, because it creates the impression of coverage.
Patching, updates and version upgrades run on a defined cadence with a tested rollback. Emergency changes are occasionally necessary and are always a signal that something upstream was deferred.
A recurring written report means the state of the platform is a fact the business can see, rather than a subject that only comes up during an outage.
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.
The cutover, DNS and validation work is a distinct engagement.
Server migration with a tested cutoverRecurring outages and 5xx errors are a diagnosis problem before they are an operations problem.
Platform reliabilityCapacity design, topology and scaling decisions are a different brief from ongoing operations.
Infrastructure engineeringXenForo communities under managed infrastructure are covered separately.
Managed XenForo hostingYes, and that is most of what we take on. Onboarding starts from whatever state the environment is in — including no documentation at all — and the first deliverable is an inventory of what actually exists. We would rather describe the environment accurately than assume it matches how it was originally specified.
We are deliberately not listing them here. A support matrix that has not been verified against what we can actually operate is the easiest kind of untrue claim to publish, and the cost of getting it wrong lands on you at the point you need help. We will tell you plainly, for your specific environment, what we can take responsibility for and what we cannot.
Yes. We start with an inventory and an access review, then establish a tested restore path before changing anything. The most common finding is that the previous setup is broadly sound but undocumented and untested — which is a different problem from a bad configuration, and cheaper to fix.
They are set per engagement rather than published as a standard, because a practice of this size cannot honestly staff a round-the-clock guarantee. What is agreed is written into the shared-responsibility matrix alongside the escalation path, so there is no ambiguity at the moment you need it — which is the only moment it matters.
No to both. We operate environments on infrastructure you or your provider own, which means you keep the commercial relationship and the ability to move. We do not mark up hosting, and we are not a reseller of anybody's platform.
You receive a handover pack: the current inventory, the change log, the runbooks, and the credentials returned to your control. The environment should be in a state another competent operator can pick up, because everything we did was documented as we went rather than reconstructed at the end.
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.