Ein Studienprojekt ist nicht wirklich abgabefertig, wenn die prüfende Person erst ein ZIP herunterladen, den richtigen Ordner finden, Dependencies installieren und raten muss, welche Datei die Anwendung startet.
Für viele Projekte ist ein Live-Link die sauberere Abgabe.
Damit ist nicht gemeint, dass jede Übung eine komplette Cloud-Architektur braucht. Viele Schul-, Hochschul- und Bootcamp-Projekte sind statisch oder lassen sich als statische Dateien bauen: HTML, CSS, JavaScript, Vite, React, Vue, Astro, kleine Browsergames, UI-Übungen, Landingpages, Dashboards und Portfolio-Experimente. Wenn der Browser die fertigen Dateien ohne Serverprozess ausführen kann, eignet sich das Projekt meist für statisches Hosting.
Was Hosting für Studentenprojekte leisten muss
Die Aufgabe ist nicht nur, Dateien irgendwo abzulegen. Der Link muss unter echten Review-Bedingungen funktionieren.
| Anforderung | Was das praktisch bedeutet |
|---|---|
| Einfach zu öffnen | Die Lehrkraft klickt eine URL, keinen ZIP-Anhang. |
| Vollständige Assets | CSS, Bilder, Fonts, JavaScript, JSON und Build-Ordner laden von der öffentlichen URL. |
| Gerätecheck | Das Projekt öffnet sich auch außerhalb des eigenen Laptops. |
| Klare Abgabe | Die Startseite erklärt kurz, was geprüft werden soll. |
| Portfolio-Nutzung | Derselbe Link kann später im Lebenslauf, Portfolio, GitHub README oder in einer Praktikumsbewerbung stehen. |
| Wiederherstellung | Eine kaputte Aktualisierung kann ersetzt oder zurückgerollt werden, ohne den öffentlichen Link neu zu erklären. |
"Bei mir lokal funktioniert es" reicht deshalb nicht. Der Link muss bei jemand anderem funktionieren.
Welche Projekte passen gut?
Statisches Hosting passt, wenn das Endergebnis aus Dateien besteht, die der Browser direkt laden kann.
| Projekttyp | Guter Upload-Zielordner | Hinweis |
|---|---|---|
| HTML/CSS-Aufgabe | Ordner mit index.html | Bilder, Fonts und CSS-Ordner mit hochladen. |
| JavaScript-Übung | Ordner mit HTML, JS, CSS und Assets | Gut für Rechner, Spiele, Quiz, Todo-Apps, Diagramme und UI-Training. |
| Vite-Projekt | dist nach npm run build | Nicht src hochladen, wenn es um den Live-Link geht. |
| React-Projekt | Build-Ausgabe | Der öffentliche Link sollte kompilierte statische Dateien ausliefern. |
| Vue-Projekt | dist nach dem Build | Routen und Asset-Pfade nach dem Veröffentlichen prüfen. |
| Statisches Portfolio | Portfolio-Ordner oder Build-Ausgabe | Eine kurze Projektübersicht ist besser als nur Screenshots. |
| Hackathon-Frontend | Statische Build-Ausgabe | API und Backend getrennt betreiben, wenn die Demo davon abhängt. |
Statisches Hosting führt kein PHP, Java, Python, Ruby, keine Datenbankserver, Hintergrundjobs oder Auth-Server aus. Das Frontend kann trotzdem statisch veröffentlicht werden, aber Backend und Datenbank gehören auf eine passende Backend-Plattform.
Warum viele zuerst an GitHub Pages denken
GitHub Pages ist naheliegend, weil viele Kurse ohnehin GitHub verwenden. Die GitHub-Dokumentation beschreibt Pages als Möglichkeit, eine Website über sich selbst, eine Organisation oder ein Projekt direkt aus einem Repository zu hosten. Für Entwicklerprojekte, bei denen der Code sauber im Repository liegt, ist das oft sinnvoll.
Trotzdem ist ein Repository-first-Prozess nicht immer die schnellste Abgabe:
- Das Projekt kommt aus einem heruntergeladenen Template, einem AI-Export oder einem Designkurs-Ordner.
- Der Live-Link wird gebraucht, bevor das Repository aufgeräumt ist.
- Für die erste Demo zählt das Ergebnis, nicht die Commit-Historie.
- Der fertige Ordner entsteht erst nach einem Build und ist nicht identisch mit dem Source-Ordner.
- Ein Teammitglied soll veröffentlichen können, ohne Besitzer des Repositories zu sein.
Cloudflare Pages dokumentiert Direct Upload für vorgebaute Assets und Uploads vom lokalen Computer. Firebase Hosting spricht im deutschen Auftritt von schnellem und sicherem Hosting für Webanwendungen. Der Punkt ist: Für Studentenprojekte gibt es mehr als einen vernünftigen Weg zu einer öffentlichen URL.
Ein sauberer Ablauf für die Abgabe
Nehmen Sie den kleinsten Prozess, der einen verlässlichen Link erzeugt.
- Projekt lokal fertigstellen.
- Den echten Veröffentlichungsordner bestimmen.
- Vollständigen Ordner oder ZIP hochladen.
- Den generierten HTTPS-Link in einem privaten Browserfenster öffnen.
- Auf dem Smartphone oder in einem zweiten Browser testen.
- Den Link in der Abgabe eintragen.
- Den Link später im Portfolio verwenden, wenn das Projekt vorzeigbar ist.
Der zweite Schritt ist der wichtigste. Viele fehlerhafte Abgaben entstehen, weil der falsche Ordner hochgeladen wurde.
| Stack | Meistens veröffentlichen | Meistens nicht veröffentlichen |
|---|---|---|
| HTML/CSS/JS | Ordner mit index.html | Nur index.html ohne Assets |
| Vite | dist | src, node_modules |
| React Static Build | build oder Framework-Ausgabe | Ungebauter Source-Ordner |
| Vue | dist | Projektwurzel mit nur Quellcode |
| Astro | dist | Content- oder Source-Ordner vor dem Build |
| Next Static Export | out | Eine serverseitige App, die einen Node-Prozess braucht |
Wenn unklar ist, welcher Ordner richtig ist, suchen Sie nach index.html plus kompilierten Assets. Danach lokal mit einer statischen Vorschau öffnen, bevor Sie hochladen.
Was auf die Startseite gehört
Ein Projektlink sollte nicht erklärungsbedürftig sein.
Fügen Sie oben eine kurze Einordnung hinzu:
| Feld | Beispiel |
|---|---|
| Projektname | Weather Dashboard |
| Kurs oder Event | Frontend-Abschlussprojekt, Sommersemester 2026 |
| Tech-Stack | HTML, CSS, JavaScript, OpenWeather API |
| Was geprüft werden soll | Stadt suchen, Einheiten wechseln, responsive Layout ansehen |
| Bekannte Grenzen | Demo-API-Key ist rate-limitiert; kein Login-System |
Das hilft bei der Bewertung und später bei Bewerbungen. Niemand sollte erst das Repository lesen müssen, um den Zweck des Projekts zu verstehen.
Häufige Fehler vor der Abgabe
Die meisten kaputten Projektlinks scheitern an einfachen Dingen.
| Symptom | Wahrscheinliche Ursache | Lösung |
|---|---|---|
| Startseite zeigt 404 | index.html liegt nicht im Deployment-Root | Den Ordner hochladen, der index.html direkt enthält. |
| CSS fehlt | Lokale oder absolute Dateipfade | Relative Pfade verwenden und den CSS-Ordner mit hochladen. |
| Bilder funktionieren lokal, aber nicht online | Bildordner fehlt oder Groß-/Kleinschreibung stimmt nicht | Alle Assets hochladen und Logo.png vs. logo.png prüfen. |
| Buttons reagieren nicht | JavaScript-Datei wird nicht gefunden | Devtools auf der Live-URL öffnen und fehlgeschlagene Requests prüfen. |
| React/Vue-Routen geben 404 zurück | Statisches Routing ist nicht passend eingerichtet | Hash-Routing oder Fallback-Verhalten für Client-Routen verwenden. |
| API-Aufrufe schlagen fehl | Backend ist nicht deployed, CORS blockiert oder localhost steht noch im Code | localhost durch eine echte API-URL ersetzen und Backend getrennt hosten. |
Der schnellste Test bleibt simpel: Öffnen Sie den Live-Link auf einem Gerät, das Ihre lokalen Dateien nie gesehen hat.
Wenn das Projekt ein Backend hat
Manche Abgaben sind nicht rein statisch. Sie verwenden Express, Flask, Django, Spring Boot, PHP, Firebase, Supabase, eine Datenbank oder ein Login-System.
Dann sollte die Architektur klar getrennt werden:
| Schicht | Wohin sie gehört |
|---|---|
| Statisches Frontend | DeployPages oder ein anderer Static Host |
| API-Server | Backend-Host, Serverless-Plattform oder Kursumgebung |
| Datenbank | Managed Database oder Hochschulumgebung |
| Secrets | Backend-Umgebungsvariablen, niemals öffentliche Frontend-Dateien |
Laden Sie keine .env-Dateien, privaten Schlüssel, Datenbank-Zugänge oder von der Lehrkraft bereitgestellten Secrets in eine öffentliche statische Website. Alles, was im Frontend liegt, kann im Browser gesehen werden.
Den Link portfolio-tauglich machen
Abgabe und Portfolio liegen nah beieinander. Aus einer Kursarbeit kann ein Nachweis für echtes Können werden, wenn die öffentliche Seite sauber wirkt.
Vor dem Teilen außerhalb des Kurses lohnt sich:
- Eine kurze Beschreibung des Problems und der eigenen Lösung.
- Ein klarer Hinweis, welche Teile selbst gebaut wurden.
- Screenshots nur dann, wenn die Live-Demo Kontext braucht.
- Ein Link zum Source Code, wenn das Repository vorzeigbar ist.
- Ein Hinweis auf Demo-Daten, deaktivierte Funktionen oder API-Limits.
- Später eine eigene Domain, wenn das Projekt Teil eines ernsthaften Portfolios wird.
Ein Studienprojekt muss nicht wie ein fertiges SaaS-Produkt klingen. Ehrliche Einordnung wirkt besser als große Behauptungen.
Wo DeployPages hilft
DeployPages passt, wenn zuerst ein funktionierender HTTPS-Link gebraucht wird.
Sie können einen statischen Ordner, ein ZIP, ein HTML-Projekt, Build-Ausgaben, eine AI-generierte Seite, ein PDF, ein kleines Spiel, eine Lebenslaufseite oder ein Portfolio-Experiment direkt aus dem Browser veröffentlichen. Wenn das Projekt wichtiger wird, kann derselbe Weg später eigene Domains, Analytics, Passwortschutz, Rollback und CLI-Deploys aufnehmen.
Für den Einstieg gibt es die Seite Student Hosting. Für einfache HTML-Projekte ist die HTML-Deployment-Anleitung der passendere Walkthrough. Für Bewerbungen und Arbeitsproben sind auch Resume Hosting und Portfolio Hosting relevant.
Checkliste vor dem Einreichen
Vor dem Einfügen des Links in Moodle, Canvas, Google Classroom, eine E-Mail oder ein Formular:
index.htmloder der statische Einstiegspunkt liegt im Deployment-Root.- CSS, JavaScript, Bilder, Fonts, JSON und generierte Assets sind enthalten.
- Der Link öffnet sich in einem privaten Browserfenster.
- Der Link öffnet sich auf einem Smartphone.
- Die Startseite erklärt Projekt, Kurs, Stack und Review-Pfad.
- Keine Secrets, Tokens, privaten Daten oder persönlichen Dokumente liegen in den öffentlichen Dateien.
- Backend-Abhängigkeiten sind dokumentiert und separat gehostet.
- Eingereicht wird die Live-URL, nicht ein lokaler Pfad oder Dashboard-Link.
Diese kurze Prüfung verhindert die Fehler, die kurz vor der Deadline am meisten Zeit kosten.