🌐 Diese Seite wurde noch nicht ins Deutsche übersetzt. Portugiesische (BR) Referenz wird angezeigt. Hilf bei der Übersetzung.

✨ Criar App

Você escreve numa frase o que precisa, a IA escreve o aplicativo, e ele aparece rodando ali. Se não ficou como queria, pede a mudança em português e ela edita o app que já existe.

O app fica no seu Launchpad, junto dos nativos, abre em janela, entra na busca do Spotlight e pode ir pro dock. Ele é seu, mora no seu RoqueOS.

Precisa de Modo Servidor (a IA roda no seu servidor) e de pelo menos um agente salvo no Estúdio de IA.

Dois modos. O Página (o padrão, descrito logo abaixo) é um único arquivo HTML isolado, pra uma ferramentinha sem rede e sem banco. O App completo é um app de verdade: backend (Node + Express), banco (Postgres) e site, num projeto multi-arquivo com pastas que fica no ar no seu servidor. Um app completo você ainda abre num editor de código embutido pra ver e editar a árvore de arquivos (na mão ou com a IA, um arquivo por vez) e republicar sem perder os dados. O resto desta seção cobre o Página; o App completo tem a sua.

---

Em qual camada ele roda (modo Página)

No modo Página, um app criado por você não é um app nativo do RoqueOS nem um container Docker. Ele é uma terceira coisa: um documento isolado que o RoqueOS hospeda dentro de uma janela. (O modo App completo é diferente: um projeto multi-arquivo que roda no seu servidor como uma stack Docker de verdade, ver App completo.)

As setas pontilhadas são o ponto principal: o app roda dentro do RoqueOS mas não fala com ele.

---

O que o app pode e o que não pode

Ele pode	Ele não pode
Desenhar qualquer interface (HTML, CSS, JS)	Ler os seus arquivos, notas ou conversas
Guardar estado em memória enquanto está aberto	Guardar dados que sobrevivam ao fechar
Usar canvas, SVG, áudio, animação	Fazer qualquer chamada de rede
Responder a teclado, mouse e toque	Ler dados de outro app criado por você
	Alcançar a sua sessão do RoqueOS ou o seu servidor

Isso não é uma lista de limitações por preguiça, é o desenho. Um app escrito por IA a partir de uma frase não deveria ter acesso à sua vida, e a única forma de garantir isso é ele não ter acesso, não é confiar que não vai usar.

Como o isolamento é imposto

• O app é renderizado por srcdoc com sandbox="allow-scripts" e sem allow-same-origin. Isso dá a ele uma origem opaca: ele não compartilha armazenamento com ninguém, não navega a janela em volta e não enxerga a sua sessão.
• A rede é bloqueada por uma CSP que o RoqueOS injeta como primeira coisa do documento. Uma política assim, entregue no topo, não pode ser desligada por script rodando dentro da caixa. Por isso a IA é instruída a não usar CDN, fonte remota nem imagem por URL: não carregariam.
• Por isso o app é um arquivo só. Vários arquivos exigiriam um endereço para servi-los, e endereço dá origem, e origem devolve ao app tudo o que a caixa isolada tira dele.

---

Integrações disponíveis hoje

Integração	Estado	O que faz
Agentes do Estúdio de IA	✅	Quem escreve o app. Usa o agente e a chave que você já configurou
Launchpad, Spotlight, Dock, Desktop	✅	O app publicado aparece como qualquer app nativo
Sistema de janelas	✅	Abre, redimensiona, minimiza, vai a tela cheia
Firebase (sua conta)	✅	Guarda os seus apps, um documento por app
Arquivos do Finder	⬜ Fase 2	O app poder pedir acesso a uma pasta, com permissão explícita
Compartilhar com um contato	⬜ Fase 3	Emprestar um app para alguém, como já dá para fazer com agentes
Loja pública de apps	❌ Não planejada	Ver a nota no fim

---

Como usar

