O que o VULK constrói por trás de uma app full-stack: base de dados, início de sessão e API, verificados em produção

Verificado a 10 de outubro de 2026, contra o código que o VULK corre hoje e contra endpoints em produção.

Quando pedes ao VULK uma app que tem de guardar dados, como uma loja, uma ferramenta de marcações ou um CRM, ele não fica pelos ecrãs. Constrói três coisas por trás deles: uma base de dados só do projeto, um sistema de início de sessão para as pessoas que vão usar a app e uma API REST com que os ecrãs comunicam. As três correm no backend gerido do VULK em api-backend.vulk.dev, e não tens de configurar um servidor, uma base de dados nem um fornecedor de autenticação.

Este artigo mostra cada parte tal como funciona de facto. Todos os números abaixo vêm de um de três sítios: o código que gera e serve estas apps (lido a 10 de outubro de 2026), o endpoint público de estado do backend e pedidos reais a uma loja que está pública na montra do VULK. Nada aqui é um benchmark que tenhamos corrido no produto de outra empresa.

O frontend que o VULK escreve

Uma app web sai como um projeto React construído com Vite. As versões estão fixadas no gerador em vez de ficarem a flutuar, por isso o projeto que pré-visualizas é o projeto que exportas:

Quando uma app precisa de dados, o VULK acrescenta ao projeto um ficheiro de cliente tipado. Os ecrãs nunca constroem URLs nem tokens à mão: chamam esse cliente, e o cliente chama o backend.

Uma base de dados por projeto

O backend dá a cada projeto a sua própria base de dados PostgreSQL, identificada por um id curto: proj_ seguido dos primeiros oito caracteres hexadecimais da conversa que construiu a app. O id mantém-se em todas as edições, por isso a tua app conserva os dados quando pedes uma alteração.

O backend publica um endpoint de estado que qualquer pessoa pode ler. A 10 de outubro de 2026, às 22:34 UTC, respondeu:

{
  "status": "ok",
  "service": "vulk-api-engine",
  "database": "connected",
  "projects": 1440
}

São 1440 bases de dados de projeto provisionadas no motor naquele momento.

Como é uma tabela gerada

O VULK decide as tabelas a partir do que a tua app precisa (produtos, encomendas, marcações) e acrescenta três colunas suas:

• id, uma chave primária de texto
• created_at, um timestamp preenchido pela base de dados
• user_id nas tabelas em que cada linha pertence a uma pessoa com sessão iniciada

Todas as outras colunas têm um de cinco tipos: texto, número, inteiro, booleano ou data e hora. Os nomes de tabelas e colunas usam letras minúsculas, algarismos e underscores, começam por uma letra e têm no máximo 48 caracteres. A API responde em camelCase, por isso created_at chega aos teus ecrãs como createdAt.

As alterações ao schema só acrescentam. Quando uma edição precisa de uma tabela ou coluna nova, o backend acrescenta-a. Apagar uma coluna ou mudar o seu tipo nunca é feito automaticamente, porque é essa a alteração que apaga dados.

A API REST, rota a rota

Cada tabela recebe o mesmo conjunto de rotas sob o endereço do projeto:

As listas chegam num único envelope, { data, meta: { total, page, perPage, totalPages } }. O cliente gerado lê 100 linhas por página e para nas 1000, e envia as inserções em massa em blocos de 1000. Cada projeto aceita 100 pedidos por minuto de cada endereço de cliente, e o backend indica-o em todas as respostas com o cabeçalho X-RateLimit-Limit: 100.

Quem pode ler e escrever o quê

Esta é a parte que os backends gerados mais vezes fazem mal, por isso vale a pena ser exato. Uma tabela sem política de acesso declarada está fechada. Primeiro, o VULK dá à app inteira uma de quatro formas:

• Contas privadas: cada pessoa inicia sessão e só vê as suas próprias linhas.
• Contas de equipa: uma equipa trabalha sobre as mesmas linhas, e as pessoas entram por convite.
• Pública: sem contas nenhumas.
• Painel do dono: visitantes, mais uma área que só o dono pode abrir.

Depois, configura cada tabela por si. Uma tabela pode ser lida publicamente, com a chave de API do projeto, por um utilizador com sessão iniciada ou só pelo dono, e as escritas têm as mesmas opções mais "qualquer pessoa", para coisas como um formulário de contacto. As escritas anónimas estão limitadas a 20 por minuto por endereço. Os campos são privados, a não ser que o plano da app diga o contrário.

Eis essa política numa app em produção. A LUMA é uma loja de moda da montra que corre neste backend em proj_266b7c3c. Enviámos estes pedidos sem iniciar sessão, a 10 de outubro de 2026:

O catálogo é público, porque uma loja tem de mostrar os produtos. As encomendas exigem um cliente com sessão iniciada. A tabela de contas nem sequer está exposta como tabela.

Início de sessão para as pessoas que usam a tua app

Cada app full-stack recebe as suas próprias contas de utilizador, separadas da tua conta VULK. O cliente gerado cobre o registo, o início de sessão, o "quem sou eu" e a reposição da palavra-passe. O backend tem também rotas para a renovação da sessão, o fim de sessão e a mudança de palavra-passe:

• As palavras-passe são guardadas com hash PBKDF2-SHA256, com 100 000 iterações e um salt aleatório de 16 bytes.
• A sessão vive no browser e é enviada como bearer token. Qualquer 401 apaga-a, por isso a app nunca guarda uma sessão que o servidor já rejeitou.
• A pessoa que é dona do projeto é o administrador; todas as que se registam são utilizadores normais.
• O registo pode ser aberto ou só por convite, com códigos que funcionam uma vez e expiram ao fim de sete dias.

No studio, o painel de cada projeto tem um separador Backend com uma visão geral, a base de dados, os utilizadores da app, a API e os respetivos segredos.

Chaves e segredos

Cada projeto recebe uma chave de API no formato vk_ seguido de 64 caracteres hexadecimais, guardada cifrada com AES-256-GCM. O bundle publicado não leva nenhuma chave: o endereço do backend é injetado na página quando ela carrega, e nada que permita a um visitante agir como o dono chega ao browser. Os segredos de que a tua app precisa, como o token de uma API de terceiros, são só de escrita. Podes definir ou substituir um, mas ninguém o consegue ler de volta, e cada um está limitado a 8 KB.

Publicar e levar o código contigo

Publicar é um clique. O VULK constrói a versão de produção dentro da mesma máquina isolada que correu a tua pré-visualização e depois serve-a em <name>.vulk.space por HTTPS. O nome que escolhes fica teu. Se despublicares, o site fica offline e o endereço é guardado para esse projeto. O endereço do backend fica ligado tanto à pré-visualização como ao build publicado, por isso a app publicada fala com a mesma base de dados que testaste.

O código também é teu. Todos os planos pagos podem descarregar o projeto inteiro em ZIP ou enviá-lo para um repositório GitHub novo, privado ou público. A exportação para o GitHub nunca faz force-push e aceita até 1000 ficheiros e 8 MB por push.