Nhost

Nhost é uma alternativa open-source ao Firebase com GraphQL.

O Nhost CLI é usado para configurar um ambiente de desenvolvimento local. Esse ambiente rastreia automaticamente migrações de banco de dados e metadados do Hasura.

É recomendado usar o Nhost CLI e a Integração com GitHub do Nhost para desenvolver localmente e implantar alterações em produção automaticamente com um fluxo de trabalho baseado em git (semelhante ao Netlify e Vercel).

Serviços

• Nhost Dashboard
• Postgres Database
• GraphQL Engine
• Auth
• Storage
• Nhost Serverless Functions
• Minio S3
• Mailhog

Instalação

Homebrew

brew install nhost/tap/nhost

Nix

Se você tiver flakes habilitados:

nix profile install github:nhost/nhost#cli

Ou execute diretamente sem instalar:

nix run github:nhost/nhost#cli

npm / pnpm / Yarn / Bun

Instale o CLI em um projeto para fixar a versão para toda a equipe:

npm install -D @nhost/cli
pnpm add -D @nhost/cli
yarn add -D @nhost/cli
bun add -d @nhost/cli

Ou execute sem instalar:

npx @nhost/cli@latest --version
pnpm dlx @nhost/cli@latest --version
yarn dlx @nhost/cli@latest --version
bunx @nhost/cli@latest --version

Instalação rápida (Linux / macOS)

curl -sSL https://raw.githubusercontent.com/nhost/nhost/main/cli/get.sh | bash

Ou especifique uma versão:

curl -sSL https://raw.githubusercontent.com/nhost/nhost/main/cli/get.sh | bash -s 1.38.0

Começando

As etapas abaixo são uma referência rápida. Para um passo a passo guiado, consulte o Início rápido do CLI.

Autenticar

Necessário apenas para obter a configuração de um projeto existente no Nhost Cloud ou para implantar — pule esta etapa para trabalho puramente local.

nhost login

Inicializar um projeto

Cria a estrutura de um diretório nhost/ (configuração de backend, versionada no Git) e um diretório functions/.

nhost init

Ou comece a partir de um projeto existente no Nhost Cloud:

nhost init --remote

Iniciar o ambiente de desenvolvimento

Inicia toda a stack (Postgres, GraphQL, Auth, Storage, Functions) com Docker e exibe as URLs locais dos serviços.

nhost up

O dashboard local roda em https://local.dashboard.local.nhost.run. Pare a stack com nhost down e acompanhe os logs com nhost logs.

Servidor MCP

O Nhost CLI acompanha um servidor MCP que permite interagir com seus projetos Nhost por meio de assistentes de IA usando o Model Context Protocol. Ele fornece acesso seguro e controlado aos seus dados GraphQL, configuração do projeto e documentação — com permissões granulares que permitem especificar exatamente quais consultas e mutações um LLM pode executar. Para desenvolvimento, ele otimiza seu fluxo de trabalho ao permitir gerenciamento de esquema assistido por IA, alterações de metadados e migrações, além de fornecer acesso direto ao seu esquema GraphQL para construção inteligente de consultas.

Você pode ler mais sobre o servidor MCP na documentação do Servidor MCP.

Documentação

• Início rápido do CLI
• Nhost CLI
• Referência
• Servidor MCP

Compilar a partir do código-fonte

Certifique-se de ter o Go 1.18 ou posterior instalado.

O código-fonte inclui um certificado autoassinado para fins de teste. Workers do Nhost com acesso configurado à AWS podem usar o script cert.sh para gerar um certificado real da Let's Encrypt.

go build -o /usr/local/bin/nhost

Isso compilará o binário disponível como o comando nhost no terminal.

Regenerar certificados TLS locais

O script de certificado agora exige um alvo Kubernetes explícito. Esta é uma mudança intencional e incompatível para operadores que anteriormente o executavam sem argumentos. A partir da raiz do repositório, entre no shell de desenvolvimento do CLI e execute:

nix develop .#cli
cd cli && ./cert.sh <namespace> <deployment>

O runtime precisa do Certbot e do plugin Route53, kubectl, jq e dig; shellcheck está incluído para linting dos scripts, mas não é uma dependência de runtime. Ferramentas equivalentes do host podem ser usadas no lugar do shell Nix. O operador precisa de credenciais AWS válidas para o certificado Route53 e um contexto Kubernetes ativo com acesso ao Deployment get, patch e ao status/observação de rollout. O script nunca seleciona nem altera um contexto kubectl.

O hook de autenticação de curinga corrige as variáveis ACME_CHALLENGE_* de ambiente existentes no Deployment. Cada uma das nove variáveis suportadas deve ocorrer exatamente uma vez como um value direto e não vazio em um contêiner; variáveis duplicadas, valueFrom ou um layout de Deployment alterado falham de forma segura. A publicação rápida de desafios pode causar oscilação intermediária de rollout. Apenas o hook invocado por último aguarda a geração final e a prontidão do DNS. Os valores de desafio são intencionalmente retidos. Se o Certbot reutilizar todas as autorizações em cache, ele não invoca nenhum hook e a publicação é um no-op válido; se apenas algumas estiverem em cache, o hook final também valida cada valor retido.

O tempo limite de rollout, o tempo limite global de DNS e o intervalo de polling de DNS têm como padrão 300, 300 e 2 segundos. Substitua-os com ACME_ROLLOUT_TIMEOUT_SECONDS, ACME_DNS_TIMEOUT_SECONDS e ACME_DNS_POLL_INTERVAL_SECONDS. O pior caso é, portanto, aproximadamente dez minutos após os patches rápidos. O DNS usa o resolvedor do sistema por padrão. Defina ACME_DNS_SERVER para um hostname ou resolvedor IPv4 na porta padrão 53; um resolvedor autoritativo ou público adequado é preferido quando o cache negativo recursivo atrasa um novo registro TXT.

Não execute solicitações de certificado concorrentes contra o mesmo Deployment: seu ambiente pode armazenar apenas um valor para cada serviço. Uma alteração de UID ou geração no momento do rollout também aborta a execução. Os valores de validação são dados DNS públicos e kubectl set env expõe necessariamente o valor atual na lista de argumentos desse processo; o hook suprime a saída de comandos que contém valores e não cria arquivos de estado de token, então os operadores ainda devem restringir a inspeção local de processos e o rastreamento de comandos.

O certificado Route53, os destinos de cópia do certificado e a limpeza final permanecem inalterados. Execute o comando a partir de cli/ para que seus caminhos de saída relativos existentes continuem resolvendo.

Dependências

• Docker
• Docker Compose
• curl
• Git

Plataformas suportadas

• macOS
• Linux
• Windows WSL2