1. Abra Criar App no Launchpad.
2. Descreva a ferramenta: "um contador de água com meta diária e botão de zerar".
3. Criar app. Em segundos ele aparece rodando ao lado.
4. Ajuste pedindo mudanças: "deixe os botões maiores, adiciona um modo escuro" e Aplicar mudança.
5. Publicar, dê um nome, e ele entra no Launchpad.

Em Meus apps ficam os que você já publicou, com continuar editando, abrir, renomear e excluir. Publicar de novo o mesmo app atualiza ele, não cria uma cópia.

Escolher o modelo, o ícone e o nome

No painel de descrição existe um seletor de Modelo: ele lista os agentes que você salvou, mostrando o modelo de cada um ("Assistente · gpt-4o"), porque o nome do agente sozinho não responde o que você quer saber. A engrenagem ao lado abre Provedores de IA direto, sem sair do que você está construindo.

Ao Publicar, o nome vem sugerido a partir do que a IA escreveu (o título do próprio app), não de um pedaço cortado do seu pedido.

O ícone tem três caminhos, na ordem que se costuma querer:

• Ícones: uma grade escolhida pelo que as pessoas constroem aqui (contador, lista, calculadora, estoque), mais a cor do ladrilho. Instantâneo e sempre funciona.
• Enviar: uma foto ou logo do seu aparelho. A imagem é recortada em quadrado e reduzida antes de ser guardada, então ela não pesa no carregamento do Launchpad.
• Gerar: a IA desenha um ícone a partir do nome do app. O pedido é por fundo transparente, e quando o provedor devolve um fundo chapado mesmo assim, ele é recortado antes de virar ícone, para o símbolo ficar sobre a cor do ladrilho em vez de dentro de um quadrado branco. Precisa de um provedor de imagem configurado em Provedores de IA.

Editar um app publicado traz o ícone junto, então salvar de novo não apaga a sua escolha.

Ver o app sendo escrito

Enquanto a IA trabalha, o código aparece na tela, linha a linha, com a contagem de caracteres. Não é um spinner com uma barra que não quer dizer nada: é o arquivo de verdade sendo escrito.

A prévia só recebe o arquivo quando ele termina. Um documento pela metade piscaria e rodaria scripts quebrados, então o que corre ao vivo é o código, e o app aparece rodando quando está pronto.

Isso exige servidor 1.8.0 ou mais novo. Num servidor mais antigo o app continua sendo gerado normalmente, só sem a parte de assistir.

A IA confere antes de te entregar

Quando o app fica pronto, o RoqueOS abre ele no servidor, tira um print e mostra para a IA. Ela olha a imagem e diz o que viu: texto cortado, botão fora da área visível, contraste ruim, tela quebrada. O que ela achar aparece numa faixa em cima do app, com um botão Corrigir que manda o próprio diagnóstico dela de volta como pedido de mudança.

O print sai do servidor porque a prévia roda isolada, e uma página isolada não pode ser fotografada pelo navegador que a contém. A página fotografada fica selada: nenhuma requisição de rede sai dela.

Se não der para tirar o print, ou se a resposta vier ilegível, o app é entregue sem veredito. Um alarme falso faria você refazer algo que estava certo.

Anexar uma imagem ao pedido

Ao lado do botão de enviar existe um clipe. Um print do layout que você quer diz mais que um parágrafo descrevendo. A imagem é reduzida no seu navegador antes de sair, e vale para aquele pedido: depois que o app é gerado, ela sai da fila.

Precisa de servidor 1.9.0 ou mais novo e de um modelo que enxergue imagem.

Dizer como você quer que seja feito

Abaixo do campo de descrição existe Como devo construir. O que você escreve ali vale para todos os seus apps e não precisa ser repetido a cada pedido: "sempre em português, sem emoji, cores sóbrias, botões grandes". Fica salvo na sua conta.

As regras técnicas (arquivo único, sem rede, sem acesso aos seus dados) continuam valendo acima disso: elas são o que mantém o app isolado.

No computador e no celular

