Summer Cloud
Summer Cloudauf jedem Rechner.
Synchronisiere Szenen, Skripte, Einstellungen und große Binärassets ohne Git-Setup und ohne LFS-artige Bandbreitenrechnung. Summer Cloud ist für Desktop-Creator und die Agents an ihrer Seite gebaut.
Was Summer Cloud synchronisiert
Einfach erklärt
Dein Spielprojekt, auf jeder Maschine, immer identisch.
Ein Spiel ist mehr als Code. Es sind Modelle, Texturen, Musik, Szenen, Einstellungen. Diese Dateien sind groß, ändern sich ständig und gehen kaputt, sobald zwei Maschinen sich über sie uneinig sind. Summer Cloud hält eine wahre Kopie des gesamten Projekts und bringt jede Maschine auf diesen Stand.
Speichern, und es ist überall
Am Desktop arbeiten, das Laptop öffnen, weitermachen. Push auf einer Maschine, Pull auf der anderen, und das Projekt kommt Byte für Byte identisch an. Keine Zips, keine Drive-Links, kein "welche Version ist das".
Nichts geht verloren
Jeder Push wird zu einer nummerierten Version, zu der du zurückkehren kannst. Bevor Summer Cloud etwas auf deiner Festplatte ändert, legt es zuerst einen lokalen Checkpoint an. Versehentliches Löschen verliert seinen Schrecken.
Deine Dateien bleiben deine
Es gibt keinen separaten Viewer zu lernen. Dein Projektordner IST die Oberfläche: Dateien synchronisieren sich an Ort und Stelle, die Engine erkennt sie, und summer cloud status zeigt, was sich geändert hat. Der Speicher ist privat für dein Konto.
Was es ist
Vollständiger Projektsync für Spiele, kein Ordnerbackup.
Ganze Projekte reisen mit
Summer Cloud verfolgt die Dateien, die ein Spiel zum Laufen bringen: Szenen, Ressourcen, Skripte, Imports, Projekteinstellungen, Add-ons und Asset-Binärdateien.
Große Assets sind erstklassig
Blobs werden per sha256 in privatem Objektspeicher abgelegt. Generierte Modelle, Texturen, Audio und Packs synchronisieren, ohne so zu tun, als wären sie hübsche Text-Diffs.
Git bleibt optional
Die einzige für Git sichtbare Cloud-Datei ist die winzige Projektbindung. Solo-Creator synchronisieren ohne Git, und Git-Teams vermeiden Merge-Kämpfe um Cloud-Zustand.
Agents nutzen dieselbe Oberfläche
Jede Operation existiert als idempotenter HTTP-Aufruf, CLI-Befehl und MCP-Tool, sodass ein Agent dasselbe System bedient wie ein Mensch.
So funktioniert es
Lokal hashen, einmal übertragen, Manifest committen.
1. Projekt binden
Führe den cloud init Befehl aus. Summer schreibt eine kleine Projektbindung und legt einen leeren Cloud-Head für das Projekt an.
2. Nur fehlende Bytes pushen
Die CLI hasht den verfolgten Baum, fragt die API, welche Blobs schon existieren, lädt fehlende Blobs auf signierte Staging-URLs hoch und committet dann ein Manifest.
3. Pullen und verifizieren
Auf einem anderen Rechner lädt Summer das Manifest, holt signierte URLs für die nötigen Blobs, verifiziert jedes sha256 und wendet Änderungen mit lokalen Checkpoints an.
Agent-Operationen
Dokumentierte HTTP-Aufrufe, gespiegelt in CLI und MCP.
Summer Cloud ist so entworfen, dass ein Agent mit Token und Operationsdokument Projekte anlegen, Blobs prüfen, hochladen, committen, hydrieren, Versionen wiederherstellen, Assets ingestieren und die Nutzung einsehen kann, ohne versteckten UI-Schritt.
HTTP-API
Die Routen unter /api/cloud/ decken Projekte, Blob check/presign/complete, Manifest-Commits, Versionen, Wiederherstellung, Ingest, Mitwirkende und Nutzung ab.
CLI-Befehle
summer cloud init, push, pull, status, restore und conflicts sind die Einstiegspunkte für Menschen und Automatisierung.
MCP-Tools
Dieselben Operationen stehen Claude Code, Codex, Cursor, Windsurf und anderen MCP-Clients über die Agent-Schicht von Summer zur Verfügung.
Content-adressierter Sync
Jede Datei zeigt auf verifizierte Bytes, und jeder Projektzustand zeigt auf eine Manifest-Version.
Wiederherstellung
Destruktive Syncs behalten einen Wiederherstellungspfad.
Summer Cloud verlässt sich nie auf Uhren oder last-write-wins. Manifest-Versionen des Servers bestimmen die Reihenfolge, lokale Checkpoints schützen ungepushte Arbeit, und Konflikte bewahren die Bytes beider Seiten.
Versionsverlauf
Jede akzeptierte Manifest-Version wird im Rahmen der Richtlinie aufbewahrt, und eine Wiederherstellung erzeugt eine neue Version, statt die alte umzuschreiben.
Lokale Checkpoints
Bevor ein Pull bestehende Dateien ändert oder löscht, schreibt die CLI einen Checkpoint des gesamten Baums in das lokale SummerGit-Repository des Projekts.
Konflikterhaltung
Wenn zwei Rechner denselben Pfad bearbeiten, landet die akzeptierte Remote-Datei am normalen Pfad, und die unterlegenen lokalen Bytes werden außerhalb des von der Engine gescannten Baums gesichert.
Preise
Storage folgt den bestehenden Summer-Plänen.
Pulls und Lesezugriffe bleiben verfügbar, auch wenn ein Konto über dem Kontingent oder schreibgeschützt ist. Die Speichergrenzen folgen den Planstufen; Bibliotheks- und Template-Blobs zählen nicht zum Nutzerkontingent.
Free
Genug, um kleine Experimente und Jam-Projekte gesichert zu halten.
Basic
Platz für ein erstes richtiges Projekt, synchronisiert über mehrere Rechner.
Pro
Für Creator, die aktive Projekte über mehrere Desktop-Rechner synchronisieren.
Pro+
Für größere Projekte mit generierten Modellen, Audio und Texturbibliotheken.
Ultra
Für intensive Asset-Arbeit und Produktion über mehrere Projekte.
FAQ
Praktische Antworten.
- Ersetzt Summer Cloud Git?
- Es ersetzt den Teil von Git, der vielen Spiele-Creators wehtut: das ganze Projekt samt Assets auf mehr als einem Rechner zu halten. Git bleibt für Text-Review und Branch-Workflows nützlich, aber Summer Cloud setzt es nicht voraus.
- Synchronisiert es große generierte Assets?
- Ja. Summer Cloud speichert Asset-Bytes als content-adressierte Blobs und synchronisiert sie über signierte Objektspeicher-URLs, statt Asset-Bytes durch die Web-App zu schieben.
- Kann ein Agent es bedienen?
- Ja. Die API ist bewusst als Agent-Oberfläche dokumentiert. CLI und MCP-Tools spiegeln dieselben Operationen, sodass Agents pushen, pullen, den Status prüfen, wiederherstellen und Assets ingestieren können.
- Was passiert bei widersprüchlichen Änderungen?
- Der Commit, der das CAS-Rennen auf dem Server gewinnt, wird zum kanonischen Pfad. Die unterlegenen lokalen Bytes werden als Konflikt-Set gesichert und können später wiederhergestellt werden. Die Doku nennt das nie last-write-wins, weil Uhren nicht vertraut wird.
- Was passiert, wenn mein Speicher voll ist?
- Schreibvorgänge und Ingest können blockiert werden, aber Lesen, Pulls, Manifest-Zugriff und Wiederherstellung bleiben verfügbar. Zahlungsverzug löscht keine Projektdaten.
Nimm das ganze Spiel mit.
Installiere Summer, initialisiere Cloud-Sync in einem Projekt und lass Desktop-App, CLI und Agent denselben wiederherstellbaren Projektzustand teilen.