Jeder sein Gerät
- Onboarding ist ein Nachmittag Versionen angleichen.
Eine Cloud-IDE, nach der du wieder Actions und einen Hoster suchst, ist nur aufgeschobenes Setup. Der Workspace hier ist dieselbe Box, von der später auch deployed wird.
Ganz deine Entscheidung – wir geben dir für beide Wege das ideale Setup.
Die Setup-App erkennt Tools und startet alles mit einem Klick.
Fertige Entwicklungsumgebung – kein lokales Setup nötig.
Eine Cloud Entwicklungsumgebung lohnt, wenn das Onboarding länger dauert als der erste Commit. Sie lohnt noch mehr, wenn dieselbe Umgebung später baut und ausrollt – sonst hast du nur den Laptop in den Browser verschoben.
Die Gegenüberstellung zeigt, welche Aufgaben rund um Entwicklungsumgebungen anfallen und wie die Application Platform sie löst.
| Aufgabe |
|
|
|---|---|---|
| Onboarding neuer Entwickler | Vollständig abgedeckt: Workspace starten und loslegen, Werkzeuge und Abhängigkeiten sind vorhanden | Nicht angeboten: Setup-Anleitung im Wiki, die selten aktuell ist |
| Gleiche Umgebung im Team | Vollständig abgedeckt: Alle arbeiten auf derselben Grundlage, unabhängig vom eigenen Betriebssystem | Nicht angeboten: Windows, macOS und Linux nebeneinander, mit abweichenden Versionen |
| Zugriffswege | Vollständig abgedeckt: VS Code im Browser, JetBrains, RDP und VNC über stabile Gateway-URLs | Teilweise abgedeckt: Nur lokal, Remote-Zugriff muss selbst aufgebaut werden |
| macOS für iOS-Builds | Teilweise abgedeckt: Pipeline-Builds auf macOS-Geräten der Plattform. Interaktive macOS-Workspaces folgen | Teilweise abgedeckt: Ein Mac pro iOS-Entwickler oder ein geteiltes Gerät mit Wartungsaufwand |
| Trennung von Kundenprojekten | Vollständig abgedeckt: Eigene Umgebung und eigene Zugangsdaten pro Projekt | Nicht angeboten: Alles auf einem Rechner, Abhängigkeiten und Zugänge vermischen sich |
| Rechenleistung für schwere Builds | Vollständig abgedeckt: Der Workspace läuft auf einer Cloud-VM, nicht auf deinem Notebook | Nicht angeboten: Build-Zeiten hängen von der Hardware der einzelnen Person ab |
| Datenbanken einsehen | Vollständig abgedeckt: phpMyAdmin steht für den Zugriff auf Datenbanken bereit | Teilweise abgedeckt: Lokaler Client, VPN oder SSH-Tunnel je nach Umgebung |
| KI-Coding-Agenten betreiben | Vollständig abgedeckt: Agenten laufen im Cloud-Workspace weiter, auch wenn du den Laptop zuklappst | Nicht angeboten: Läuft lokal und endet, sobald der Rechner in den Ruhezustand geht |
| Geräteverlust oder Wechsel | Vollständig abgedeckt: Der Arbeitsstand liegt im Workspace und im Repository, nicht auf dem Endgerät | Nicht angeboten: Neuinstallation und Wiederherstellung auf dem Ersatzrechner |
| Zugriffsrechte auf Umgebungen | Vollständig abgedeckt: Rollen und Projektzugehörigkeit steuern, wer welche Umgebung öffnen darf | Nicht angeboten: Faktisch jeder mit Zugang zum Rechner |
Grün bedeutet vollständig abgedeckt, gelb teilweise, grau nicht vorgesehen. Lokale Entwicklung bleibt möglich, die Setup-App deckt diesen Weg ab.
Stand: 9. September 2026. Die Gegenüberstellung beschreibt typische Abläufe und kann je nach Projekt abweichen. Logos sind Marken der jeweiligen Rechteinhaber und dienen nur der Zuordnung.
Workspaces laufen als Teil der Plattform, nicht als separates IDE-Abo neben GitHub.

Vier Schritte vom Projekt zum laufenden Workspace.
Der Workspace hängt am Projekt. Repository, Struktur und Zugangsdaten sind damit bereits vorhanden.
Wähle Ubuntu als Workspace-Betriebssystem (Windows und macOS folgen). iOS-Builds laufen trotzdem in der Pipeline auf macOS-Geräten der Plattform.
Arbeite mit VS Code im Browser, verbinde deine JetBrains-IDE oder nutze RDP beziehungsweise VNC für eine grafische Sitzung.
Commits laufen in dasselbe Repository wie sonst, die Pipeline übernimmt Test, Build und Deployment.
Nein. Für lokale Arbeit gibt es die Setup-App. Viele Teams nutzen beide Wege parallel: lokal für den Alltag, den Cloud-Workspace für Aufgaben mit besonderen Anforderungen wie iOS-Builds. Beide starten von derselben Projektbasis.
Über stabile Gateway-URLs, die auch nach einem Neustart gleich bleiben. Von dort öffnest du VS Code im Browser, verbindest eine JetBrains-IDE oder startest eine grafische Sitzung per RDP oder VNC. Für Datenbanken steht phpMyAdmin bereit.
Pipeline-Builds ja. iOS-Builds laufen auf macOS-Geräten der Plattform, ohne dass du Hardware anschaffen musst. Eigene macOS-Workspaces zum interaktiven Arbeiten folgen – unter Workspaces wählst du aktuell Ubuntu. Signierung und Store-Uploads nutzen dieselbe Pipeline.
Jedes Projekt hat eine eigene Umgebung mit eigenen Zugangsdaten, Rollen und Projektzugehörigkeit bestimmen den Zugriff. Das ist der Unterschied zu einem Laptop, auf dem sich die Zugänge von acht Kunden ansammeln. Rechteänderungen landen im Audit Log.
Ja, das ist einer der häufigsten Gründe für einen Workspace. Ein Agent mit längeren Aufgaben läuft weiter, während dein Notebook aus ist. Über den MCP-Server bekommt er Projektkontext, die Ergebnisse landen als Commits.
Registriere dich kostenlos, lege ein Projekt an und öffne eine fertig konfigurierte Umgebung im Browser.