A tela se organiza sozinha pelo tamanho que ela tem:

• Computador: o app que está sendo feito ocupa a tela, e ao lado fica um painel fixo com o campo de descrição, o botão de criar, Publicar e a lista de Meus apps. Nada abre por cima do app, e Ctrl+Enter envia.
• Celular: o app ocupa a tela inteira e a barra de baixo abre o campo de descrição num painel deslizante. O teclado do RoqueOS ocupa a largura da tela e empurra o painel para cima, como um teclado nativo (segure uma letra para os acentos, e há copiar e colar). Só um painel por vez: abrir Meus apps fecha o campo de descrição.

---

Para que serve

A ferramentinha que só você precisa e que não existe pronta: um contador, um sorteador, uma calculadora de um cálculo específico do seu trabalho, um cronômetro de treino, uma tabela que some quando você fecha.

Para app que precisa guardar dados de verdade (que sobrevivem ao fechar), com banco e backend, use o modo App completo abaixo. Para escrever código à mão, o Roque Code ou o VS Code integrado.

---

App completo: backend, banco e site rodando no seu servidor

No topo do painel existe um seletor com dois modos:

• Página: tudo que está acima. Um arquivo HTML isolado, sem rede, sem dados que sobrevivem.
• App completo: um app de verdade, com backend (Node + Express), banco de dados (Postgres) e site (nginx), que é publicado no seu RoqueOS Server e fica no ar, com dados que sobrevivem porque moram num banco, não na aba.

É a diferença entre uma ferramentinha e um produto. Um quadro de tarefas da equipe cujos cartões continuam lá amanhã, um placar que todo mundo vê, um cadastro que não some quando você fecha o navegador.

Continuar evoluindo o app depois que ele está no ar

Criar o app é o começo, não o fim. Com um App completo aberto (recém-criado, ou reaberto por Abrir projeto em Meus apps), o campo de descrição vira "O que mudar no app?" e o botão vira Aplicar mudança. Você pede em português: "adiciona um filtro por categoria", "o botão salvar está errado, corrige", "mostra o total no rodapé".

O que acontece:

1. A IA recebe o código que já existe (não só a sua frase) e devolve apenas os arquivos que mudaram.
2. Esses arquivos vão para os contêineres que já estão rodando: o endereço continua o mesmo, a stack continua a mesma e os dados continuam lá.
3. O app é testado logo depois, e se algo quebrou, o mesmo laço de reparo tenta consertar.

Três garantias que importam:

• O banco só cresce. Uma mudança pode criar tabela, coluna ou índice, e nunca apagar nem renomear o que já existe, porque ali tem dado seu. O esquema é reaplicado a cada subida do app, então uma tabela pedida depois do primeiro dia realmente passa a existir.
• Se a IA não mudar nada, o app diz isso em vez de anunciar sucesso e deixar você procurando a diferença. E diz por quê: a IA devolveu tudo igual ao que já estava, ela não mexeu em arquivo nenhum, ou nós recusamos uma mudança que apagaria seus dados.
• A mudança também roda no servidor (a partir da versão 1.21.0 dele). Como acontece com a criação, você pode fechar a janela no meio: o trabalho continua lá, e o app não fica com metade dos arquivos trocados por causa de uma aba fechada. Num servidor mais antigo, a mudança segue acontecendo no navegador, e a única diferença que você vê é essa.

Para começar um app diferente, use Novo app: enquanto um app está carregado, o que você escreve muda esse app, nunca cria outro por engano.

O nome do app (e o endereço que ele vira)

Em App completo, acima da descrição existe o campo Nome do app. Ele não é enfeite: o nome vira o endereço público (/x/nome-do-app), os nomes dos contêineres e o rótulo no Launchpad.

