Crie e hospede suas imagens Docker personalizadas

Sim. A Shard Cloud constrói uma imagem Docker a partir do seu Dockerfile e a executa como aplicação. Envie um arquivo ZIP ou RAR com um Dockerfile na raiz, ou importe um repositório do GitHub, e crie uma aplicação a partir da imagem pronta. O ENTRYPOINT e o CMD da própria imagem definem como ela inicia.

Recomendamos sempre usar o runtime padrão e só usar uma imagem Docker personalizada quando o runtime padrão não consegue fazer o que você precisa. Os runtimes padrão cobrem as linguagens suportadas (Node.js, Python, Go, Java, PHP, .NET, Ruby, Elixir) e sites estáticos: não há Dockerfile para escrever, a plataforma detecta como iniciar sua aplicação e não é preciso o plano Core. Escolha uma imagem Docker personalizada quando precisar de algo que eles não oferecem, como outra linguagem ou versão, pacotes do sistema ou um processo de início definido pelo seu próprio Dockerfile. Em troca, você mantém a imagem base, e imagens personalizadas exigem o plano Core ou superior.

Imagens Docker personalizadas exigem o plano Core ou superior. O Core inclui 2 imagens, o Pro inclui 6 e o Enterprise inclui 20. O plano Basic não inclui. O limite conta todas as suas imagens, qualquer que seja o status do build.

Comece com um arquivo ZIP ou RAR (até 100 MB) ou importe um repositório pela integração com GitHub; o fluxo de criação permite escolher a fonte antes do build. A imagem é sempre construída a partir do seu Dockerfile: não há opção para importar uma imagem pronta de outro registry.

O arquivo deve ser um ZIP ou RAR de até 100 MB com um arquivo chamado Dockerfile na raiz. O dashboard verifica isso antes do envio e mostra o Dockerfile para revisão. Se ele usar /app como WORKDIR, você recebe um aviso, porque os dados da aplicação ficam em /app e qualquer mount ali é apagado.

Sim. Sua fonte (ZIP, RAR ou repositório do GitHub) precisa já incluir um Dockerfile — o dashboard mostra ele em uma etapa de preview antes de criar ou reconstruir a imagem, mas não gera um Dockerfile para você.

A imagem define como a aplicação inicia: o que o ENTRYPOINT e o CMD dela executarem é o que roda. Configurações de linguagem, versão, entrypoint e comando personalizado não se aplicam. Ao criar a aplicação você escolhe a RAM, as variáveis de ambiente e, opcionalmente, um subdomínio web. Os arquivos em /app persistem; o resto do sistema de arquivos da imagem é somente leitura.

Quando a imagem estiver com status Pronta, abra Imagens Docker no dashboard e escolha Criar app na imagem. Você pode criar várias aplicações a partir da mesma imagem. Depois, as configurações de Runtime da aplicação mostram a imagem usada, com logs, atualização e rebuild pelo GitHub.

Sim. Escolha Atualizar imagem no card e envie um novo contexto de build; a imagem mantém o mesmo ID. Ou vincule um repositório do GitHub e escolha uma branch para que cada push inicie um rebuild. Um rebuild é recusado enquanto a imagem já está em build.

Não. O rebuild atualiza apenas a imagem. As aplicações que a usam continuam na versão do último deploy até você reiniciá-las ou fazer um novo deploy.

Excluir uma imagem também exclui todas as aplicações criadas a partir dela, por isso o dashboard pede que você digite o nome da imagem para confirmar. Não é possível excluir uma imagem enquanto ela está em build.

Leia o guia de imagens Docker personalizadas para ver o fluxo de build, os limites e o rebuild automático pelo GitHub.