Produção: o app numa instância separada

Na produção, o app vira uma imagem que roda em outra instância da sua conta. Ele continua no ar com a Sandbox desligada, quebrada ou voltada no tempo. O caminho tem dois comandos: nimu iniciar e nimu deploy.

Atualizado em 9 de outubro de 2026

O caminho em quatro passos

1. Na pasta do projeto, rode nimu iniciar. Ele escreve o Dockerfile, o .dockerignore e o nimu.toml.
2. Confira o Dockerfile e defina os segredos de que o app precisa para subir.
3. Rode nimu deploy --novo. Ele constrói a imagem na Sandbox, cria o app de produção e publica a primeira versão.
4. Acompanhe com nimu versoes ID até a versão ficar ativa. Nas próximas vezes, é só nimu deploy.

O agente faz os mesmos passos quando você pede "põe em produção". Nada da Sandbox alcança a instância de produção: mexer na Sandbox não derruba o que está no ar.

Preparar o projeto: nimu iniciar

$ nimu iniciar
Projeto Node.js em /home/dev/projetos/loja (package.json).
  Dockerfile     criado
  .dockerignore  criado
  nimu.toml      criado
A produção roda o contêiner com o app escutando em 0.0.0.0:3000, a saúde em / e 256 MB de memória (nimu.toml).
Atenção: O .env fica fora da imagem (.dockerignore): ponha os segredos da produção com nimu segredo definir.
Confira o Dockerfile e publique: nimu deploy --novo (constrói aqui e manda para a produção; acompanhe com nimu versoes ID).

Ele olha a pasta, reconhece o tipo do projeto e não troca um arquivo que já existe. Rodar de novo mostra "mantido" ao lado de cada um.

Todos os Dockerfiles gerados rodam o app sem root e escutando em 0.0.0.0. Ajuste à vontade: é esse arquivo que o nimu deploy usa.

--tipo

Escolhe o tipo em vez de detectar: auto, node, vite, next, python ou estatico.

--porta N

A porta do app dentro do contêiner, de 1024 a 65535.

--banco

Escreve banco = true no nimu.toml. Veja Banco de dados.

--sobrescrever

Troca o Dockerfile, o .dockerignore e o nimu.toml que já existem.

--pasta P

A pasta do projeto, quando não é a atual.

O arquivo nimu.toml

O nimu.toml diz como a produção roda o app. É o arquivo que o nimu iniciar escreve, com um comentário em cada chave:

# nimu.toml: como a produção da Nimu Cloud roda este app (o nimu deploy lê este arquivo).
# porta: onde o app escuta DENTRO do contêiner, em 0.0.0.0 (não em localhost).
porta = 3000
# saude: o caminho que responde 200 quando o app está pronto (a produção espera até 60 s).
saude = "/"
# memoria_mb: o limite de memória do contêiner, em MB.
memoria_mb = 256
# banco: true dá ao app um Postgres gerenciado na produção (1 GiB por conta, cópias diárias). O app lê a
# variável DATABASE_URL, que a Nimu define sozinha (nimu banco mostra; nimu banco dev sobe um Postgres local
# para desenvolver e grava o DATABASE_URL dele no .env, que nunca vai para o git nem para a imagem).
# banco = true
# migrar: o comando da migração, como lista de argumentos (até 16, cada um até 512 bytes). Roda num contêiner
# avulso da imagem nova, com o DATABASE_URL da produção, antes de cada versão subir; a produção tira uma cópia
# do banco antes. Se falhar, a versão nova não sobe e a antiga segue no ar.
# migrar = ["npx", "prisma", "migrate", "deploy"]

porta

Onde o app escuta dentro do contêiner, de 1024 a 65535.

saude

O caminho que a produção pede para saber se o app subiu. Começa com /. Sem a chave, vale /.

memoria_mb

O limite de memória do contêiner, de 128 a 1024. Sem a chave, vale 256.

banco

true dá ao app um Postgres na produção.

migrar

O comando da migração do banco, como lista de argumentos.

app

O id do app que recebe o projeto. Quem grava é o nimu deploy --novo.

O arquivo aceita só linhas chave = valor, com número, texto entre aspas, true ou false, ou uma lista de textos numa linha. Não usa tabelas entre colchetes. Linha que começa com # é comentário.

O que o app precisa