• Enquanto você descreve, o campo já mostra um nome curto sugerido a partir do seu pedido. "um catalogo de livros com titulo, autor e preco" vira Catalogo de Livros, não a frase inteira.
• Deixar em branco é uma resposta válida: o nome sugerido é o que será usado.
• O limite é de 40 caracteres, com contador ao lado, e o endereço aparece embaixo (Endereço: /x/catalogo-de-livros) antes de você criar qualquer coisa.
• Um nome que não vira endereço (só emoji, só pontuação) é recusado antes do build, com um nome utilizável no lugar. Se o endereço já estiver ocupado por outro app seu, o novo recebe um número (minha-loja-2) em vez de ficar sem endereço.

Em Página o campo não aparece: uma página não ganha endereço próprio nem contêiner, e o nome dela é pedido na hora de publicar.

Otimizar a ideia antes de gerar

Uma frase esconde o que importa: quais dados o app guarda, quais telas ele tem. O botão Otimizar (ao lado de Criar e publicar) manda a sua descrição pra um modelo rápido montar um resumo estruturado, o que o app faz, as entidades e campos do banco, as telas, e até 3 perguntas puláveis, e mostra isso num painel que você edita. Confirma e o app é gerado a partir desse resumo mais rico (em vez de adivinhar de uma frase); ou gere direto com o seu texto, como antes.

O otimizador nunca trava a geração: se o modelo demora ou não entende, ele sai do caminho e você gera com o seu texto. Uma pergunta que você pulou não vira ruído no pedido.

Dar um arquivo como contexto

Ao lado dos botões, um anexar arquivo aceita uma planilha (CSV/Excel) ou um documento (PDF, Word, Markdown, texto):

• Planilha (CSV/Excel): vira uma tabela de verdade. O tipo de cada coluna é inferido pelos valores (uma coluna de números inteiros vira integer, de datas vira date, misturada vira text), e as linhas são semeadas no banco. O app já nasce com os seus dados dentro, e a IA é avisada de que a tabela existe, então ela constrói em cima dela em vez de inventar um modelo.
• Documento (PDF, Word, MD, texto): vira contexto de leitura. O texto é extraído no seu navegador e entra no pedido (com teto), então um briefing longo molda o app sem você redigitar.

Um chip mostra o que está anexado (tabela + número de linhas, ou caracteres de contexto) e deixa você remover. O Excel é lido sem uma dependência pesada; um .xlsx complexo que não abrir pode ser exportado como CSV.

Como funciona (e por que é confiável)

A IA não desenha a infraestrutura. É aí que todo gerador de app quebra: ele inventa um docker-compose, um proxy, um banco, e o resultado "funciona na prévia e morre em produção". Aqui a IA escreve os arquivos do app dentro de um projeto de verdade, com pastas: o backend em camadas (src/routes/, uma rota por recurso, cada uma virando /api/<nome>, mais src/controllers/, src/services/, src/repositories/ e src/validators/, com SQL só no repositório), o schema do banco em db/init.sql, e um frontend estruturado com HTML, CSS e JS em suas próprias pastas. A cola que transforma um monte de arquivos num servidor que roda (um server.js que monta sozinho cada arquivo de rota, o acesso ao banco, o compose com os três containers, o proxy do nginx pro backend, os healthchecks, os limites de recurso, os nomes de volume) é gerada por nós, igual toda vez, e a IA nunca consegue sobrescrever. Isso é o que faz o app subir de forma confiável, e ao mesmo tempo entrega um projeto profissional que você lê, guarda e evolui, não um arquivo gigante.

O fluxo, quando você aperta Criar e publicar:

1. A IA escreve os arquivos do projeto (as rotas, os serviços, os repositórios, o schema e o frontend).
2. O RoqueOS monta o projeto (juntando a cola fixa) e manda pro seu servidor.
3. O servidor descompacta os arquivos em volumes nomeados por projeto e sobe a stack a partir de imagens base (node:20-alpine, postgres:16-alpine, nginx:alpine), sem build.
4. O RoqueOS resolve um endereço navegável pro app (ver "O endereço", abaixo).

Você acompanha as cinco etapas (escrevendo, montando, subindo, iniciando, publicando o endereço) como uma sequência, não um spinner que não diz nada.

