
Summer Cloud
Summer Cloudem toda máquina.
Sincronize cenas, scripts, configurações e assets binários grandes sem configurar Git nem pagar uma conta de banda no estilo LFS. O Summer Cloud foi feito para criadores no desktop e para os agentes que trabalham ao lado deles.
O que o Summer Cloud mantém em sincronia
Em palavras simples
Seu projeto de jogo, em todas as máquinas, sempre igual.
Um jogo é mais que código. São modelos, texturas, música, cenas, configurações. Esses arquivos são grandes, mudam o tempo todo e quebram quando duas máquinas discordam sobre eles. O Summer Cloud mantém uma cópia verdadeira do projeto inteiro e faz cada máquina ficar igual a ela.
Salvou, está em todo lugar
Trabalhe no desktop, abra o notebook, continue. Faça push em uma máquina, pull em outra, e o projeto chega idêntico byte a byte. Sem zips, sem links de drive, sem "qual versão é essa".
Nada se perde
Cada push vira uma versão numerada para a qual você pode voltar. Antes de mudar qualquer coisa no seu disco, o Summer Cloud cria um checkpoint local. Apagar algo sem querer deixa de ser assustador.
Seus arquivos continuam seus
Não há um visualizador separado para aprender. Sua pasta de projeto É a interface: os arquivos sincronizam no lugar, a engine os reconhece, e summer cloud status mostra o que mudou. O armazenamento é privado da sua conta.
O que é
Uma camada de sincronização de projeto completo para jogos, não um backup de pasta.
Projetos inteiros viajam
O Summer Cloud acompanha os arquivos que fazem um jogo funcionar: cenas, recursos, scripts, imports, configurações do projeto, add-ons e binários de assets.
Assets grandes são prioridade
Os blobs são armazenados por sha256 em storage privado de objetos, então modelos gerados, texturas, áudio e packs sincronizam sem fingir que são diffs de texto.
Git continua opcional
O único arquivo de nuvem visível no Git é a pequena vinculação do projeto. Criadores solo sincronizam sem Git, e times com Git evitam brigas de merge de estado de nuvem.
Agentes usam a mesma superfície
Cada operação existe como chamada HTTP idempotente, comando de CLI e ferramenta MCP, então um agente opera o mesmo sistema que um humano usa.
Como funciona
Hasheie localmente, transfira uma vez, confirme o manifesto.
1. Vincule o projeto
Rode o comando cloud init. O Summer grava uma pequena vinculação do projeto e cria uma head de nuvem vazia para ele.
2. Envie só os bytes faltantes
A CLI hasheia a árvore rastreada, pergunta à API quais blobs já existem, envia os que faltam para URLs de staging assinadas e então confirma um manifesto.
3. Baixe e verifique
Em outra máquina, o Summer baixa o manifesto, assina os blobs necessários, verifica cada sha256 e aplica as mudanças com checkpoints locais.
Operações de agente
Chamadas HTTP documentadas, espelhadas por CLI e MCP.
O Summer Cloud foi desenhado para que um agente com um token e o documento de operações consiga criar projetos, checar blobs, enviar, confirmar, hidratar, restaurar versões, ingerir assets e inspecionar uso sem nenhum passo escondido de UI.
API HTTP
As rotas em /api/cloud/ cobrem projetos, check/presign/complete de blobs, commits de manifesto, versões, restauração, ingestão, colaboradores e uso.
Comandos de CLI
summer cloud init, push, pull, status, restore e conflicts são os pontos de entrada humanos e de automação.
Ferramentas MCP
As mesmas operações ficam disponíveis para Claude Code, Codex, Cursor, Windsurf e outros clientes MCP pela camada de agentes do Summer.

Sincronização endereçada por conteúdo
Cada arquivo aponta para bytes verificados, e cada estado do projeto aponta para uma versão do manifesto.
Recuperação
Syncs destrutivos deixam rastro de recuperação.
O Summer Cloud nunca depende de relógios nem de last-write-wins. As versões de manifesto do servidor decidem a ordem, checkpoints locais protegem trabalho não enviado e conflitos preservam os bytes dos dois lados.
Histórico de versões
Cada versão de manifesto aceita é retida dentro da política, e restaurar cria uma nova versão em vez de reescrever a antiga.
Checkpoints locais
Antes de um pull modificar ou apagar arquivos existentes, a CLI grava um checkpoint da árvore inteira no repositório SummerGit local do projeto.
Preservação de conflitos
Quando duas máquinas editam o mesmo caminho, o arquivo remoto aceito fica no caminho normal e os bytes locais perdedores são salvos fora da árvore escaneada pela engine.
Preços
Storage acompanha os planos existentes do Summer.
Pulls e leituras continuam disponíveis mesmo com a conta acima da cota ou em modo somente leitura. Os limites de storage seguem os níveis de plano, com blobs de biblioteca e template fora da cota do usuário.
Free
Suficiente para manter experimentos pequenos e projetos de jam com backup.
Basic
Espaço para um primeiro projeto real sincronizado entre máquinas.
Pro
Para criadores sincronizando projetos ativos entre máquinas desktop.
Pro+
Para projetos maiores com modelos gerados, áudio e bibliotecas de texturas.
Ultra
Para trabalho pesado com assets e produção multiprojeto.
FAQ
Respostas práticas.
- O Summer Cloud substitui o Git?
- Ele substitui a parte do Git que dói para muitos criadores de jogos: manter o projeto inteiro e seus assets em mais de uma máquina. O Git continua útil para revisão de texto e fluxos de branch, mas o Summer Cloud não o exige.
- Ele sincroniza assets grandes gerados?
- Sim. O Summer Cloud armazena os bytes dos assets como blobs endereçados por conteúdo e os sincroniza por URLs assinadas de object storage, em vez de empurrar bytes de asset pelo app web.
- Um agente consegue operá-lo?
- Sim. A API é documentada de propósito como superfície de agente. A CLI e as ferramentas MCP espelham as mesmas operações, então agentes podem enviar, baixar, inspecionar status, restaurar e ingerir assets.
- O que acontece em edições conflitantes?
- O commit que vence a corrida de CAS no servidor vira o caminho canônico. Os bytes locais perdedores são salvos como conjunto de conflito e podem ser restaurados depois. A documentação nunca chama isso de last-write-wins, porque relógios não são confiáveis.
- O que acontece se eu ficar sem storage?
- Escritas e ingestão podem ser bloqueadas, mas leituras, pulls, acesso a manifesto e restauração continuam disponíveis. Inadimplência não apaga dados de projeto.
Mantenha o jogo inteiro indo com você.
Instale o Summer, inicialize a sincronização de nuvem em um projeto e deixe o app desktop, a CLI e o agente compartilharem o mesmo estado recuperável de projeto.