Summer Cloud
Summer Clouden cada máquina.
Sincroniza escenas, scripts, configuración y assets binarios grandes sin configurar Git ni pagar una factura de ancho de banda estilo LFS. Summer Cloud está hecho para creadores de escritorio y para los agentes que trabajan a su lado.
Lo que Summer Cloud mantiene sincronizado
En palabras simples
Tu proyecto de juego, en todas tus máquinas, siempre igual.
Un juego es más que código. Son modelos, texturas, música, escenas, configuración. Esos archivos son grandes, cambian todo el tiempo y se rompen cuando dos máquinas no coinciden. Summer Cloud mantiene una copia verdadera de todo el proyecto y hace que cada máquina coincida con ella.
Guardas, y está en todas partes
Trabaja en el escritorio, abre el portátil, sigue. Haz push en una máquina, pull en otra, y el proyecto llega idéntico byte a byte. Sin zips, sin enlaces de drive, sin "qué versión es esta".
Nada se pierde
Cada push se convierte en una versión numerada a la que puedes volver. Antes de cambiar algo en tu disco, Summer Cloud crea primero un checkpoint local. Borrar algo por accidente deja de dar miedo.
Tus archivos siguen siendo tuyos
No hay un visor aparte que aprender. Tu carpeta de proyecto ES la interfaz: los archivos se sincronizan en su lugar, el motor los detecta, y summer cloud status muestra qué cambió. El almacenamiento es privado de tu cuenta.
Qué es
Una capa de sincronización de proyecto completo para juegos, no un backup de carpeta.
Los proyectos viajan enteros
Summer Cloud sigue los archivos que hacen funcionar un juego: escenas, recursos, scripts, imports, configuración del proyecto, add-ons y binarios de assets.
Los assets grandes son primera clase
Los blobs se guardan por sha256 en almacenamiento privado de objetos, así que modelos generados, texturas, audio y packs se sincronizan sin fingir que son diffs de texto.
Git sigue siendo opcional
El único archivo de nube visible en Git es la pequeña vinculación del proyecto. Los creadores solo sincronizan sin Git, y los equipos con Git evitan peleas de merge por estado de nube.
Los agentes usan la misma superficie
Cada operación existe como llamada HTTP idempotente, comando de CLI y herramienta MCP, de modo que un agente opera el mismo sistema que usa un humano.
Cómo funciona
Hashea localmente, transfiere una vez, confirma el manifiesto.
1. Vincula el proyecto
Ejecuta el comando cloud init. Summer escribe una pequeña vinculación del proyecto y crea una head de nube vacía para él.
2. Sube solo los bytes que faltan
La CLI hashea el árbol rastreado, pregunta a la API qué blobs ya existen, sube los que faltan a URLs de staging firmadas y luego confirma un manifiesto.
3. Descarga y verifica
En otra máquina, Summer descarga el manifiesto, firma los blobs necesarios, verifica cada sha256 y aplica los cambios con checkpoints locales.
Operaciones de agente
Llamadas HTTP documentadas, reflejadas en CLI y MCP.
Summer Cloud está diseñado para que un agente con un token y el documento de operaciones pueda crear proyectos, comprobar blobs, subir, confirmar, hidratar, restaurar versiones, ingerir assets e inspeccionar el uso sin ningún paso oculto de UI.
API HTTP
Las rutas bajo /api/cloud/ cubren proyectos, check/presign/complete de blobs, commits de manifiesto, versiones, restauración, ingesta, colaboradores y uso.
Comandos de CLI
summer cloud init, push, pull, status, restore y conflicts son los puntos de entrada humanos y de automatización.
Herramientas MCP
Las mismas operaciones están disponibles para Claude Code, Codex, Cursor, Windsurf y otros clientes MCP a través de la capa de agentes de Summer.
Sincronización direccionada por contenido
Cada archivo apunta a bytes verificados, y cada estado del proyecto apunta a una versión del manifiesto.
Recuperación
Los syncs destructivos dejan una ruta de recuperación.
Summer Cloud nunca depende de relojes ni de last-write-wins. Las versiones de manifiesto del servidor deciden el orden, los checkpoints locales protegen el trabajo no subido y los conflictos preservan los bytes de ambos lados.
Historial de versiones
Cada versión de manifiesto aceptada se retiene dentro de la política, y restaurar crea una versión nueva en lugar de reescribir la antigua.
Checkpoints locales
Antes de que un pull modifique o borre archivos existentes, la CLI escribe un checkpoint del árbol completo en el repositorio SummerGit local del proyecto.
Preservación de conflictos
Cuando dos máquinas editan la misma ruta, el archivo remoto aceptado queda en la ruta normal y los bytes locales perdedores se guardan fuera del árbol escaneado por el motor.
Precios
El almacenamiento sigue los planes existentes de Summer.
Los pulls y las lecturas siguen disponibles aunque la cuenta esté sobre la cuota o en modo de solo lectura. Los límites de almacenamiento siguen los niveles de plan, con los blobs de biblioteca y plantilla excluidos de la cuota del usuario.
Free
Suficiente para respaldar experimentos pequeños y proyectos de jam.
Basic
Espacio para un primer proyecto real sincronizado entre máquinas.
Pro
Para creadores que sincronizan proyectos activos entre máquinas de escritorio.
Pro+
Para proyectos más grandes con modelos generados, audio y bibliotecas de texturas.
Ultra
Para trabajo intensivo con assets y producción multiproyecto.
FAQ
Respuestas prácticas.
- ¿Summer Cloud reemplaza a Git?
- Reemplaza la parte de Git que duele a muchos creadores de juegos: mantener el proyecto entero y sus assets en más de una máquina. Git sigue siendo útil para revisión de texto y flujos de ramas, pero Summer Cloud no lo exige.
- ¿Sincroniza assets grandes generados?
- Sí. Summer Cloud guarda los bytes de los assets como blobs direccionados por contenido y los sincroniza mediante URLs firmadas de object storage, en lugar de empujar bytes de assets por la app web.
- ¿Puede operarlo un agente?
- Sí. La API está documentada a propósito como superficie de agente. La CLI y las herramientas MCP reflejan las mismas operaciones, así que los agentes pueden subir, bajar, inspeccionar el estado, restaurar e ingerir assets.
- ¿Qué pasa con las ediciones en conflicto?
- El commit que gana la carrera de CAS en el servidor se convierte en la ruta canónica. Los bytes locales perdedores se guardan como conjunto de conflicto y pueden restaurarse después. La documentación nunca lo llama last-write-wins porque no se confía en los relojes.
- ¿Qué pasa si me quedo sin almacenamiento?
- Las escrituras y la ingesta pueden bloquearse, pero las lecturas, los pulls, el acceso al manifiesto y la restauración siguen disponibles. La morosidad no borra datos de proyecto.
Lleva todo el juego contigo.
Instala Summer, inicializa la sincronización de nube en un proyecto y deja que tu app de escritorio, la CLI y el agente compartan el mismo estado recuperable de proyecto.