Pode fechar a janela, o app continua sendo criado

Criar um app completo leva minutos: a IA escreve os arquivos, o servidor monta o projeto e sobe quatro contêineres. Você não precisa ficar olhando.

Assim que o build começa, ele deixa de pertencer à janela do Criar App e passa a ser uma tarefa do sistema: aparece uma pílula flutuante com o progresso, do mesmo tipo que um upload longo. Feche a janela, vá usar outro app, o build continua. Clicando na pílula você vê em que passo ele está.

Quando termina, o RoqueOS avisa por dois caminhos:

• uma notificação dentro do sistema, que fica guardada na central, então mesmo que você só volte depois ela está lá;
• uma notificação do seu sistema operacional, se você tiver dado permissão ao navegador. Essa é a que aparece com a aba do RoqueOS em segundo plano, que é o caso de "saí para fazer outra coisa".

O aviso vem também quando dá errado. Um build que morreu em silêncio é pior que um que avisa, porque você fica esperando.

Duas coisas que valem saber:

• Enquanto um app está sendo criado, não dá para começar outro. Reabrir a janela no meio do build mostra a tarefa em andamento, não um formulário vazio. Isso evita subir duas implantações da mesma coisa sem querer.
• Quem faz o trabalho é o servidor, não o seu navegador. Feche a aba, desligue o computador, saia do escritório: o build segue. Ao voltar — no mesmo aparelho ou em outro — abrir o Criar App te devolve o build acontecendo, com o nome do app e o passo em que ele está, em vez de uma tela em branco.

Parar um build

Enquanto um app está sendo criado aparece um botão Parar. Ele só existe quando parar de fato funciona: em servidores mais antigos, que ainda constroem dentro do navegador, não há o que interromper, e um botão que não age seria pior que a ausência dele.

Parar de verdade para. Além de encerrar o trabalho, ele corta a conversa com a IA no meio — sem isso você desistiria e o modelo continuaria escrevendo (e cobrando) uma resposta que ninguém veria.

O que acontece com o que já subiu depende de onde você parou:

• No começo (a IA ainda escrevendo, o projeto ainda sendo montado): nada foi criado, e nada fica para trás.
• Depois que os contêineres subiram: eles existem, então o app é registrado assim mesmo, como um app incompleto. Ele aparece em "Meus apps" para você abrir, olhar e apagar. É de propósito: um app que você vê e apaga é melhor que quatro contêineres rodando que ninguém sabe que existem.

Baixar o app e levar para onde você quiser

O app é seu, e não fica preso ao RoqueOS. No app pronto — e também quando o build não termina — existe Baixar o código: sai um .zip que não é um monte de arquivos soltos, é um repositório pronto.

Dentro dele:

• o código do app, do jeito que está rodando;
• um docker-compose.yml portátil, que sobe em qualquer máquina com docker compose up (sem os nomes de volume e as portas internas do seu servidor);
• um README.md gerado, com as rotas que o app expõe, as tabelas que ele tem, como rodar e como mandar para o GitHub;
• um .env.example e um .gitignore.

A senha do seu banco nunca entra no zip. O compose lê a senha do ambiente (POSTGRES_PASSWORD), e o .env fica de fora pelo .gitignore — porque a primeira coisa que um repositório publicado faria seria expor essa senha para o mundo.

Descompactou, é git init, git remote add, git push, e o app está no seu GitHub. Rodar em outro lugar é docker compose up.

Vale o mesmo para um build que quebrou: você descreveu o app, a IA escreveu o código, e o que falhou foi a subida. Devolver isso de mãos vazias seria jogar fora o seu trabalho.

Quando dá errado, a tela diz o quê

Um build que falha não some em silêncio nem mostra erro técnico: ele vira um painel com a causa em português, e o botão de baixar o código ao lado quando ainda há o que baixar.

