Portfolios and client projects are where student hosting meets the outside world, and both need boundaries drawn in advance. Portfolios: students should absolutely publish them on university hosting during study — and should expect to take them elsewhere at graduation, with export guidance, a grace period and (ideally) a personally-owned domain so every shared link survives the move, because teaching infrastructure is not a lifetime hosting commitment. Client projects: real briefs belong on university hosting during the module, under written agreements that settle ownership, domains, credentials, personal data and handover before work begins — and production hosting for a live client belongs with the client, not the university, once the module ends.
Can students publish portfolio sites on university hosting?
They should — a portfolio is the single highest-value thing most students ever put on their hosting account. Published throughout the course rather than assembled in panic before finals, it accumulates assessed work into a live, linkable body of evidence: exactly what placement applications and graduate interviews ask for, on an institution-branded URL that lends credibility while they study.
Course teams can do more than permit this — build it in: a portfolio thread through the programme (add each term's best piece), URL-on-CV guidance, and peer showcase sessions all convert hosting from coursework plumbing into employability infrastructure. The web-courses guide covers the curriculum side; this guide owns what happens at the edges — graduation, and clients.
Read next: Web hosting for web-design and development courses
Should portfolio sites remain online after graduation?
For a stated grace period, yes; indefinitely, no — and the honest reasoning helps everyone plan. Graduate sites left on teaching hosting become unmaintained public applications (the security guide's abandoned-site problem), carry personal data past any teaching purpose, and quietly convert coursework infrastructure into an open-ended alumni service nobody budgeted. But a hard stop on results day punishes students at exactly the moment their portfolio matters most — mid job hunt.
The fair pattern: pre-graduation guidance delivered while students still read university email ('here is how to take your portfolio with you'), a defined grace period after award, a working export route, and a stated destination. For Education Host institutions, that destination has a published option: Alumni Hosting exists for graduates who want to keep a web presence after teaching accounts close — alongside the universal answer, a personally-owned domain and commercial hosting.
Read next: What happens to student websites after a course ends?
How does a personally-owned domain ease graduation?
It decouples the address from the infrastructure. A finalist who registers their own domain and points it at their university-hosted portfolio has a professional URL for applications — and at graduation, moving the portfolio is invisible to the world: export the site, host it anywhere, re-point the domain, and every CV link keeps working. The institutional subdomain could never promise that; the personally-owned name does it by construction.
This belongs in final-year guidance as a concrete recommendation (register your name, connect it where the deployment supports custom domains, before you graduate), and it teaches the portability lesson — names you own outlive services you use — that the domains guide covers mechanically.
Should client projects use university infrastructure at all?
During the module, yes — that is what makes client briefs teachable: the build and staging happen on student hosting under module governance, where lecturers can see progress, assessment can freeze a submission copy, and the university's controls (isolation, backups, lifecycle) protect everyone including the client. A client project scattered across whoever's personal hosting was cheapest is ungovernable and unmarkable.
The boundary is production, after: a live site the client depends on does not belong on teaching infrastructure past the module's end. University hosting has teaching lifecycles (suspension at block end), teaching support hours and teaching acceptable-use terms — none of which a real organisation's website should rest on. 'We build it here, you host it there, handover is part of the assessment' is the sustainable arrangement, and it is kindest stated in the initial agreement rather than discovered at the deadline.
Who owns a client project's domain, content and code?
Whatever the written agreement says — which is why there must be one, even a single page, before work starts. The questions it settles: the domain (registered by the client, in the client's name, always — a client site on a domain a student registered personally is a future hostage situation); the content (the client's — they supplied it or commissioned it); the code and design (per the module's IP norms — commonly the client gets rights to use the delivered work; the student keeps the right to show it in their portfolio); and the university's role (venue and educator, not agency or long-term host).
The portfolio clause deserves its sentence in every agreement: students will want to show the work, clients occasionally object late, and one line agreed early ('the student may present this project in their portfolio') prevents the dispute. Where a client wants confidentiality, that is decided before the brief is accepted, not after the build.
How should handover to the client work?
As an assessed deliverable, because handover is a professional skill and treating it as one solves the logistics free. A complete handover package: the site export (files and database), deployment documentation ('how to put this on your hosting'), an account inventory (what services the project uses, in whose name), credentials transferred securely and then rotated, the domain confirmed in the client's control, and a short maintenance briefing — what needs updating, how often, and what happens if it is neglected (the honest WordPress conversation).
The university-side close matches it: the staging copy on student hosting is frozen for assessment, then follows the module's retention lifecycle; nothing keeps serving the client from teaching infrastructure. Modules that mark the handover package report the same thing: clients stop phoning the department in November.
How should client credentials and personal data be handled?
With more care than any other coursework, because this is where student work touches other people's obligations. Credentials: anything the client shares (existing hosting, social accounts, service logins) is stored and transmitted securely, never committed to repositories, shared within the team on a need-to-use basis, and rotated at handover — the group-projects credential discipline with third-party stakes. Better still, structure briefs so students rarely need the client's own credentials at all: build on university staging, hand over an export.
Personal data: a client site can involve real people's data (customer lists, testimonials, contact-form submissions), and coursework involving it engages the university's data-protection framework — module design should minimise it (dummy data for builds, real data only at handover on the client's own infrastructure), and anything unavoidable gets the data-protection team's eyes before, not after. The security guide's rules apply throughout; this is the context where they stop being theoretical.
Read next: Student web-hosting security and abuse management
How should production and assessment copies be separated?
Cleanly, at the deadline, because the two copies serve masters with different clocks. The assessment copy — what the module marks — is frozen at submission (restricted account, export, tagged commit) and lives on the academic retention schedule through marking and appeals. The production copy — what the client uses — is whatever was handed over, lives on the client's infrastructure, and evolves under the client's ownership from handover day.
The separation protects everyone: the student's mark cannot be changed by the client's later edits (or their new agency's rebuild), the client's live site cannot be frozen by an appeals process, and the university's retention machinery never has to reason about a third party's production website. It is the staging-versus-production concept from the courses guide, graduated into the real world.
What support should the university provide — and where does it end?
During the module: normal coursework support to the students (the hosting, resets, the usual routes) — not web agency services to the client; lecturers advise the student team, and the client's relationship is with the project, through the module's structure. After handover: nothing ongoing, by design and by prior statement — the handover package's maintenance briefing exists precisely so the client knows what they own now. A support boundary stated in the initial agreement is a courtesy; one improvised in February is a grievance.
The same clarity serves portfolios: university support covers the hosting while the student is enrolled and through the stated grace period; after that, the portfolio lives wherever the graduate moved it, supported by whoever hosts it now. Clean edges are what let the university be generous inside them.
How does Education Host support portfolios and client work?
The mechanics this guide assumes are standard on Education Host student hosting: portfolio sites run on students' governed cPanel accounts with institution-branded subdomains and SSL; group and client-project work uses the same structures with module oversight through Student Web Host Manager — including the restriction-at-deadline behaviour that separates assessment copies from live work — and lifecycle automation runs the retention stages with notice. For the graduation edge specifically, Alumni Hosting gives Education Host institutions a published answer to 'where does my site go now?', alongside the own-domain route this guide recommends to every finalist.
If client-project modules are part of your portfolio, the agreement and handover patterns above travel well — bring them to a scoping conversation and we will map them onto the platform's structures.