Nhost

Nhost es una alternativa de código abierto a Firebase con GraphQL.

La CLI de Nhost se utiliza para configurar un entorno de desarrollo local. Este entorno rastreará automáticamente las migraciones de la base de datos y los metadatos de Hasura.

Se recomienda usar la CLI de Nhost y la Integración de Nhost con GitHub para desarrollar localmente y desplegar cambios automáticamente a producción con un flujo de trabajo basado en Git (similar a Netlify y Vercel).

Servicios

• Panel de Nhost
• Base de datos Postgres
• Motor GraphQL
• Autenticación
• Almacenamiento
• Funciones serverless de Nhost
• Minio S3
• Mailhog

Instalación

Homebrew

brew install nhost/tap/nhost

Nix

Si tienes flakes habilitados:

nix profile install github:nhost/nhost#cli

O ejecútalo directamente sin instalarlo:

nix run github:nhost/nhost#cli

npm / pnpm / Yarn / Bun

Instala la CLI en un proyecto para fijar la versión para todo el equipo:

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

O ejecútala sin instalarla:

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

Instalación rápida (Linux / macOS)

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

O especifica una versión:

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

Primeros pasos

Los pasos siguientes son una referencia rápida. Para una guía detallada, consulta el Inicio rápido de la CLI.

Autenticación

Solo es necesaria para extraer la configuración de un proyecto existente en Nhost Cloud o para desplegar; omítela si trabajas únicamente en local.

nhost login

Inicializar un proyecto

Crea la estructura de un directorio nhost/ (configuración del backend, versionada en Git) y un directorio functions/.

nhost init

O comienza desde un proyecto existente en Nhost Cloud:

nhost init --remote

Iniciar el entorno de desarrollo

Levanta toda la pila (Postgres, GraphQL, Auth, Storage, Functions) con Docker y muestra las URL de los servicios locales.

nhost up

El panel local se ejecuta en https://local.dashboard.local.nhost.run. Detén la pila con nhost down y sigue los registros con nhost logs.

Servidor MCP

La CLI de Nhost incluye un servidor MCP que te permite interactuar con tus proyectos de Nhost a través de asistentes de IA mediante el Model Context Protocol. Proporciona acceso seguro y controlado a tus datos de GraphQL, la configuración del proyecto y la documentación, con permisos granulares que te permiten especificar exactamente qué consultas y mutaciones puede ejecutar un LLM. Para el desarrollo, agiliza tu flujo de trabajo al permitir la gestión de esquemas, cambios de metadatos y migraciones asistidos por IA, además de brindar acceso directo a tu esquema GraphQL para la construcción inteligente de consultas.

Puedes leer más sobre el servidor MCP en la documentación del servidor MCP.

Documentación

• Inicio rápido de la CLI
• CLI de Nhost
• Referencia
• Servidor MCP

Compilar desde el código fuente

Asegúrate de tener Go 1.18 o una versión posterior instalado.

El código fuente incluye un certificado autofirmado para fines de prueba. Los workers de Nhost con acceso configurado a AWS pueden usar el script cert.sh para generar un certificado real de Let's Encrypt.

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

Esto compilará el binario disponible como el comando nhost en la terminal.

Regenerar certificados TLS locales

El script de certificados ahora requiere un destino explícito de Kubernetes. Este es un cambio disruptivo deliberado para los operadores que anteriormente lo ejecutaban sin argumentos. Desde la raíz del repositorio, entra al shell de desarrollo de la CLI y ejecuta:

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

El entorno de ejecución necesita Certbot y su plugin de Route53, kubectl, jq y dig; shellcheck se incluye para el linting de los scripts, pero no es una dependencia de ejecución. Se pueden usar herramientas equivalentes del host en lugar del shell de Nix. El operador necesita credenciales de AWS funcionales para el certificado de Route53 y un contexto de Kubernetes activo con acceso al Deployment get, patch y al estado/observación del rollout. El script nunca selecciona ni cambia un contexto de kubectl.

El hook de autenticación de comodín parchea las variables de entorno ACME_CHALLENGE_* existentes en el Deployment. Cada una de las nueve variables admitidas debe aparecer exactamente una vez como un value directo y no vacío en un contenedor; las variables duplicadas, valueFrom o un diseño de Deployment modificado fallan de forma segura. La publicación rápida de desafíos puede causar fluctuaciones intermedias en el rollout. Solo el hook invocado al final espera la generación final y la disponibilidad de DNS. Los valores de desafío se conservan intencionalmente. Si Certbot reutiliza todas las autorizaciones en caché, no invoca ningún hook y la publicación es un no-op válido; si solo algunas están en caché, el hook final también valida cada valor retenido.

El tiempo de espera del rollout, el tiempo de espera global de DNS y el intervalo de sondeo de DNS tienen como valores predeterminados 300, 300 y 2 segundos. Anúlalos con ACME_ROLLOUT_TIMEOUT_SECONDS, ACME_DNS_TIMEOUT_SECONDS y ACME_DNS_POLL_INTERVAL_SECONDS. El peor caso es, por lo tanto, aproximadamente diez minutos después de los parches rápidos. DNS usa el resolutor del sistema de forma predeterminada. Establece ACME_DNS_SERVER a un nombre de host o resolutor IPv4 en el puerto estándar 53; se prefiere un resolutor autoritativo o público adecuado cuando el almacenamiento en caché negativo recursivo retrasa un nuevo registro TXT.

No ejecutes solicitudes de certificados concurrentes contra el mismo Deployment: su entorno solo puede almacenar un valor para cada servicio. Un cambio de UID o de generación durante el rollout también aborta la ejecución. Los valores de validación son datos DNS públicos y kubectl set env necesariamente expone el valor actual en la lista de argumentos de ese proceso; el hook suprime la salida de comandos que contiene valores y no crea archivos de estado de tokens, por lo que los operadores deben restringir la inspección local de procesos y el rastreo de comandos.

El certificado de Route53, los destinos de copia del certificado y la limpieza final permanecen sin cambios. Ejecuta el comando desde cli/ para que sus rutas de salida relativas existentes sigan resolviéndose.

Dependencias

• Docker
• Docker Compose
• curl
• Git

Plataformas compatibles

• macOS
• Linux
• Windows WSL2