O que apareceu	O que aconteceu, e o que fazer
Nenhum agente utilizável	Este servidor não tem um agente de IA configurado. Crie um no Estúdio de IA e escolha-o no Criar App
Não deu para perguntar ao servidor	O servidor não respondeu a lista de agentes. Costuma ser conexão — tente de novo
O provedor de IA recusou	Chave inválida, sem crédito ou modelo indisponível. Confira a chave do agente no Estúdio de IA
A IA não devolveu nada	O modelo respondeu vazio. Tentar de novo costuma resolver; um modelo maior resolve mais
Veio texto, mas não um app	O modelo escreveu uma explicação em vez do projeto. Reformule o pedido, ou use um modelo mais forte
O código não seguia as regras	O que veio quebrava a fiação entre site, API e banco, e não deu para consertar sozinho. Tente de novo, de preferência com outro modelo
Recusei mexer no banco	O pedido apagaria dados existentes (DROP, TRUNCATE). O resto foi aplicado; o banco ficou intacto de propósito
Docker fora	O Docker do servidor não está respondendo. É no servidor, não no seu pedido
Já existe um app com esse nome	O nome vira o endereço, então ele é único. Escolha outro
Não consegui criar o app	A stack não subiu. Veja o app Containers para o motivo
Subiu, mas o endereço não apareceu	O app está de pé e ainda sem endereço público. Ele fica registrado; dá para abrir pelo Containers
Está no ar sem endereço navegável	Mesma coisa: existe, funciona, falta a rota. O app não é perdido
Subiu e não responde	Os contêineres estão de pé mas o app não responde, e o reparo automático não resolveu. O código continua baixável
Você mandou parar	Foi você. Se já havia contêineres, o app incompleto está em "Meus apps"
O servidor reiniciou no meio	O servidor caiu ou foi atualizado durante o build. Dá para tentar de novo

Quando o app fica pronto, a prévia ao vivo ocupa a tela e o endereço fica na barra de cima dela. A barra verde separada aparece no modo Página, onde não existe prévia embutida.

Se o servidor demorar demais pra publicar a porta, o app ainda é registrado, sem endereço: ele aparece em "Meus apps" como um app não publicado, pra você abrir o painel de containers, ver o que houve e apagá-lo se quiser. Antes, uma parada nesse ponto deixava containers rodando sem nada apontando pra eles.

Onde ele vive e como gerenciar

O app é uma stack real no seu gestor de containers. Ele aparece no app Containers com logs, reiniciar, editar e re-publicar, como qualquer outro container. Se você deletar a stack lá, o app sai do ar.

Cada app ganha volumes próprios (nomeados pelo projeto), então dois apps no mesmo servidor nunca compartilham banco. O Postgres não tem porta pública: só o backend o alcança, pela rede interna da stack. O site é a única coisa que o mundo de fora vê.

Ver e editar o código

Um app que ficou no ar não é uma caixa-preta. No estado publicado aparece Ver código, que abre um editor embutido com a árvore de arquivos de verdade do projeto (o backend com as cinco camadas, o schema em db/init.sql, o frontend estruturado) e um editor de código para cada arquivo.

Duas formas de mudar:

• Na mão: escolha um arquivo na árvore e edite direto.
• Com a IA (por arquivo): o botão Editar com IA manda só o arquivo aberto pra IA, com o pedido de mudança, e ela devolve só aquele arquivo reescrito. Não regenera o projeto inteiro: uma mudança pontual continua pontual (o "Lock/Target" dos editores de IA do mercado).

Aplicar e republicar leva as suas edições pro app que já está rodando, no lugar. Em um servidor com o endpoint de atualização, a troca é incremental (só os volumes de código são reescritos e o app reinicia); em qualquer servidor, o dado do app sobrevive, porque o volume do Postgres nunca é tocado. Editar o código nunca apaga as suas linhas do banco.

O editor só carrega quando você o abre, então ele não pesa no app no dia a dia.

Ver o diagrama do app

No app publicado, o botão Diagrama abre duas visões do que foi construído:

