Summer Jam #2Participar

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.

Rode no projeto
Sem Git obrigatórioAPI HTTP pronta para agentesRecuperável por design

O que o Summer Cloud mantém em sincronia

CenasScriptsAssetsConfiguraçõesImportsHistórico de versões

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.

manifest v42verified
assets/models/player.glbe3b0c4...
scripts/player.gda1f8d2...
project.godot9c11ab...

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

1 GiB

Suficiente para manter experimentos pequenos e projetos de jam com backup.

Basic

5 GiB

Espaço para um primeiro projeto real sincronizado entre máquinas.

Pro

20 GiB

Para criadores sincronizando projetos ativos entre máquinas desktop.

Pro+

100 GiB

Para projetos maiores com modelos gerados, áudio e bibliotecas de texturas.

Ultra

500 GiB

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.