Shared hosting gives a student a managed slice of a web server — files, databases and applications on infrastructure someone else administers — while a cloud lab gives them whole machines they control themselves. The split follows the syllabus: if students are building and publishing websites (HTML, PHP and MySQL, WordPress, portfolios), hosting accounts are the right tool; if the subject is the system itself (server administration, networking, security, custom development stacks), lab environments are. Most computing portfolios need both, they complement rather than replace each other, and the expensive mistake is forcing one to do the other's job.
What are the two models — and what sits between them?
Shared hosting accounts: many isolated accounts on a managed web server, each with files, databases and a control panel, on a fixed stack (typically PHP and MySQL) the platform maintains. The student manages a website; the platform manages everything beneath it. Cloud lab environments: per-student virtual machines or multi-machine networks, deployed from templates, with administrative rights inside — the student manages the system, disposably and in isolation.
Between and around them sit models worth naming so they land in the right bucket: containers and managed application platforms (students deploy applications to a platform — closer to hosting in who owns the infrastructure, closer to labs in stack flexibility) and VDI (standardised remote desktops — a delivery mechanism for desktop software, not a hosting or lab model at all; our VDI guide covers that comparison separately).
Read next: Virtual computer labs versus VDI
What is the real difference in purpose?
Who administers the stack — that single question separates the models. On hosting, the platform owns the operating system, web server and database engine, which is precisely what makes it right for web teaching: students spend their time on sites and applications, not on being reluctant sysadmins, and the platform's governance (isolation, quotas, lifecycle) comes built in. In a lab, the student owns the stack, which is precisely what makes it right for systems teaching: installing, configuring, breaking and securing the machine is the coursework.
Put another way: hosting abstracts the server away because it is not the lesson; labs expose the server because it is. Both abstractions are correct — for different modules.
| Comparison area | Shared hosting account | Cloud lab environment | Container/app platform | VDI desktop |
|---|---|---|---|---|
| Student controls | A website and its content | Whole machines, root access | An application deployment | Nothing structural — a desktop session |
| Stack | Fixed (PHP/MySQL-centred), platform-maintained | Anything the template ships | Per-app runtimes | The standard desktop image |
| Public by default | Yes — publishing is the point | No — private by default | Usually public endpoints | Not applicable |
| Lifespan | The course or programme | The exercise or teaching block | Per deployment | Persistent |
| Breakage model | Reset site from backup | Redeploy from template | Redeploy | IT support ticket |
| Teaches | Building and publishing for the web | Operating systems, networks, security, dev stacks | Modern deployment workflow | Using desktop applications |
Which model suits which subject?
The allocation, subject by subject — the table most curriculum conversations actually need:
The 'depends' row deserves its sentence: a web-development module using MySQL belongs on hosting, where the database serves the site; a database-administration module belongs in a lab, where students run the engine itself. The database modules guide in the cloud labs centre draws that line in full.
| Teaching area | Best-fit model | Why |
|---|---|---|
| HTML, CSS and JavaScript | Hosting | Publishing pages to real URLs is the outcome; no server admin needed |
| PHP and MySQL | Hosting | The native shared-hosting stack — server-side code and databases without server ownership |
| WordPress and CMS teaching | Hosting | One-click installs (where enabled), per-student sites, industry-real workflow |
| Portfolios and client projects | Hosting | Stable public URLs under institutional governance |
| Node.js and Python web stacks | Cloud lab (usually) | Full toolchain control; on hosting these are scoping conversations, not defaults |
| Software-development toolchains | Cloud lab | Root access, arbitrary dependencies, disposable environments |
| Server administration (Linux/Windows) | Cloud lab | The server is the syllabus |
| Networking | Cloud lab | Multi-machine private topologies |
| Cyber security | Cloud lab | Isolated attack/defend environments — never on shared hosting |
| Databases | Depends | Web-facing DB work → hosting; database administration → lab (see below) |
| Operating systems | Cloud lab | Full machine control, disposability |
Read next: Cloud labs for database modules
Why not run everything in cloud labs?
Because for web-publishing coursework, the lab model's flexibility is pure overhead. Give a WordPress marketing cohort virtual machines and every student now administers a Linux server — patching, web-server configuration, security exposure — to do coursework that needed none of it, while the institution loses the governed publishing properties hosting provides for free: stable public URLs with SSL, marking-window durability, per-account quotas and lifecycle.
There is also a duty-of-care point: hosting platforms are maintained by professionals, while a student-administered, internet-facing server is only as patched as its student. Publishing coursework on hosting keeps beginners' public sites on professionally-run infrastructure — the lab model's public exposure is deliberately rare and controlled for exactly this reason.
Why not run everything on hosting?
Because a hosting account is a deliberately fenced garden, and half the computing curriculum needs to leave it. No root access means no operating-systems teaching; a fixed platform stack means no custom toolchains, services or containers; single-account isolation means no multi-machine topologies for networking; and 'please do not attack the shared server' rules out security exercises entirely. Stretching hosting towards these needs — loosening restrictions, granting shell access, special-casing accounts — erodes exactly the governance that made hosting safe, without ever reaching what a lab provides natively.
The tell that a module has outgrown hosting is when requests start being about the platform rather than the site: 'can we get this package installed', 'can students run a service', 'can we open a port'. Each is reasonable — and each is the lab model knocking.
How do the two models coexist well?
Cleanly, when three practices hold. Allocate per module, in writing: the curriculum map says which modules use hosting and which use labs, so the decision is visible and reviewable rather than folklore. Keep one front door per student where possible: students should experience one coherent service — their hosting, their lab environments, their support — not two unrelated products with two logins (institutional SSO across both is most of this battle). Let work flow between them: a student who develops an application in a lab environment and publishes a version on their hosting account is having the correct end-to-end experience — development and publication are different activities, and the models mirror that professionally.
The same student, in the same week, legitimately uses both: a final-year student might break servers in a security lab on Tuesday and update their portfolio site on Thursday. That is the system working.
How do Student Web Host Manager and Cloud Pulse fit this picture?
They are Education Host's two sides of exactly this allocation, built to work together rather than compete: Student Web Host Manager governs the hosting column — real cPanel accounts with Microsoft Entra sign-in, module structure and lifecycle automation — while Cloud Pulse provides the lab column, with lecturer-built templates, isolated environments and multi-machine networks. Where an institution enables it, students see their Cloud Pulse services in the same Student Web Host Manager dashboard as their hosting, which is the one-front-door principle made concrete.
Neither replaces the other, and we would talk you out of trying: the honest deployment question is which modules need which column, at what scale — which is a curriculum-mapping conversation before it is a procurement one.