• Banco (ER): um card por tabela, com suas colunas (tipo, chave primária, chave estrangeira) e uma linha por relação, marcada com a coluna que a liga e a cardinalidade (categoria_id · N:1). A relação aparece mesmo quando o schema não declarou a chave estrangeira: uma coluna categoria_id ao lado de uma tabela categorias é desenhada como relação tracejada, porque é uma leitura nossa, não algo que o código afirma.
• Arquitetura: o caminho inteiro do sistema, você → o site (nginx) → a camada de integração (o proxy /api, o pulo que faz o site e a API serem um app só) → o backend → cada rota /api/<recurso>, com os métodos que ela responde (GET, POST…) → o Postgres (com quantas tabelas tem) → cada tabela (com quantas colunas tem). Uma linha tracejada liga a rota às tabelas que o SQL dela realmente usa.

Os dois são desenhados a partir do próprio db/init.sql e dos arquivos de rota do app, então é um mapa deste app, não um desenho genérico. O diagrama redesenha quando você muda o schema no editor de código embutido: o banco é a fonte da verdade.

É um canvas de verdade, o mesmo motor do construtor de Fluxos: dá pra arrastar a tela, dar zoom e mover um card. E o diagrama nunca encolhe além do ponto em que os rótulos param de ser legíveis.

Checkpoints: um retrato dos dados, com volta

Editar um app que já está no ar com a IA pede uma rede de segurança. O botão Checkpoints dá isso: Criar checkpoint agora tira um retrato dos dados do app (o banco Postgres). Cada checkpoint fica listado com a data, e Restaurar volta os dados pra aquele ponto, com confirmação (ele substitui os dados atuais e reinicia o app). É a lição do episódio do Replit: você sempre pode voltar, e uma restauração nunca acontece sem você mandar.

Cada checkpoint também pode ser excluído, e isso também pede confirmação: o retrato é apagado do servidor e não volta, e se for o único você fica sem ponto de retorno. As duas ações usam o botão vermelho, porque as duas são destrutivas: restaurar troca os dados de produção do app.

Por baixo, o checkpoint usa a mesma capacidade de backup de container que o app Containers já expõe, então é um backup de verdade do volume do banco, não uma cópia frágil.

O banco nunca encolhe sozinho

Quando você pede uma mudança, o app já tem dados reais. Por isso o schema só pode crescer: criar tabela, acrescentar coluna, criar índice. Se a IA responder com um DROP, um TRUNCATE ou um rename de tabela ou coluna, o RoqueOS recusa aquele arquivo e mantém o schema que está valendo, avisando na tela. O resto da mudança que for seguro continua sendo aplicado.

Isso importa mais do que parece: o schema é reaplicado a cada vez que o app sobe, então um DROP aceito não apagaria os seus dados uma vez, apagaria de novo em todo restart.

Abrir o banco do app

Ao lado de Checkpoints existe o botão Dados, que abre um console do banco do app dentro do RoqueOS: as tabelas, as linhas e uma janela de consulta. Ele é alcançado só pelo proxy autenticado do seu servidor (nunca por um endereço público), então o Postgres continua sem porta aberta pro mundo.

Segurança (o desenho, não a confiança)

• O app gerado nunca monta o socket do Docker, roda com limites de memória, CPU e processos, e o banco fica fora de qualquer porta pública.
• O enquadramento é self-hosted: o app roda no seu servidor, com a sua confiança, do mesmo jeito que os 200+ apps do catálogo. Não é uma hospedagem multi-inquilino nossa. Rodar apps de terceiros por nós exigiria isolamento por microVM e é uma fase futura, não esta.

O endereço

Quando você aperta Criar e publicar, o app ganha um endereço navegável de verdade, não uma porta que não abre.

São três caminhos, tentados nesta ordem, e o RoqueOS só mostra um endereço que de fato abre:

