Research projects get websites at an awkward moment. The grant funds the work, the team is busy with the work, and the site is needed anyway, so the decision about who looks after the server is made quickly and often by whoever happens to be asking.
That choice shapes security, cost, and the amount of researcher time lost to updates for years afterwards. A clear view of what managed and self-managed setups each involve makes the decision a deliberate one.
A self-managed website leaves the technical care to the project team. Someone installs the software, applies updates, configures backups, monitors the server, and fixes problems at whatever hour they appear. That person may be a research software engineer, a doctoral student with server experience, or an IT officer who handles the project in spare moments. The arrangement gives complete freedom over the setup and complete responsibility for what goes wrong. The difference shows up in everyday tasks as much as in emergencies.
In a managed arrangement, the provider takes on much of that routine work. Depending on the service, it covers server configuration, security patches, backups, and performance tuning, so researchers spend their time on content. Providers differ on where the line sits, and WordPress sites are the most common example in academic projects.
For a clear explanation of how a managed WordPress service divides the work between provider and site owner, read the guide at https://www.jump.bg/en/blog/what-is-managed-wordpress-hosting-en.
Some research sites cannot be managed by anyone else. A project that serves a custom data portal, runs analysis scripts on request, or depends on a specific database engine needs access to the server itself. Software versions must sometimes be pinned to match published results, and a managed platform that upgrades PHP or the database on its own schedule can break a pipeline that reviewers expect to reproduce.
Control also helps with unusual compliance demands. A study that handles sensitive participant data may be required by its ethics board to keep everything on institutional servers, where access logs and encryption settings follow the university's own policies. Cloud virtual servers and dedicated machines suit that pattern, as they provide root access and predictable resources, though the project then owns patching and incident response.
Cost cuts in an unexpected direction. Self-managed hosting looks cheaper on the invoice and can be considerably more expensive once researcher time is counted. An hour spent diagnosing a failed update is an hour not spent on the study, and a postdoctoral researcher's time costs more than almost any hosting plan.
Long-lived experiments raise a separate problem. A web application written for one study may have to keep running for the decade that data-retention rules require, long after its developer has left. Containerising the application and documenting its dependencies helps, as does keeping the code in an institutional repository, but someone still has to patch the underlying operating system.
Patching is the heart of the argument for managed services. Patchstack's State of WordPress Security in 2026 report counted 11,334 new vulnerabilities in the WordPress ecosystem during 2025, with 91 percent of them in plugins. The same report put the median time to first mass exploitation of a new flaw at about five hours. Plugin authors in academic settings are often volunteers, so a reported flaw can wait weeks for a fix.
A project site updated once a quarter by a busy doctoral student cannot keep up with that pace. Managed providers apply core updates and server-level protections continuously, and some add virtual patching that blocks known attacks before plugin authors release fixes. Self-managed teams can reach similar results with automation and monitoring, but the work has to be assigned to a named person and scheduled, not left to goodwill. Ask any provider how quickly it responds to a newly published vulnerability, and request an example from the last quarter.
The differences show up most clearly when the two approaches are set against the same questions. The table below uses the concerns that research teams raise most often when they plan a site that must outlast one funding round.
| Concern | Managed | Self-managed |
|---|---|---|
| Initial setup | Provider configures the environment | Team installs and configures everything |
| Security updates | Applied by the provider, often automatically | Applied by the team on its own schedule |
| Backups | Usually included and restored through a panel | Configured and tested by the team |
| Server control | Limited to what the platform allows | Full, including software versions |
| Staff time | Low after launch | Ongoing and tied to specific people |
| Custom code | Weaker fit for unusual stacks | Strong fit |
| After the grant ends | Easy to hand over or pause | Depends on who still knows the setup |
No row decides the matter alone. A project with a simple public site and a single developer-heavy data service often finds that both columns apply, each to a different part of the work.
Many projects settle on a split. The public website, which carries news, team pages and publications, runs on a managed WordPress service, while data services and analysis tools run on a virtual server the team controls. The split keeps the public face patched without anyone giving up a weekend and leaves custom work where it belongs. Each side needs a named owner and a written record of how it is configured.
Funding ends before research impact does. A site that still attracts readers three years after the final report needs a plan, and managed hosting makes that plan simple, since a low-cost tier can keep the pages online while nobody monitors a server. Ask funders whether they require data and code to be archived in a repository, which would let the website itself shrink to a short landing page.
Write down the exit costs before choosing. Moving a managed site to another host is usually a matter of exporting files and a database, and providers that migrate accounts for free reduce the effort further. Moving a heavily customised server takes days of work by someone who understands it, a cost that belongs in the grant budget beside the hosting fee.