Sobe em segundos
deployEscolha a imagem, defina CPU e RAM, e o container já inicia no node. Sem fila de build, sem passo intermediário.
Merged CloudEscolha a imagem, defina CPU e RAM, clique em criar. Seu bot ou aplicação sobe isolado, com limites que o kernel garante — sem Dockerfile, sem YAML, sem terminal.
10:42:07 container bot-comunidade iniciado
10:42:07 limite aplicado: 512m / 0.4 cpu
10:42:11 gateway conectado, 4 shards
10:44:53 api-webhook escutando na porta 8080
imagens disponíveis nesta versão
O essencial pra colocar uma aplicação no ar. Nada além disso — de propósito.
Escolha a imagem, defina CPU e RAM, e o container já inicia no node. Sem fila de build, sem passo intermediário.
Node.js, Python, Deno, Bun. Seu bot do Discord roda sem você pensar em servidor, porta ou systemd.
CPU e memória com limite aplicado pelo kernel do host. Vizinho barulhento não toma o desempenho que você contratou.
Start, stop e restart num clique. Status e configuração na mesma tela, sem abrir terminal.
Saída do container sob demanda e status atualizado a cada 5 segundos, com CPU e RAM lidos direto do Docker.
Cada criação, start, stop e exclusão fica registrada com o resultado. Dá pra saber o que aconteceu e quando.
Cada plano dá uma cota de vCPU, RAM e SSD pra dividir entre seus projetos como quiser — não é um teto fixo por projeto. Nenhum cartão é cobrado agora: os planos abaixo abrem o cadastro, e a cobrança chega numa fase seguinte.
Em breve — este pool ainda excede o limite técnico por projeto.
Em breve — este pool ainda excede o limite técnico por projeto.
Os números que a API aceita hoje, sem asterisco e sem letra miúda. O losango marca o padrão — e o mesmo desenho vira o controle no formulário de criação.
O storage é informativo nesta fase: o valor é registrado, mas ainda não existe quota reforçada pelo host. Memória e CPU são aplicadas pelo kernel.
Quatro paradas, cada uma com um trabalho só. Não é diagrama de marketing — é como a plataforma está montada.
Next.js · navegador
Você clica em criar, parar ou reiniciar. Nenhum token passa pelo JavaScript — a sessão vive num cookie httpOnly.
NestJS · PostgreSQL
Confere quem é você, se o container é seu e se os números pedidos cabem nos limites. Registra a tentativa antes de seguir.
serviço local
Roda na máquina que hospeda, num usuário separado. Valida o pedido pela segunda vez, com schema fechado.
cgroups do kernel
Cria o container com CPU, memória e teto de processos aplicados pelo kernel. O socket nunca aparece na rede.
Isolamento e validação não ficaram pra depois. Vieram junto com a primeira linha de código.
Nada roda privilegiado, não há bind mount do host, a rede é bridge e o teto de 256 processos barra fork bomb.
Senha com Argon2id e sessão em cookie httpOnly. O código do painel nunca toca no seu token.
Onze repositórios na lista, sempre com tag explícita. Registry arbitrário não entra.
O socket nunca é exposto na rede. Só o agente local fala com ele, num usuário de sistema separado.
Schema fechado na API e de novo no agente. Nenhuma string livre vira configuração de Docker.
Login, logout, falha de acesso e todo o ciclo de vida do container ficam gravados no banco.
Não. Você escolhe a imagem numa lista, define CPU e RAM, e o container sobe. Não há Dockerfile pra escrever, nem YAML, nem terminal — o painel cuida do ciclo de vida inteiro.
Node.js, Python, Deno, Bun, Go, Java (Eclipse Temurin), Ruby, Alpine, NGINX, Redis e PostgreSQL — sempre com tag explícita. A lista é fechada de propósito: registry arbitrário não entra.
São. O limite é aplicado pelo kernel do host, via cgroups do Docker — não é contabilidade de painel. Um container que estoura a RAM contratada é encerrado pelo kernel em vez de tomar memória dos vizinhos, e swap fica desabilitado além do limite.
Fica. Nada roda privilegiado, não existe bind mount do host, a rede é bridge (nunca host), há teto de 256 processos por container contra fork bomb, e no-new-privileges está ligado. O nome no Docker é sempre gerado pela plataforma, então um usuário não alcança o container do outro.
Pode, e é opcional. Se informar, o mapeamento é 1:1 entre host e container. Portas da própria infraestrutura (22, 80, 443, 3000, 3001, 4001 e 5432) são recusadas, assim como uma porta já ocupada por outro container ativo no mesmo node.
Na página do container: status atualizado a cada 5 segundos, CPU e RAM lidos direto do Docker, e logs sob demanda. Start, stop, restart e exclusão saem do mesmo lugar.
Histórico e gráficos de métricas, backup automático e planos pagos. O MVP no ar faz conta, container, ciclo de vida completo, logs e métricas ao vivo — o resto está por vir, e preferimos dizer isso a prometer o que ainda não entregamos.
Sem cartão de crédito.
Imagem, CPU, RAM e variáveis, num formulário só.
Status, logs e métricas ao vivo.