Cloud-Workspace, der schon an die Pipeline hängt

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.

  • VS Code, JetBrains, RDP, VNC – nicht nur der Browser-Tab
  • iOS bleibt auf macOS in der Pipeline. Die Ubuntu-Box ist die gemeinsame Linux-Basis.

Laptop-Zoo oder dieselbe Box

Jeder sein Gerät

  • Onboarding ist ein Nachmittag Versionen angleichen.

Workspace aus dem Projekt

  • Fertig konfiguriert, dieselbe CI danach.

Lokal oder in der Cloud arbeiten?

Ganz deine Entscheidung – wir geben dir für beide Wege das ideale Setup.

Lokal Setup-App
  • Git & Repos
  • Flutter SDK
  • Node.js
  • Docker

Die Setup-App erkennt Tools und startet alles mit einem Klick.

Cloud Remote-Workspace
  • Ubuntu VM
  • VS Code im Browser
  • Von überall

Fertige Entwicklungsumgebung – kein lokales Setup nötig.

Lokal oder in der Cloud, mit derselben Projektbasis.

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.

Lokale Umgebungen oder Workspaces aus der Plattform

Die Gegenüberstellung zeigt, welche Aufgaben rund um Entwicklungsumgebungen anfallen und wie die Application Platform sie löst.

Aufgabe Mit der Application Platform Manuell aufgesetzt
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.

Was eine Cloud-IDE nicht ist

  • Kein Ersatz fürs Gerät Schwere native Arbeit am iPhone bleibt am Mac. Die Workspace-VM ist die gemeinsame Linux-Basis, nicht der App-Store-Rechner.

Kostenmodell

Workspaces laufen als Teil der Plattform, nicht als separates IDE-Abo neben GitHub.

Ein Workspace startet fertig konfiguriert, statt tagelang eingerichtet zu werden. Ein Workspace startet fertig konfiguriert, statt tagelang eingerichtet zu werden.
Ein Workspace startet fertig konfiguriert, statt tagelang eingerichtet zu werden.

So kommst du zu einer Cloud Entwicklungsumgebung

Vier Schritte vom Projekt zum laufenden Workspace.

  1. Projekt anlegen oder beitreten

    Der Workspace hängt am Projekt. Repository, Struktur und Zugangsdaten sind damit bereits vorhanden.

  2. Workspace starten

    Wähle Ubuntu als Workspace-Betriebssystem (Windows und macOS folgen). iOS-Builds laufen trotzdem in der Pipeline auf macOS-Geräten der Plattform.

  3. Zugriffsweg wählen

    Arbeite mit VS Code im Browser, verbinde deine JetBrains-IDE oder nutze RDP beziehungsweise VNC für eine grafische Sitzung.

  4. Entwickeln und deployen

    Commits laufen in dasselbe Repository wie sonst, die Pipeline übernimmt Test, Build und Deployment.

Häufige Fragen

Muss ich vollständig in der Cloud entwickeln?

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.

Wie greife ich auf einen Workspace zu?

Ü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.

Kann ich iOS-Apps ohne eigenen Mac entwickeln?

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.

Wie bleiben Kundenprojekte getrennt?

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.

Kann ein Agent in einem Workspace arbeiten?

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.

Starte deinen ersten Workspace

Registriere dich kostenlos, lege ein Projekt an und öffne eine fertig konfigurierte Umgebung im Browser.