Managed Linux VPS administration
Managed is the least specific word in this market. Here is what is actually covered — the distributions, the stacks, and what patching, backup and monitoring each mean in practice.
A VPS is a server with an owner who is not a system administrator
A virtual server is cheap, capable and entirely unmanaged by default. It arrives with a root login and no patch policy, no backup that has been restored, no monitoring and no record of what was changed. Most of the time that is fine, and then a distribution reaches end of life, a certificate does not renew, or something fills the disk at three in the morning — and the person who has to deal with it is a developer or a business owner rather than a sysadmin.
- Nobody knows which distribution release the server is on or whether it is still supported
- Patches are applied when someone remembers, or after something breaks
- Backups are configured and nobody has restored one
- Nobody would know the site was down until a customer said so
- The server has accumulated changes nobody documented
- Root access is shared or has never been rotated
- Disk, memory or inode usage is not tracked until it causes a failure
- An application needs a specific runtime and the server is configured ad hoc around it
The people who usually bring us this problem
A business running a site on an unmanaged VPS
The server works and nobody is looking after it, and you would like that to stop being true.
A developer who inherited the server as well as the application
You can write the application and you did not sign up to be the system administrator.
Someone who has just had a failure
A disk filled, a certificate lapsed or a patch broke something, and you want the routine established rather than the incident repeated.
What this costs while it goes unfixed
Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.
End of life is the failure that arrives with a date
A distribution release stops receiving security patches on a published date, and nothing announces it. The server keeps running, the site keeps working, and the exposure accumulates silently until it is either noticed or exploited. Knowing the date in advance is the whole of the mitigation.
A backup that has not been restored is a hypothesis
Backups fail in ways that are invisible until they are needed: incomplete sets, a database dump that ran while the database was being written, a snapshot that excluded the uploads directory. The only way to know is to restore one to a working environment and check — which is also the moment retention gets reconsidered.
Access accumulates and is never reduced
Keys added for a contractor, a root password shared once, an account for a tool that was removed. On a VPS the access list is the security boundary, and it grows by addition and shrinks by nothing.
Unmanaged does not mean cheaper, it means deferred
The cost of running a server without administration is not avoided, it is paid at the moment of failure with interest — an outage, a recovery, an emergency and often a migration that could have been planned. The comparison is between a routine and an incident, not between two prices.
Capabilities
Each of these is work we carry out, not an area we advise on.
Coverage stated up front
Which distributions are supported and at which releases, which web stacks are maintained, and what is explicitly out of scope. Stated before the engagement rather than discovered during it, because a managed service whose scope is vague is one where the boundary gets argued about at the worst moment.
Patch and release management
Security patches applied on a schedule, release upgrades planned against end-of-life dates, and the kernel and runtime kept at supported versions. The end-of-life dates for everything installed are tracked so the upgrade is planned rather than reactive.
Access management
Root access reduced to key-based authentication and rotated, individual accounts for anything shared, privileges reduced to necessity, and a record of who has access and why. The access list is reviewed on a schedule rather than left to accumulate.
Backup configuration and verification
Backups covering the whole estate — files, databases and anything the application stores outside both — stored off the server, with retention set against how long a problem can run undetected, and verified by restoring one rather than by observing that the job runs.
Monitoring and alerting
Availability, resource trends, certificate expiry, disk and inode consumption, and the application-level signals that indicate trouble before it becomes an outage. Alerts go somewhere a human will see them, which is a design decision rather than a default.
Firewall and service hardening
Only the ports that need to be open, services bound to the interfaces they should be, and the server's own configuration brought to a documented baseline. Every deviation from that baseline is recorded with its reason.
Application runtime support
The specific runtimes, extensions and configuration an application requires, maintained deliberately rather than patched in by hand. This is where a managed VPS differs from a generic one: the server is configured around what runs on it.
Documented state
What is installed, what was changed and why, what the recovery procedure is, and what to do first if something fails. Written for whoever deals with it next — which may be us, and may be you.
Engineering methodology
The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.
Establish what the server actually is
Distribution and release, installed packages, running services, listening ports, scheduled jobs, user accounts and keys, and where the data lives. Everything else is planned against that inventory, and it is consistently not what anyone expected.
State the end-of-life dates in the assessment
Every component with a support date, and the date it arrives. It converts an invisible risk into a scheduled piece of work, and it is frequently the single most useful thing in the report.
Restore a backup before trusting one
To a working environment, and check that the site and its data come back. Backup configuration is checked afterwards, but the verification is a restore, because that is the only thing that establishes the backups work.
Reduce access before adding controls
Removing what is not needed is a stronger guarantee than configuring what is. Keys that belong to nobody, accounts for departed contractors and shared root credentials are removed first, and the remaining access is then hardened.
Alert on the things that precede failure
Disk and inode trends, certificate expiry, memory and connection counts, and error rates. An alert that fires at the point of failure is a notification; an alert that fires on the trend is what allows the failure to be avoided.
Document deviations, not just the baseline
Anywhere the server differs from a standard build, and why. Undocumented deviation is what makes the next person afraid to change anything, and it is how a server becomes unmaintainable without ever being wrong.
What an engagement produces
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.
Assessment
- Distribution, release and support status, with end-of-life dates for everything installed
- Installed packages, running services and listening ports
- User accounts, keys and the current access position
- Backup configuration, coverage, retention, and whether a restore has been tested
- Monitoring in place and what it would and would not catch
- Every deviation from a standard build, and whether its reason is known
Management
- Security patches applied on a schedule
- Release upgrades planned against their dates
- Access reduced, rotated and reviewed
- Backups verified by restore, with retention set against detection lag
- Monitoring and alerting covering availability, resources and expiry
- Firewall and services reduced to what is needed
Handover
- The documented state of the server and the reason for each deviation
- The recovery procedure, and what to do first
- What is monitored, where alerts go, and what each one means
- What is out of scope, stated plainly
- The next scheduled upgrade and when it needs to start
Architecture and technology
What is covered
- Supported distributions and their releases
- Web server, application runtime, database and cache
- Security patching and release upgrades
- Access management, keys and privilege
- Backups, retention and restore verification
- Availability, resource, certificate and error monitoring
- Firewall configuration and service exposure
- The application's runtime requirements
What is not
- Application code changes — a bug in the site is not a server fault
- Content, editorial or database content work
- Development work on the application itself
- DNS and domain registration, which belong with whoever holds the account
- Guaranteed uptime: a server can be made reliable and cannot be made infallible
- Any provider-side failure — the platform underneath the VPS is theirs
If this is not quite your problem
These overlap at the edges. Sending you to the right page is more useful than having you work it out.
The server is the platform underneath
Serving-path design, capacity and database configuration as engineering.
Server managementThe database is the constraint
Query, index and schema performance work.
MySQL performance optimisationThe server is being replaced
Moving the site between servers while the software stays the same.
Server migrationThe platform is running a community
Managed infrastructure for a production XenForo forum.
Managed XenForo hostingFrequently asked
Which distributions and stacks do you cover?
The page states the coverage rather than leaving it to a conversation, and the principle is supported releases only: a server we manage is on a distribution release that still receives security patches, or on a planned path to one. If your server is on a release past end of life, the first piece of work is the upgrade and the assessment will say so with its date. Where a stack is outside what we maintain, that is stated up front rather than discovered later — a managed service with a vague scope is one where the boundary gets argued about during an incident.
Do you have a case study for this?
No, and we will not borrow one from elsewhere on the site. Our published engagements are forum platforms, a stockbroking platform and a marketplace, and none of them is a general managed-VPS reference a reader could check. What we can describe precisely is the method and the coverage: what is assessed, what is maintained, how backups are verified and what is monitored. If a named reference is a requirement for you, that is a fair thing to need and this is not the page that has one.
What does managed actually include, in one sentence?
Patching on a schedule, access reduced and reviewed, backups verified by restoring one, monitoring that alerts on trends rather than only on failures, and the server's state documented. What it does not include is application code changes — a bug in the site is not a server fault — and no managed service can offer guaranteed uptime, because the platform underneath the VPS is not ours.
Will you take over a server you did not build?
Yes, and that is the normal case. The first piece of work is an assessment rather than a change, because a server that has been administered by hand for years accumulates deviations whose reasons are not recorded, and changing it before understanding it is how a working server is broken. The assessment establishes what is there, what is unsupported and what is undocumented, and the work is then planned against that rather than against a standard build that does not describe your server.
What happens when something fails?
The monitoring alerts on the things that precede failure — disk and inode trends, certificate expiry, memory and connection counts, error rates — so the aim is that most failures are avoided rather than responded to. When something does fail, the recovery procedure is documented in advance and the first actions are written down, because the moment of failure is the worst time to be working out what the server is. Response to an outage is not covered by this arrangement; that is a separate engagement.
Related capabilities and work
Bring us the problem you have not been able to fix
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.