• Escutar em 0.0.0.0, não em localhost, na porta do nimu.toml.
• Responder no caminho saude em até 60 segundos depois de subir. O esperado é um 200; a produção aceita qualquer resposta que não seja um erro do servidor, da faixa 500.
• Rodar sem root.
• Não depender do arquivo .env nem de nada fora da imagem.

A versão nova só assume depois de responder. Se não responder, a que estava no ar continua.

Publicar uma versão: nimu deploy

Na primeira vez, use --novo: ele cria o app de produção, aberto a todos, e grava o id no nimu.toml. O endereço fica fora do ar até a primeira versão ficar ativa.

$ nimu deploy --novo
A conta ainda não tem instância de produção: esta primeira versão cria uma, que conta na cota da conta.
App novo: https://w4n8t3hd.nimucloud.app (aberto a todos; fora do ar até a primeira versão ficar ativa; o id ficou no nimu.toml).
Construindo a imagem (docker build).
Salvando e comprimindo a imagem (docker save | zstd).
Abrindo a entrega para a Nimu buscar a imagem (porta 9121).
A Nimu criou a instância de produção da conta: producao-kgx5 (1 núcleo, 2 GB de memória, 10 GB de disco, conexão até 100 Mb/s). Ela conta na cota da conta e aparece no painel e no nimu status. Versão 1 de w4n8t3hd na fila (imagem de 87,0 MB). A Nimu busca a imagem, confere e sobe; acompanhe com: nimu versoes w4n8t3hd

O comando volta logo, sem esperar a versão subir. A construção roda em segundo plano: se ela passar de 90 segundos, o comando volta dizendo que a construção continua, e a versão aparece em nimu versoes ID quando a imagem ficar pronta.

Com --esperar, ele acompanha a versão até o fim, por até 10 minutos depois da construção:

$ nimu deploy --esperar
Construindo a imagem (docker build).
Salvando e comprimindo a imagem (docker save | zstd).
Abrindo a entrega para a Nimu buscar a imagem (porta 9121).
Versão 2: a Nimu está buscando a imagem.
Versão 2: preparando (checagem de segurança).
Versão 2: subindo e esperando a saúde responder.
Versão 2: no ar.
No ar: https://w4n8t3hd.nimucloud.app (versão 2).

--novo

Cria um app novo se o nimu.toml ainda não tem um. Rodar de novo não cria outro.

--app ID

Manda a versão para um app que já existe.

--porta, --saude, --memoria

Valem por cima do nimu.toml neste deploy.

--esperar

Espera a versão ficar no ar, falhar ou ser bloqueada.

--pasta P

A pasta do projeto, quando não é a atual.

O que o deploy confere antes de construir

• Se algum arquivo com segredo iria para a imagem, como um .env ou uma chave. Se iria, ele recusa e diz qual: acrescente o arquivo ao .dockerignore com **/ na frente.
• Se a produção está liberada para a conta e se o app cabe na instância de produção.
• Se o Docker da Sandbox responde e se não há outro deploy construindo. É uma construção por vez em cada Sandbox.

A checagem de segurança

Antes de subir, a produção examina a imagem. Se achar um segredo no código, a versão fica bloqueada e a que estava no ar continua. Exemplo de bloqueio:

chave secreta da Stripe em /app/dist/app.js, arquivo que vai para o navegador: qualquer visitante leria; use a chave só no servidor, como segredo (nimu segredo definir), e troque a chave no provedor

Tire o segredo do código, troque a chave que vazou e publique de novo.

As versões

Cada deploy vira uma versão numerada. A produção guarda as 5 mais novas de cada app, contando a que está no ar.

