Summer Cloud
Summer Cloudfor every machine.
Sync scenes, scripts, settings, and big binary assets without setting up Git or paying LFS-style bandwidth bills. Summer Cloud is built for desktop creators and the agents working beside them.
What Summer Cloud keeps in sync
In plain words
Your game project, on every machine, always the same.
A game is more than code. It is models, textures, music, scenes, settings. Those files are big, they change constantly, and they break the moment two machines disagree about them. Summer Cloud keeps one true copy of your whole project and makes every machine match it.
Save, and it is everywhere
Work on your desktop, open the laptop, keep going. Push from one machine, pull on another, and the project arrives byte for byte identical. No zip files, no drive links, no "which version is this".
Nothing gets lost
Every push becomes a numbered version you can go back to. Before Summer Cloud changes anything on your disk, it takes a local checkpoint first. Deleting something by accident stops being scary.
Your files stay yours
There is no separate viewer to learn. Your project folder IS the interface: files sync in place, the engine picks them up, and summer cloud status tells you what changed. Storage is private to your account.
What it is
A full-project sync layer for games, not a folder backup.
Whole projects travel
Summer Cloud tracks the project files that make a game run: scenes, resources, scripts, imports, project settings, add-ons, and asset binaries.
Big assets are first-class
Blobs are stored by sha256 in private object storage, so generated models, textures, audio, and packs sync without pretending they are nice text diffs.
Git stays optional
The only Git-visible cloud file is the tiny project binding. Solo creators can sync without Git, and Git teams avoid cloud state merge fights.
Agents get the same surface
Every operation is exposed as an idempotent HTTP call, CLI command, and MCP tool so an agent can operate the same system a human uses.
How it works
Hash locally, transfer once, commit the manifest.
1. Bind the project
Run the cloud init command. Summer writes a small project binding and creates an empty cloud head for the project.
2. Push only missing bytes
The CLI hashes the tracked tree, asks the API which blobs are already present, uploads missing blobs to signed staging URLs, then commits a manifest.
3. Pull and verify
On another machine, Summer downloads the manifest, presigns the needed blobs, verifies each sha256, and applies changes with local checkpoints.
Agent operations
Documented HTTP calls, mirrored by CLI and MCP.
Summer Cloud is designed so an agent with a token and the operations doc can create projects, check blobs, upload, commit, hydrate, restore versions, ingest assets, and inspect usage without a hidden UI step.
HTTP API
Routes under /api/cloud/ cover projects, blob check/presign/complete, manifest commits, versions, restore, ingest, collaborators, and usage.
CLI commands
summer cloud init, push, pull, status, restore, and conflicts are the human and automation entry points.
MCP tools
The same operations are exposed to Claude Code, Codex, Cursor, Windsurf, and other MCP clients through the Summer agent layer.
Content-addressed sync
Every file points to verified bytes, and every project state points to a manifest version.
Recovery
Destructive syncs get a paper trail.
Summer Cloud never relies on wall clocks or last-write-wins. Server manifest versions decide ordering, local checkpoints protect unpushed work, and conflicts preserve both sides' bytes.
Version history
Every accepted manifest version is retained within policy, and restoring creates a new version instead of rewriting the old one.
Local checkpoints
Before a pull modifies or deletes existing files, the CLI writes a full-tree checkpoint into the project's local SummerGit repo.
Conflict preservation
When two machines edit the same path, the accepted remote file lands at the normal path and the losing local bytes are saved outside the engine-scanned tree.
Pricing
Storage rides the existing Summer plans.
Pulls and reads stay available even if an account is over quota or read-only. Storage limits follow the plan tiers, with library/template blobs excluded from user quota.
Free
Enough to keep small experiments and jam projects backed up.
Basic
Room for a first real project synced across machines.
Pro
For creators syncing active projects across desktop machines.
Pro+
For larger projects with generated models, audio, and texture libraries.
Ultra
For heavy asset work and multi-project production use.
FAQ
Practical answers.
- Is Summer Cloud a Git replacement?
- It replaces the part of Git that is painful for many game creators: keeping the whole project and its assets on more than one machine. Git is still useful for text review and branch workflows, but Summer Cloud does not require it.
- Does it sync large generated assets?
- Yes. Summer Cloud stores asset bytes as content-addressed blobs and syncs them through presigned object-storage URLs instead of pushing asset bytes through the web app.
- Can an agent operate it?
- Yes. The API is intentionally documented as an agent surface. The CLI and MCP tools mirror the same operations so agents can push, pull, inspect status, restore, and ingest assets.
- What happens during conflicting edits?
- The server commit that wins the CAS race becomes the canonical path. The losing local bytes are saved as a conflict set and can be restored later. The docs never call this last-write-wins because clocks are not trusted.
- What happens if I run out of storage?
- Writes and ingest can be blocked, but reads, pulls, manifest access, and restore remain available. Delinquency does not delete project data.
Keep the whole game moving with you.
Install Summer, initialize cloud sync in a project, and let your desktop app, CLI, and agent share the same recoverable project state.