1. Servidor com um domínio no Cloudflare: cada app recebe o seu próprio subdomínio (meu-app.seu-dominio), criado pelo mesmo gestor de túneis que o gerenciador de containers usa. Não é um caminho à parte: o site do app é um container gerenciado, então a rota aparece no painel de acesso do container, dá para editar e remover ali, e um novo deploy do mesmo app mantém o mesmo endereço.
2. Rota por caminho no próprio servidor (/x/<nome-do-app>/): funciona em qualquer servidor alcançável, sem DNS e sem porta. É o caminho que atende a maioria dos casos, inclusive servidor atrás de túnel sem zona de DNS. O nome que você escolheu vira esse endereço, e é por isso que ele tem limite de 40 caracteres e é validado antes do build. Se o endereço já estiver ocupado, o RoqueOS numera (meu-app-2) em vez de falhar.
3. host:porta, e só quando o servidor é da sua rede local.

Se nenhum dos três der um endereço navegável, o RoqueOS diz que o app está sem endereço público em vez de mostrar um link que não abre.

Assim o endereço que a barra verde mostra é o mesmo que qualquer pessoa abre no navegador, com backend e banco rodando por trás dele.

Requisitos

• Modo Servidor com Docker ativo (mesma base que o gestor de containers usa).
• Um agente de IA configurado escreve os arquivos do projeto a partir da sua descrição. Sem um modelo capaz, o RoqueOS ainda publica um app inicial funcional (um projeto multi-arquivo com backend e banco de verdade), pra você partir dele e configurar a IA depois.

---

Publicar para fora do RoqueOS

Um app publicado vive no seu Launchpad. Deixá-lo acessível pela internet, com um endereço que qualquer pessoa abre, é outra coisa, e por enquanto está desligado.

O caminho está construído e reusa o que o servidor já tem para sites: os mesmos modos de acesso (aberto, senha, só contatos), o mesmo cookie assinado e o mesmo portão que decide quem recebe os bytes. Inventar um segundo caminho público seria acabar com dois modelos de segurança e só um deles auditado.

Como ligar

É uma chave do servidor, não do app, porque quem decide é quem opera o servidor:

# no update do seu servidor
curl -fsSL https://roqueos.com.br/install.sh | bash -s -- --update
# com a variável de ambiente ligada
ENABLE_APP_MAKER_PUBLIC=true

Com ela ligada, aparece um botão Publicar na internet dentro do diálogo de publicar. Sem ela, o botão não existe: uma ação que não funciona é pior que uma ação ausente.

O app vai para uma pasta sua em Apps publicados, e o endereço é servido pelo mesmo módulo de sites, com o modo de acesso que você escolher.

Quando ligado, o documento que vai para a internet não é o mesmo que roda dentro do RoqueOS: ele leva título, descrição e as etiquetas de cartão (Open Graph), porque lá fora o documento é o que o buscador indexa e o que o WhatsApp transforma em prévia. App sem ícone não ganha etiqueta de imagem: uma etiqueta apontando para o nada vira cartão quebrado, que é pior que um cartão simples.

Por que não existe uma loja de apps

Foi analisado e a resposta foi não, por enquanto. Plataformas muito maiores que a nossa não conseguem encher uma loja desse tipo: o Puter tem dezenas de apps de terceiros, o Nextcloud levou cerca de dez anos para centenas, e no Home Assistant os milhares de add-ons vêm de uma fração mínima dos usuários.

Existe também um motivo jurídico: desde a decisão do tribunal europeu no caso Russmedia (dezembro de 2025), quem opera um marketplace é controlador dos dados pessoais que os apps de terceiros processam, e não pode se defender dizendo que só hospeda.

O caminho que faz sentido é o oposto: primeiro compartilhar um app com uma pessoa, que é a Fase 3, e deixar a demanda provar que existe antes de construir a vitrine.

---

Veja também

• Estúdio de IA, onde vivem os agentes que escrevem os apps
• Agentes, instruções, conhecimento e ferramentas de cada agente
• Roque Code, quando o app precisa ser de verdade