$ nimu versoes w4n8t3hd
Versões de w4n8t3hd (https://w4n8t3hd.nimucloud.app):
  v3   ativa        criada 2026-10-08 15:00, no ar desde 2026-10-08 15:01
  v2   substituida  criada 2026-10-08 10:00, no ar desde 2026-10-08 10:02
  v1   substituida  criada 2026-10-07 17:00, no ar desde 2026-10-07 17:02
Detalhes de uma versão: nimu versoes w4n8t3hd --versao N. Voltar a uma: nimu voltar w4n8t3hd --versao N

nimu versoes ID --versao N mostra uma versão só, com o erro, os bloqueios e as últimas linhas que o app escreveu quando falhou. A lista também mostra a construção que ainda está em andamento na Sandbox.

Voltar a uma versão anterior

$ nimu voltar w4n8t3hd --versao 2
Pedido na fila: w4n8t3hd volta para a versão 2 em instantes (só a imagem; o banco fica como está, e a migração feita não é desfeita). Acompanhe com: nimu versoes w4n8t3hd

O que troca

Só a imagem do app, em segundos.

O que fica como está

O banco de dados e os segredos. A migração que a versão nova fez não é desfeita: para o banco de antes, restaure a cópia feita antes daquele deploy.

Para quais versões

As que já estiveram no ar e ainda estão guardadas: as 4 mais novas, além da que está no ar.

Quem volta

O agente, sem esperar confirmação. Ou você, no painel, na vista Produção, em Voltar para esta versão.

Os logs

nimu logs ID traz as últimas linhas que o app escreveu na produção. Os valores dos segredos saem escondidos.

$ nimu logs w4n8t3hd --linhas 3
servidor no ar em 0.0.0.0:3000
GET / 200
GET /saude 200

--linhas N

Quantas linhas, de 1 a 200. Sem a opção, 200.

--seguir

Continua mostrando as linhas novas, até Ctrl+C.

O app dorme sem visita

Depois de 15 minutos sem nenhuma visita, o app dorme. A visita seguinte acorda o app e espera ele subir. O Postgres dorme e acorda junto.

Se o app demorar a acordar, quem visita vê "O app está iniciando. Tente de novo em alguns segundos."

A instância de produção

A instância de produção é um recurso da conta, incluído na Sandbox, sem fatura própria. Ela aparece no painel, na Visão geral e na vista Produção, e no nimu status.

Quando é criada

Automaticamente, na primeira versão publicada, no primeiro segredo ou no primeiro banco da conta. A resposta do comando que a criou diz o nome e o tamanho.

Tamanho

1 vCPU, 2 GB de memória e 10 GB de disco, com conexão de até 100 Mb/s.

Cota

Uma instância de produção por conta, que leva até 3 apps. O quarto app é recusado antes de construir.

Reiniciar

nimu producao reiniciar, ou o botão Reiniciar no painel. Os apps ficam fora do ar por cerca de 1 minuto e voltam sozinhos. Não perde dados.

Ligar

Se a instância ficar parada, o botão Ligar aparece no painel, na vista Produção e na Visão geral. Os apps voltam em cerca de 1 minuto. A próxima versão publicada também liga a instância.

Apagar

nimu producao apagar, ou o botão Apagar no painel. Só vale com a instância vazia. A próxima versão publicada cria outra.

Remoção automática

Vazia por 1 hora, a instância é apagada pela Nimu. O painel avisa desde quando ela está vazia e quando sai.

Vazia quer dizer sem nenhum app na produção. Um app conta enquanto tiver versão, segredo ou banco lá.

$ nimu producao
Produção: instância producao-kgx5, ligada (1 núcleo, 2 GB de memória, 10 GB de disco, conexão até 100 Mb/s). Apps nela: 1 de até 3.
  w4n8t3hd  na produção  aberto a todos  no ar  https://w4n8t3hd.nimucloud.app  "loja"
Cota da conta: instâncias de produção 1 de 1; apps publicados 2 de 3.
Reiniciar: nimu producao reiniciar (os apps ficam fora do ar por cerca de 1 minuto). Apagar: nimu producao apagar (só com a instância vazia).
$ nimu producao reiniciar --sim
Instância de produção producao-kgx5 reiniciando: os apps dela ficam fora do ar por cerca de 1 minuto e voltam sozinhos. Acompanhe com: nimu producao

Reiniciar e apagar não passam pela confirmação no painel. No terminal, sem --sim, o comando pergunta antes. O agente só apaga a instância quando você pede.

Sem a produção liberada para a conta, os comandos respondem "A produção não está liberada para esta conta. Fale com a Nimu para liberar."

Remover um app da produção

nimu remover ID também vale para o app da produção, e também espera a sua confirmação no painel. Saem junto as versões, os segredos e o banco do app, com as cópias na instância.

A instância de produção fica. Vazia, ela sai sozinha em 1 hora, ou você apaga antes.

No site: Publicar. Nesta documentação: Banco de dados, Segredos e os limites em Limites do teste.