Impreza Host

El conector oficial de Impreza Host para la gestión de servidores offshore

Documentación

impreza-mcp

Servidor de Model Context Protocol para Impreza Host. Permite que las herramientas de codificación con IA (Claude Code, Cursor, Codex CLI, Continue, Zed, ...) desplieguen aplicaciones creadas por clientes en VPS de Impreza administrados sin salir del chat.

Cuando le dices "despliega esto por mí" a Claude con este servidor MCP cargado, Claude llama a impreza_deploy_custom directamente: empaqueta tu proyecto, lo sube, lo compila y lo ejecuta en tu VPS de Impreza, y te devuelve la URL.

Vincula la CLI local

Genera un código de un solo uso en el área de cliente en Impreza API → Conectar un asistente de IA, eligiendo los permisos que necesite el asistente. Ejecuta npx -y impreza-mcp login --code <code-from-clientarea> en la máquina donde se ejecuta el servidor MCP local. Los códigos caducan después de 10 minutos y solo pueden usarse una vez.

La CLI intercambia el código en POST /v1/mcp/pair sin enviar ninguna credencial API existente. Guarda la clave, el secreto, los alcances y la caducidad devueltos en ~/.impreza/credentials.json; el código y el secreto nunca se imprimen. El directorio usa el modo 0700 y el archivo 0600 en POSIX. Windows usa una ACL protegida que otorga acceso solo a tu cuenta. El servidor lee este archivo automáticamente cuando ninguna variable de entorno de credenciales está configurada. Las variables IMPREZA_API_KEY y IMPREZA_API_SECRET explícitas tienen prioridad juntas; las credenciales de entorno parciales nunca usan una contraparte guardada.

Configura IMPREZA_BASE_URL antes de vincular para un endpoint de API diferente. Se requiere HTTPS; un endpoint onion v3 requiere IMPREZA_PROXY con un proxy SOCKS5 explícito y nunca recurre a una conexión directa. El endpoint y el proxy se guardan con la credencial. Una URL de API diferente rechaza la credencial guardada. La vinculación nunca sigue redirecciones ni reintenta un código automáticamente.

Un archivo de credenciales existente nunca se sobrescribe. Revoca una clave vinculada anterior en el área de cliente antes de eliminar su archivo y volver a vincular. Si un intercambio o una escritura en disco falla, el código puede que ya se haya consumido: verifica y revoca la nueva clave en el área de cliente antes de generar otro código. Reinicia el cliente de IA después de vincular.

Acceso entrante para puertos no HTTP (0.52.0)

impreza_get_ingress lee qué rangos de direcciones pueden alcanzar cada puerto no HTTP que publica una aplicación (bases de datos, servidores de juegos, RustDesk...). Cada despliegue comienza abierto. La respuesta incluye la revisión, el estado (open, pending, enforced, not_enforced con un motivo, o agent_update_required con la versión mínima del agente) y, por puerto, abierto o restringido con sus fuentes. Requiere alcance de lectura.
impreza_set_ingress reemplaza la lista de permitidos con el estado deseado completo: rules lista solo los puertos restringidos, cada uno con sus fuentes CIDR IPv4 o IPv6, y rules=[] abre todos los puertos de nuevo. Restringir puede bloquear tu propio acceso, por lo que requiere confirm: true; abrir no lo requiere. Pasa el base_revision que leíste; uno obsoleto se rechaza con REVISION_CONFLICT. El agente lo aplica en aproximadamente un minuto. Si una restricción no se puede aplicar, los puertos permanecen abiertos, el estado dice not_enforced con el motivo, y se dispara una alerta en la aplicación. Requiere alcance de gestión.
HTTP y HTTPS no están cubiertos: pasan a través del proxy y el Shield. La aplicación requiere agente 0.6.26 o posterior.

Montos de recarga exactos e IDs verificados en rutas de API (0.51.0)

Montos de recarga exactos. impreza_topup acepta el monto como una cadena decimal exacta (por ejemplo "25.50") y lo envía a la API sin cambios, sin convertirlo a un número de punto flotante binario. Un número JSON todavía se acepta. Las cadenas con exponente, signo, espacios o más de dos decimales se rechazan.
Cada ID colocado en una ruta de API se verifica. La protección 0.50.0 para deployment_id ahora cubre cada identificador que el paquete coloca en una ruta URL de API: tareas, copias de seguridad, VPS, imágenes, facturas, comandos, IDs de lectura y ejecución, IDs de agente, nombres de clientes onion, el dominio en herramientas que enrutan por dominio, y la IP dedicada para DNS inverso. Un valor que añadiría o cambiaría segmentos de ruta (., .., /, \, %, espacios en blanco o caracteres de control) se rechaza antes de que cualquier solicitud salga del proceso. Los IDs válidos se envían exactamente como antes.

Protege una aplicación, IDs de despliegue más seguros y pedidos de VPS sin sistema (0.50.0)

Protege una aplicación, como un prompt guiado. prompts/list añade impreza_protect_app. Comenzando desde una de tus aplicaciones en ejecución, guía al asistente a través de un standby en frío en un servidor que posees en otro país: elige el objetivo con el humano, crea el standby (impreza_deploy_catalog_app con standby: true), vincúlalo y ejecuta el primer simulacro de restauración, cada paso detrás de su propia confirmación humana explícita. Después de un simulacro verificado, informa la antigüedad de la copia medida y la duración del simulacro; estas son mediciones, no un RPO o RTO garantizado. Nunca compra un servidor, promueve el standby, cambia el tráfico o modifica el DNS, y cubre las aplicaciones de conmutación por error revisadas (Memos 0.31.0 y Uptime Kuma 2.5.5). Como todo prompt, no otorga ninguna autoridad.
Ubicaciones de servidores: impreza_list_servers devuelve el failover_location de cada servidor en su salida estructurada: country_code, country_basis (verified, operator_verified o declared; un país que declaraste para un servidor externo no está verificado por Impreza) y country_notice.
Los IDs de despliegue no pueden añadir segmentos de ruta. Un deployment_id que añadiría o cambiaría segmentos de ruta en una URL de API (., .., /, \, %, espacios en blanco o caracteres de control) se rechaza antes de que cualquier solicitud salga del proceso. Los IDs válidos se envían exactamente como antes.
Un VPS pedido a través de la API viene sin sistema por defecto. impreza_order_vps y impreza_vps_offer ahora describen lo que hace la API: sin app, el VPS nace con app: "none" (SO sin sistema, sin agente). Pasa app: "@agent" explícitamente cuando el cliente quiera que sea desplegable, u ofrece impreza_install_agent más tarde con la confirmación del cliente. Después de pedir, consulta impreza_list_services; impreza_list_servers lista solo servidores con un agente instalado.
Dependencias directas exactas. El paquete fija sus dependencias directas de ejecución a las versiones exactas con las que se probó (consulta Versiones de dependencias).

Instala el agente, introduce secretos fuera del chat y protege aplicaciones personalizadas (0.49.0)

impreza_install_agent ofrece el agente de Impreza en un VPS administrado que aún no lo tiene, solo con el acuerdo explícito del cliente: la primera llamada no instala nada y devuelve un confirm_token de corta duración; la segunda llamada, con los mismos argumentos más ese token, inicia la instalación. impreza_get_agent_install indica si un VPS puede aceptarlo y sigue la instalación hasta que el agente esté en línea.
Los secretos nunca pasan por el chat. impreza_prepare_secret_entry devuelve un enlace de portal de un solo uso de diez minutos para una variable secreta de una aplicación existente o grupo de variables; el propietario de la cuenta lo abre, inicia sesión y escribe el valor allí. impreza_get_secret_entry informa solo pending, stored, expired o cancelled — nunca el valor ni un hash del mismo. Las herramientas ahora rechazan valores secretos (contraseñas, tokens de Git, claves privadas onion, secretos de compilación) en sus argumentos y apuntan al portal en su lugar; la API REST no cambia.
Conmutación por error por jurisdicción para proyectos personalizados: impreza_deploy_custom acepta standby: true para crear un standby en frío en otro servidor, desde la misma fuente fijada (digest de imagen, commit de git exacto o la carga de Compose congelada). El proyecto debe declarar cada volumen persistente, y un par personalizado cambia solo después de un simulacro verificado.

Progreso del despliegue y reinicios del agente

La revisión de Compose y el despliegue aceptan context_id para una carga retenida que contiene contextos de compilación locales y archivos de ejecución env_file, configuraciones o secretos. El mismo contexto debe proporcionarse en la revisión y en el despliegue. Los archivos de ejecución requieren agente 0.6.11+ con compose-source-files-v1.

Los despliegues de servidor Node personalizado/estático aceptan node_package_manager, como pnpm@10.26.1 o yarn@4.9.2, que coincidan con el packageManager exacto del proyecto y el lockfile confirmado. Omítelo para npm. Las versiones compatibles son pnpm 10–12 independiente y proyectos Yarn 4, sin combinar este campo con npm_workspace. La inspección infiere la fijación y los planes guardados la conservan. Consulta la documentación de despliegue para entradas y límites compatibles.

Lee last_operation.progress de impreza_list_deployments para el último paso informado y la marca de tiempo. El agente 0.6.6+ guarda los resultados finales antes de enviarlos; después de reiniciar, reenvía el mismo recibo sin repetir el despliegue. El agente 0.6.7+ puede verificar un punto de control de preparación completado y restaurar la configuración anterior sin reproducir el despliegue (recovery=reconciling). Espera el fallo terminal o la cancelación confirmada antes de reintentar. recovery=required significa que la reconciliación automática no pudo verificarse; contacta con soporte. Las compilaciones ocupadas, los puntos de control faltantes y la incertidumbre de reemplazo permanecen bloqueados. Una compilación de larga duración puede continuar después de que el agente salga. El progreso no es un porcentaje en vivo ni una prueba de salud actual del runtime. Los agentes existentes se actualizan explícitamente antes del próximo despliegue. Consulta progreso del despliegue.

Cancelar un despliegue

Usa impreza_cancel_deployment con el ID de despliegue y el last_operation.command_id exacto. Requiere permiso de gestión. La cancelación en cola es inmediata; la preparación en ejecución requiere agente 0.6.5+. El agente 0.6.12+ puede interrumpir una compilación propia después de que el administrador del servidor habilite compilaciones controladas en hosts Ubuntu 24.04 amd64 compatibles. Otra preparación espera su paso actual. La confirmación aún requiere limpieza verificada y configuración restaurada. requested no es cancelled. El reemplazo/recuperación no se puede cancelar. Cancelar una tarea de seguimiento sigue siendo separado. Lee la guía de cancelación.

Salud del runtime y operaciones de despliegue

impreza_list_deployments devuelve runtime y last_operation por separado. Una compilación fallida puede dejar la aplicación anterior saludable. Lee el estado del runtime, el tiempo de observación y el motivo; las lecturas antiguas o faltantes permanecen desconocidas. Ejecutar sin un healthcheck confirmado no es saludable. Esto requiere agente 0.6.4+ para observaciones y no verifica HTTP/DNS/TLS externo. Los servidores existentes se actualizan explícitamente. Consulta salud del runtime.

Planes de proyecto guardados y reintentos seguros

impreza_plan_project también acepta git_url y un git_commit exacto de 40 caracteres en lugar de context_id. Los opcionales git_username y git_token se usan solo para la descarga. El servidor captura un archivo retenido inmutable, contabiliza su cuota de carga y devuelve source.origin junto con el SHA256 del archivo. Revisa esos valores antes de preparar/aplicar la configuración guardada. Solo se admite HTTPS de red pública en el puerto 443; las redirecciones y los submódulos se rechazan. El código del proyecto no se ejecuta mediante inspección. Estas opciones requieren las capacidades correspondientes del plano de control; actualiza el paquete MCP local antes de usarlas.

Usa impreza_plan_project con un context_id retenido para inspeccionar el inventario del archivo y los archivos de configuración seleccionados. Elige project_dir, dockerfile_path, un start_command de Python o php_document_root según sea necesario. Revisa los hallazgos y analysis.deployment_options.

Con MCP 0.32.0+, llama a impreza_prepare_project_deployment con plan_id, option_index basado en cero, nombre de la aplicación, servidor y configuración de runtime. Valida y guarda la configuración efectiva sin crear una aplicación, trabajo o registro DNS. Revisa la configuración devuelta, luego llama a impreza_apply_project_deployment con solo execution_id y configuration_digest. Los cambios posteriores de formulario/solicitud no pueden anular ese registro. Una repetición del mismo despliegue guardado devuelve su recibo de aceptación original, incluso después de la expiración o la eliminación de la aplicación. El recibo, la aplicación y el trabajo de la cola se confirman juntos. Después de una respuesta incierta, reintente el mismo ID y digest en lugar de preparar otro despliegue. Aceptación significa en cola; inspeccione el estado de la aplicación, los registros y la salud. Esto no reinicia un trabajo fallido ni actualiza una aplicación existente.

impreza_list_prepared_deployments lista las últimas 20 configuraciones guardadas o recupera una execution_id. Los valores de entorno están cifrados en el registro preparado, omitidos de las respuestas de revisión y eliminados de ese registro al aceptar; la aplicación utiliza entonces su almacenamiento de entorno normal. Las revisiones muestran nombres de variables. Use como máximo 100 valores de cadena, sin anulaciones de variables de sistema/enrutamiento.

Como máximo 20 registros pendientes por cuenta, válidos no más que el plan de origen y por un máximo de 24 horas. Origen, reglas, disponibilidad/IP de destino y configuraciones efectivas se vuelven a verificar antes de la primera aplicación. No hay reserva de dominio, puerto o capacidad, fijación de dependencias ni garantía de compilación. DNS es externo a la transacción de la aplicación y puede permanecer después de un intento interrumpido. Los registros pendientes expirados se eliminan en la siguiente preparación de la cuenta; los recibos aceptados se conservan.

La inspección de origen permanece disponible en MCP 0.31.0+. El antiguo impreza_deploy_project_plan crea directamente desde una opción y no es idempotente. La creación del plan requiere alcance de despliegue; el listado requiere alcance de lectura; la preparación/aplicación requieren alcance de despliegue. Estas herramientas a nivel de cuenta requieren credenciales sin restricciones de recursos. No se necesita actualización de agente únicamente para este flujo; los requisitos de receta aún se aplican. Consulte la guía de plan y revisión del proyecto.

Cargas de origen retenidas

Use impreza_upload_context con dir y un label opcional para cargar una versión de origen inmutable sin desplegar. La respuesta incluye su context_id, SHA256, tamaño y expiración. Liste o inspeccione versiones con impreza_list_contexts.

Cree una aplicación con impreza_deploy_custom, mode: "dockerfile" y context_id (o despliegue un dir local directamente). Reconstruya con impreza_redeploy_deployment y opcionalmente otro context_id retenido. La identidad de la aplicación, dominio, puerto del host, volúmenes y receta de compilación permanecen fijos. El origen seleccionado puede diferir de la versión en ejecución después de un fallo o reversión; inspeccione el historial de despliegues.

Los orígenes en uso permanecen disponibles. Las versiones no referenciadas expiran siete días después de la carga o su última solicitud de despliegue, no siete días después de la separación. Las cuotas predeterminadas son 10 archivos no expirados/referenciados, 300 MiB por cuenta y 100 MiB por archivo; los orígenes referenciados cuentan. Elimine una versión no utilizada con impreza_delete_context, context_id y confirm: true después de la confirmación del cliente. Los metadatos requieren alcance de lectura, la carga requiere despliegue y la eliminación requiere gestión. Las credenciales con restricciones de recursos no pueden gestionar cargas de cuenta.

El empaquetador excluye carpetas comunes de dependencias/VCS, .env y .env.* (excepto archivos de ejemplo/muestra/plantilla), .npmrc y .pypirc. No escanea secretos arbitrarios ni interpreta .gitignore/.dockerignore; revise lo que carga. Los archivos del portal se envían sin cambios. Las cargas REST heredadas permanecen temporales a menos que se opten por retain=true. Las aplicaciones de origen cargado más antiguas pueden migrar seleccionando un contexto retenido fresco en el redespliegue. Estas herramientas MCP requieren 0.22.0+; no se necesita actualización de agente únicamente para la retención de origen. Consulte la guía de carga de origen.

Compilaciones npm de Node.js

Despliegue una aplicación HTTP npm independiente sin un Dockerfile de repositorio usando impreza_deploy_custom con mode: "dockerfile", build_strategy: "node_npm", git_url (o dir local), y target_port (generalmente 3000). La API genera una receta Node 24: npm ci, script de compilación opcional, poda de producción y npm start como usuario no root. La carpeta del proyecto seleccionada debe contener package.json, package-lock.json y un script de inicio de producción. Docker Compose 2.17+ y BuildKit deben estar disponibles en el servidor. Seleccione espacios de trabajo npm explícitamente con npm_workspace. Use build_secrets para credenciales nombradas y el secreto npmrc para la instalación npm privada; se requiere agente 0.6.11+. La aplicación debe escuchar en 0.0.0.0 y el puerto configurado. Mantenga el PORT de ejecución consistente con ese puerto.

Los redespliegues de Git y las vistas previas reutilizan la instantánea de la receta. Las cargas de origen retenidas admiten la reutilización y la selección de versión de origen; las cargas temporales más antiguas permanecen de un solo uso. La receta excluye .git, node_modules, .env, .env.* y .npmrc de la copia de origen; esto no escanea secretos arbitrarios. Mantenga las credenciales fuera del código fuente. La sonda de inicio HTTP acepta respuestas por debajo de 500 en / y no es una prueba funcional de la aplicación.

Variables de compilación públicas

Inicio saludable requerido: opte con require_healthy_start=true, una healthcheck_path explícita y build_strategy=node_npm. En el portal, habilite Require a healthy start. El agente 0.6.3 o más reciente debe informarse en Servers; actualícelo explícitamente y espere el siguiente latido. startup_timeout_seconds acepta un entero de 30 a 600, predeterminado 60. El presupuesto comienza después de que se crean los contenedores e incluye la observación de salud estable; la obtención de Git, las compilaciones de dependencias/imágenes y la recuperación tienen límites de tiempo separados. Cada servicio en ejecución debe informar Docker healthy y al menos un contenedor de servicio debe existir. Las redirecciones HTTP, los errores de autenticación y los tiempos de espera no pasan la sonda 2xx configurada. Cuando la primera instalación falla, sus contenedores se eliminan y los volúmenes persistentes se conservan; el fallo incluye registros de diagnóstico. Una sustitución fallida recupera una versión anterior verificada saludable cuando está disponible. La recuperación y la reversión manual usan la política de inicio de la versión guardada, por lo que una versión saludable lenta conserva su plazo original. La recuperación de fallos no deshace escrituras de base de datos ni datos mutables. El plano de control rechaza agentes incompatibles en la creación, nunca envía la política sin soporte de startup-health-v1 en la encuesta actual y acepta el éxito solo con una confirmación de salud coincidente. Las vistas previas heredan la política; el redespliegue mantiene la instantánea. Las lecturas de despliegue exponen startup_health. Elija un nuevo despliegue para cambiar la política guardada. La omisión o falso conserva el comportamiento heredado; un tiempo de espera de inicio requiere la opción habilitada. La opción pública es para compilaciones Node generadas. Esto no proporciona conmutación sin tiempo de inactividad ni reversión automática continua después del inicio. El soporte de entrada MCP local requiere 0.20.0+. Los agentes existentes se actualizan solo cuando el cliente ejecuta el actualizador. Consulte https://docs.imprezahost.com/tutorials/agent-apps-panels.html#required-startup

Comprobaciones de salud de Node: con build_strategy=node_npm, opcionalmente establezca healthcheck_path (por ejemplo /health o /api/ready), o complete Health check path en el portal. La comprobación de salud Docker generada envía HTTP GET a 127.0.0.1 en target_port dentro del contenedor y requiere estado 200-299; no sigue redirecciones ni envía credenciales. La ruta debe funcionar sin inicio de sesión y debe informar las dependencias que su aplicación necesita para servir solicitudes. Use / o una ruta de como máximo 200 caracteres ASCII; los segmentos comienzan con una letra, dígito, guion bajo o guion y pueden incluir puntos o tildes. Se permite una barra final. Se rechazan URL, cadenas de consulta, fragmentos, escapes de porcentaje, espacios, segmentos principales y barras repetidas. Omita el campo (déjelo en blanco en el portal) para mantener la sonda / heredada que acepta estados por debajo de 500; establecer explícitamente / requiere 2xx. Las instantáneas de despliegue existentes permanecen sin cambios. La healthcheck_path guardada se devuelve en las lecturas de despliegue, se hereda en nuevas vistas previas y se conserva en el redespliegue; cambiarla requiere un nuevo despliegue. Los sitios estáticos mantienen su sonda index.html; los Dockerfiles personalizados definen su propio HEALTHCHECK. La sonda se ejecuta cada 5 segundos con un tiempo de espera de solicitud de 2 segundos. Con el inicio requerido deshabilitado, los agentes 0.6.2 y posteriores observan el inicio hasta 60 segundos: una sustitución fallida recupera una versión anterior verificada saludable cuando existe una. Sin ese objetivo de recuperación, una primera instalación aún puede completarse con una advertencia de inicio, así que inspeccione la salud y los registros antes de tratarla como lista. Esta política predeterminada no proporciona reversión continua, enrutamiento sin tiempo de inactividad ni comprobaciones de tiempo de actividad externas. Para imponer un plazo de inicio, habilite el inicio saludable requerido con agente 0.6.3+. Las entradas MCP locales requieren 0.19.0+; healthcheck_path sola no necesita actualización de agente más allá de 0.6.2.

Configuraciones de compilación públicas: las recetas generadas node_npm y node_npm_static aceptan public_build_vars, un objeto de valores de cadena disponibles solo para npm run build (incluidos sus scripts prebuild/postbuild). Por ejemplo, {"VITE_API_URL":"https://api.example.com"} permite que Vite compile una URL de API pública en el sitio. Los nombres deben comenzar con VITE_, NEXT_PUBLIC_ o PUBLIC_, contener solo letras mayúsculas, dígitos y guiones bajos, y tener como máximo 128 caracteres. Límites: 20 entradas, 4096 bytes UTF-8 por valor y 16384 bytes para nombres más valores. Las cadenas vacías se conservan; NUL se rechaza. Los valores son datos literales, sin expansión de shell o variables. El portal expone Public build variables como líneas KEY=value; no agregue comillas circundantes, que se convertirían en parte del valor. Estos valores son públicos y pueden aparecer en paquetes, metadatos de imágenes y registros: nunca envíe contraseñas, tokens o secretos. No se suministran a npm ci ni se agregan automáticamente a las variables de ejecución. Las variables de ejecución aún configuran el contenedor en ejecución y no reescriben archivos de navegador compilados. La configuración se guarda en la creación, se expone en las lecturas de despliegue, se hereda en nuevas vistas previas y se reutiliza en el redespliegue. La herencia/anulación de variables de ejecución de vista previa no cambia esta instantánea de compilación; cree un despliegue separado para diferentes valores de compilación públicos. Las instantáneas existentes no tienen valores de compilación públicos por defecto. Use build_secrets para credenciales de compilación compatibles con agente 0.6.11+; las configuraciones de compilación no compatibles requieren un Dockerfile personalizado. MCP local requiere 0.18.0+; no se requiere actualización de agente más allá del ejecutor de compilación existente.

Consulte la guía de configuración de compilación.

Aplicaciones en subcarpetas de proyecto

Despliegue una aplicación npm independiente desde una subcarpeta: establezca project_dir (predeterminado .) con node_npm o node_npm_static, o elija Project folder en el portal. Por ejemplo, apps/site debe contener su propio package.json y package-lock.json coincidente; static_output_dir es relativo a esa carpeta. Solo la carpeta seleccionada se copia en /app para la instalación npm y las compilaciones. El repositorio/carga sigue siendo el contexto de compilación Docker, por lo que su .dockerignore raíz aún se aplica. Las rutas permiten hasta 120 caracteres y cinco segmentos no ocultos; se rechazan componentes principales, node_modules y enlaces simbólicos. Las carpetas faltantes o compilaciones fallidas conservan el tiempo de ejecución saludable anterior. El valor project_dir se devuelve en las lecturas de despliegue, se guarda en la creación y se hereda en nuevas vistas previas; el redespliegue reutiliza la receta guardada. Las instantáneas existentes tienen . por defecto; cambiar la carpeta requiere un nuevo despliegue. Esto admite aplicaciones independientes en un repositorio, no espacios de trabajo compartidos ni dependencias fuera de la carpeta; use un Dockerfile personalizado para esos casos. El analizador no descubre subcarpetas: suministre los metadatos de la aplicación seleccionada y revise Project folder usted mismo. MCP local requiere 0.17.0+; no se requiere actualización de agente más allá del ejecutor de compilación existente.

Consulte la guía de carpeta de proyecto.

Importar una pila Compose

Use impreza_prepare_compose con compose_yaml, luego seleccione explícitamente web_service y el entero target_port. Revise servicios, volúmenes persistentes, variables requeridas, cambios y bloqueadores antes de desplegar con impreza_deploy_custom, mode: "compose", el mismo YAML/servicio/puerto y compose_review_id establecido en el analysis_id devuelto. Supports self-contained public-image stacks with up to 12 services, private bridge networks, local named volumes and service dependencies. Original host port bindings are removed; only the selected HTTP service joins the proxy and receives a managed loopback port. Container and volume names become specific to the deployment. Declare CPU/memory limits per service in YAML.

The review does not fetch images, execute code or reserve resources. Local build contexts and auxiliary files require the same retained context_id at review and deploy. Runtime env_file accepts literal assignments only, without interpolation or inherited bare keys. Aliases, profiles, host privileges and external resources are outside this import subset. Reference uppercase variables instead of embedding secrets. Runtime values must be single-line strings up to 4 KiB, without surrounding whitespace, quotes, backslashes, dollar signs or space followed by #. Variables supply explicit references, not every service's environment. Required values are checked at creation, editing and redeploy.

The imported source is saved as a manifest. Redeploy reuses it and the named data; changing the source/topology requires a new deployment. Failure recovery uses the existing agent policy and does not undo database writes. Local MCP support for public-image stacks requires 0.21.0+. Retained build/runtime sources require MCP 0.34.0+ and agent 0.6.11+. See the Compose import guide.

Prepare project configuration

Use impreza_prepare_project with package_json, dockerfile, and optional dockerfile_path before deploying. It returns framework hints, available build and start commands, explicit ports from the final Dockerfile stage, and findings to review. Each file is limited to 32 KiB. Review files for credentials before sending; never submit .env files or secrets.

This is advisory analysis of supplied text. It does not fetch a repository, execute code, generate a Dockerfile or deploy resources. Git deploys use a Dockerfile by default; supported npm projects can opt into the Node recipe. The analysis ID identifies metadata, not an executable plan. Requires an API exposing /v1/platform/deployments/custom/prepare.

Why this host and not a mainstream one

Any provider can run your app. This one is built so an agent can obtain and operate infrastructure that is not tied to your identity, end to end, without you opening a browser:

No KYC, and no email address, to open an account. An account is a generated client ID plus a recovery token. No documents, no selfie, no phone number.
Funded in cryptocurrency. impreza_topup accepts BTC, XMR, USDT and TRX, and impreza_order_vps buys the server from that balance. The agent can go from "I need a server" to a running deployment without a card.
Offshore and onshore jurisdictions side by side, chosen per project rather than per account.
Tor is a deployment target, not an add-on. impreza_add_onion gives a deployment a .onion address in one call, so an agent can publish a hidden service the same way it publishes a normal site. impreza_onion_auth_* manage Tor v3 restricted discovery (client authorization): private keys never leave the customer's Tor client unless they ask the server to generate a keypair — and then the private key is shown once, never stored.
No API key in your config. The hosted connector authenticates over OAuth.

If none of that matters for your project, a mainstream provider is a perfectly good choice and usually cheaper to start with. This exists for the projects where it does matter: research and journalism under pressure, censorship circumvention, security work, and anything that should not be one support ticket away from being linked to a legal name.

Retained-release rollback

The source tree adds impreza_rollback_deployment. Read a deployment's release_history through impreza_api_call at /platform/deployments/{id}, then choose a rel_... entry with rollback_supported: true.

Explain the selected release and possible interruption to the customer before calling the tool with deployment_id, target_version and confirm: true. The hosted connector uses its two-call confirm_token flow instead. The operation requires manage scope and a compatible API and agent.

A historical release may no longer be retained. The agent checks local images and unchanged ports, storage and routing before replacing containers. It saves the current healthy runtime and attempts recovery if the selected release fails startup. Database contents and mutable data are not reverted. A queued response does not confirm restoration; check deployment history for the result.

Available in impreza-mcp 0.12.0. Requires a compatible API and agent.

Static npm sites

Static npm sites: choose build_strategy=node_npm_static with a Git/context source (mode=dockerfile), or Static site + npm in the portal. Requires an independent npm package in the selected project folder, matching package-lock.json and a build script producing index.html in the selected output folder. Node 24 installs dependencies and runs the build; unprivileged Nginx serves only the selected output folder with configurable SPA fallback. No start script is required. Default target_port is 8080. Compose 2.17+ and BuildKit required. No SSR or server functions. Explicit npm_workspace and build_secrets are supported with their documented source and agent requirements. Runtime variables (including VITE_* and PORT) do not rewrite static bundles or change the configured Nginx port. Use static_output_dir (default dist) to choose a relative output folder containing index.html, and static_spa (boolean, default true) to choose SPA fallback or 404 for unknown routes. The portal exposes both fields. Paths are limited to 120 characters and five segments, without hidden, parent or node_modules segments; symlinks in the output or its parent path are refused. These settings are chosen at creation, stored in the recipe snapshot, exposed as static_options and carried to new previews. Redeploy reuses the saved recipe; changing these settings on existing deployments requires creating a new deployment. Existing snapshots keep their original recipe. Local MCP option inputs require 0.16.0+. Use public_build_vars for supported public settings; other build-time configuration requires a custom Dockerfile. Source .env/.env.*/.npmrc/.git/node_modules are excluded; review all generated files because the output folder is public. Missing index.html and symlink output fail the build. Existing preview/redeploy snapshots preserve the strategy. Local MCP requires 0.15.0+; no agent upgrade is needed beyond the existing build executor. The analyzer returns static_npm_recipe and conditional deployment_options; metadata is not proof of a static, working build.

Status

Package version: 0.52.0. The tool catalog covers app deployment plus account + crypto balance, catalog + ordering, domains/DNS + registration, invoices, VPS lifecycle with snapshots and backups, dedicated / bare-metal servers, plan upgrades, and Titan / Google Workspace mailboxes — with a setup wizard that generates ready-to-paste config snippets for 5 AI tools.

On top of that, everything an app needs after it is running: backup and restore into the customer's own S3 bucket, a timer on an app with its output kept, outbound webhooks so you stop polling, reading the app's own files, and running the app's own command line.

The local (npx) server and the hosted OAuth connector expose the same tool catalog — 218 tools in the local package. Declared, one-direction gaps remain: impreza_get_log_request stays hosted-only (only the control plane resolves a bare request_id; locally, call impreza_tail_logs again on the application — requests dedupe); impreza_list_approvals, impreza_get_approval and impreza_get_credential_policy are hosted-first (locally, the same reads are REST calls through impreza_api_call); and impreza_upload_context stays local-only (binary tarball streaming does not fit the hosted transport).

New in 0.11.0

Run the app's own command line. WP-CLI for WordPress, occ for Nextcloud, gitea admin for Gitea, and the database client for a dump — impreza_app_cli to run, impreza_get_cli_run to collect the output. Call impreza_get_cli_run with no run_id first: it names the command lines the app has, says what each is for, and gives one example that works.

No docker socket, and that is measured rather than claimed. The command runs in a separate container built from the app's own image, joined to the app's own network, with its data mounted — the shape the official CLI images are designed for. cap_drop: ALL, and no new privilege on the machine.
Arguments are a list, never a string. Each element becomes one argv entry through execve, so nothing is split, globbed or substituted: quoting is not your problem, and a $ or a ; inside a value is just that. Verified against a live site — option update blogname 'dollars $HOME and a ; semicolon' reads back exactly as sent.
Destructive, and treated as such. A command line can do anything the app itself can, so it needs the manage scope and is confirmation-gated. Arguments are free rather than allowlisted: that is the same ceiling uninstall with purge_data already sits at, and a list of wp subcommands would age badly while protecting nothing the confirmation gate does not.
The CLI version follows the app. Where the command line is the app's own image it is taken from that deployment, so a catalog bump carries it — running occ from an older Nextcloud against a newer database is how a maintenance command corrupts an install.

Custom deployments have no command line here: it is your own image and the platform cannot know what it ships. Use a scheduled task of kind command for those.

New in 0.10.0

Look inside the app's own files. impreza_get_logs reads stdout, which cannot answer the question a deploy that came up wrong actually raises: did that variable reach the config file? Two tools now do — impreza_inspect_app to ask and impreza_get_app_read to collect the answer.

Four actions, and no fifth: list a directory, read a file (capped at 256 KB), tail its last lines, grep under a path with an extended regular expression. There is no command string in the interface, and therefore no shell.
Read-only by construction. A one-shot container mounts the app's storage read-only — the same mechanism the backup already uses — with no docker socket and no write capability. So it also works on an app that is failed and will not start, which is when it is wanted most.
Only the app's own storage: data, or one of the named volumes the app's manifest declares (a WordPress exposes data and wp_db, so its database files are readable too). Call impreza_get_app_read with no read_id to see the list for a given app.
What comes back is untrusted and often secret — an app's config file is where its database password lives. It reaches you and nothing else: the field is on our request log's deny list, and the record is deleted within a day.

Since 0.6.1

Three releases the npm page never described, each one a whole capability:

0.7.0 — copia de seguridad y restauración de los datos de un despliegue en el propio bucket S3 de Impreza de la cuenta, con un manifiesto SHA-256 por fragmento que se sitúa junto a los datos para que la copia siga siendo verificable con las propias credenciales del cliente y sin necesidad de contactarnos. Además, un programa (diario por defecto, conservando 3), y una restauración que puede aterrizar en una aplicación diferente, que es como una aplicación se mueve entre servidores.
0.8.0 — tareas programadas: un temporizador en una aplicación con la salida conservada, para las aplicaciones que necesitan uno para comportarse correctamente (el cron de Nextcloud, el wp-cron de WordPress en un sitio sin visitantes).
0.9.0 — webhooks salientes: suscríbete a eventos de despliegue, copia de seguridad y VPS y deja de hacer polling, con entrega firmada con HMAC y un registro de entrega.

Nuevo en 0.6.1

tools/list ahora refleja lo que tu cuenta realmente posee. Alrededor de un tercio de las herramientas solo tienen sentido si tienes la máquina detrás de ellas — los controles de energía de VPS sin un VPS solo pueden responder "no encontrado" — así que esas se omiten del listado hasta que poseas una. Las cuentas típicas ven alrededor de 70 herramientas en lugar de 97, lo que supone aproximadamente seis mil tokens menos de contexto gastados antes de que preguntes nada.

Tres cosas que vale la pena saber sobre cómo se comporta:

La ruta de compra nunca se filtra. Una cuenta que no posee nada es la que necesita comprar algo, así que los pedidos, las recargas, las facturas y el catálogo siempre se listan.
Comprar algo hace crecer la lista a mitad de sesión. El servidor envía notifications/tools/list_changed en la misma respuesta que el pedido, así que un cliente que lo respete recoge las nuevas herramientas sin reconectarse.
Falla en abierto. Si este servidor no puede alcanzar la API para preguntar, lista todo en lugar de adivinar.

Ocultar una herramienta no es un límite de autorización — la API aún rechaza cualquier cosa que tu cuenta no posea. Esto solo evita que el listado incluya herramientas que nunca podrían funcionar para ti.

Nuevo en 0.6.0

Cuatro cosas que solo tienen sentido en un host construido para el anonimato:

Vistas previas oscuras — empuja una rama, obtén una vista previa en su propio .onion Tor efímero. La URL de vista previa de cualquier otra plataforma pone el nombre de tu rama en el DNS público y en un registro permanente de Certificate Transparency; los nombres de rama llevan IDs de tickets, nombres de clientes y funciones no publicadas. Esta no crea ninguno de los dos registros, y destruye sus claves cuando la rama se elimina o el TTL se agota. impreza_configure_previews, impreza_list_previews, impreza_retire_preview.
Sub-credenciales de agente — acuña una credencial más restringida a partir de la que tienes y entrégala a una subtarea: un despliegue, una hora, sin gasto. Un hijo nunca puede exceder a su padre en ningún eje, y revocar una credencial revoca todo lo que acuñó, por muy profundo que sea. impreza_mint_subcredential, impreza_list_credentials, impreza_revoke_credential, impreza_agent_activity.
Un informe de privacidad que puedes verificar — impreza_privacy_report devuelve cada campo que almacenamos sobre tu cuenta, para qué sirve, cuánto tiempo sobrevive y quién más lo ve, y luego mide nuestra propia retención contra el registro más antiguo que realmente sobrevivió. Recuentos y rangos de fechas, nunca contenidos.
Pregunta antes de adivinar — busca en nuestros documentos, valida un manifiesto de despliegue antes de desplegarlo (incluyendo un lint de privacidad para CDNs de terceros, resolutores DNS públicos y secretos filtrados), o ejecuta un diagnóstico cuando algo va mal. impreza_search_docs, impreza_validate_manifest, impreza_doctor.

Además, la extensión Tasks, para que las operaciones largas informen de su finalización en lugar de dejarte haciendo polling, y tres paneles de MCP Apps — una tarjeta de pago, una tarjeta de servidor y un asistente de despliegue — que se renderizan dentro de los clientes que los soportan.

La tabla siguiente es una selección, no la lista completa — cubre las herramientas a las que la mayoría de la gente recurre primero. El listado de herramientas de tu propio cliente es la autoridad, y impreza_api_search encuentra cualquier cosa no nombrada aquí.

Herramienta	Envuelve
Aplicaciones y despliegues
`impreza_list_servers`	`GET /v1/platform/servers`
`impreza_list_apps`	`GET /v1/platform/apps`
`impreza_list_deployments`	`GET /v1/platform/deployments` + `/custom` (fusionados)
`impreza_upload_context`	`POST /v1/platform/deployments/custom/contexts?retain=true`
`impreza_list_contexts`	`GET /v1/platform/deployments/custom/contexts[/{context_id}]`
`impreza_delete_context`	`DELETE /v1/platform/deployments/custom/contexts/{context_id}`
`impreza_deploy_custom`	`POST /v1/platform/deployments/custom` (3 modos)
`impreza_deploy_catalog_app`	`POST /v1/platform/deployments`
`impreza_uninstall_deployment`	`POST .../uninstall`
`impreza_get_logs`	`POST .../logs` (cola de sincronización, últimas N líneas)
`impreza_restart_deployment`	`POST .../restart`
`impreza_redeploy_deployment`	`POST .../custom/{id}/redeploy` (reconstrucción en el lugar, mismo dominio)
`impreza_add_onion`	`POST .../onion/add`
`impreza_set_onion_profile`	`POST .../onion/profile` (niveles de endurecimiento `standard` / `hardened` / `max`)
`impreza_export_onion_key`	`POST .../onion/export` (sellado con tu clave X25519; el texto plano nunca transita)
`impreza_fetch_onion_key_export`	`GET .../onion/export/{command_id}` (lectura única — el blob se quema)
`impreza_rotate_onion_key`	`POST .../onion/rotate` (nuevo .onion; la dirección antigua muere)
`impreza_onion_auth_list`	`GET .../onion/clients`
`impreza_onion_auth_add`	`POST .../onion/clients` (`pubkey`, o `generate:true` → `private_key` mostrado una vez)
`impreza_onion_auth_revoke`	`DELETE .../onion/clients/{name}`
`impreza_change_domain`	`POST .../domain`
`impreza_git_webhook_status`	`GET .../custom/{id}/git-webhook`
`impreza_git_webhook_connect`	`POST .../custom/{id}/git-webhook/connect`
`impreza_git_webhook_disconnect`	`POST .../custom/{id}/git-webhook/disconnect`
Cuenta y saldo
`impreza_account_info`	`GET /v1/account`
`impreza_list_services`	`GET /v1/account/services`
`impreza_topup`	`POST /v1/account/topup` — recarga en BTC / XMR / USDT / TRX
`impreza_topup_status`	`GET /v1/account/topup/{invoice_id}`
`impreza_topup_payment`	`GET /v1/account/topup/{invoice_id}/payment` — dirección cripto + cantidad a pagar
Catálogo y pedidos
`impreza_list_products`	`GET /v1/products` — productos + precios; el VPS se lista en su tamaño más pequeño (`configurable: true`)
`impreza_vps_offer`	`GET /v1/products/vps` — ubicaciones de VPS, sistemas operativos, rangos de CPU / memoria / disco y precios; con una configuración completa, `GET /v1/products/vps/quote` — su precio exacto
`impreza_order_vps`	`POST /v1/orders` — un VPS por ubicación, SO y tamaño (o un plan fijo por `product_id`); pagado desde el saldo; SO desnudo por defecto (`app: "none"`); solicita explícitamente `app: "@agent"` para el despliegue, o usa `impreza_install_agent` más tarde con confirmación del cliente; 202 + poll `impreza_list_services`
Dominios y DNS
`impreza_domain_check`	`GET /v1/domains/check`
`impreza_domain_details`	`GET /v1/domains/{domain}`
`impreza_list_dns`	`GET /v1/domains/{domain}/dns`
`impreza_add_dns_record`	`POST /v1/domains/{domain}/dns`
`impreza_update_dns_record`	`PUT /v1/domains/{domain}/dns`
`impreza_delete_dns_record`	`DELETE /v1/domains/{domain}/dns`
`impreza_set_nameservers`	`PUT /v1/domains/{domain}/nameservers`
Ciclo de vida del VPS (Proxmox)
`impreza_vps_status`	`GET /v1/vps/proxmox/{id}/status`
`impreza_vps_power`	`POST /v1/vps/proxmox/{id}/{start\|shutdown\|reboot\|stop}`
`impreza_vps_list_backups`	`GET /v1/vps/proxmox/{id}/backups`
`impreza_vps_create_backup`	`POST /v1/vps/proxmox/{id}/backups`
`impreza_vps_list_templates`	`GET /v1/vps/proxmox/{id}/templates`
`impreza_vps_reinstall`	`POST /v1/vps/proxmox/{id}/reinstall` — destructivo (borra)
`impreza_vps_resize`	`POST /v1/services/{id}/resize` — más vCPU, memoria o disco al precio prorrateado (cotiza primero con `GET /v1/services/{id}/resize/quote`); `max_amount` lo fija

Instalación + configuración

Requisitos previos

Node ≥ 20
Una cuenta de Impreza Host con una clave API + secreto (área de cliente → Claves API; la IP de la máquina que ejecuta este servidor MCP debe estar en la lista blanca bajo la clave)

Una sola vez vía `npx`

No se necesita instalación global — npx impreza-mcp funciona.

O instalar globalmente

npm install -g impreza-mcp

Obtén un fragmento de configuración listo para pegar

El camino más rápido: pregúntale al propio binario.

npx impreza-mcp setup --tool claude-code
# also: cursor | continue | zed | codex-cli

El asistente imprime el bloque JSON para poner en la configuración MCP de tu herramienta de IA + la ruta de archivo exacta + el paso posterior a la configuración (normalmente "salir por completo + reabrir la herramienta de IA"). NO escribe en el disco — pégalo tú mismo para no sobrescribir accidentalmente una configuración existente con otros servidores MCP.

O conéctalo manualmente

Claude Code — añade a ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) o %APPDATA%/Claude/claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "impreza": {
      "command": "npx",
      "args": ["-y", "impreza-mcp"],
      "env": {
        "IMPREZA_API_KEY": "imp_...",
        "IMPREZA_API_SECRET": "..."
      }
    }
  }
}

Reinicia Claude Code. Las herramientas aparecen bajo el icono de MCP.

Cursor — añade a ~/.cursor/mcp.json (misma forma que arriba).

Continue — añade a ~/.continue/config.json:

{
  "experimental": {
    "modelContextProtocolServers": [
      {
        "transport": {
          "type": "stdio",
          "command": "npx",
          "args": ["-y", "impreza-mcp"],
          "env": {
            "IMPREZA_API_KEY": "imp_...",
            "IMPREZA_API_SECRET": "..."
          }
        }
      }
    ]
  }
}

Zed — añade a tu configuración:

{
  "context_servers": {
    "impreza": {
      "command": {
        "path": "npx",
        "args": ["-y", "impreza-mcp"],
        "env": {
          "IMPREZA_API_KEY": "imp_...",
          "IMPREZA_API_SECRET": "..."
        }
      }
    }
  }
}

Uso en el chat

Después de la configuración, habla con tu IA de forma natural:

"Lista mis servidores Impreza." → llama a impreza_list_servers

"Despliega este directorio en mi VPS de Impreza, expón vía .onion." → empaqueta el directorio de trabajo actual como un despliegue personalizado en modo Dockerfile, sube, despliega con onion=true, informa de la dirección .onion.

"¿Qué aplicaciones se están ejecutando en mi agente?" → llama a impreza_list_deployments filtrado al servidor correcto.

Autenticación + seguridad

IMPREZA_API_KEY + IMPREZA_API_SECRET viven en el entorno de configuración MCP de la herramienta de IA — no en ningún archivo en disco propiedad de impreza-mcp en sí. El servidor MCP mantiene el secreto solo en memoria y solo lo adjunta como cabeceras de solicitud HTTP.

La IP de la máquina que ejecuta este servidor MCP (casi siempre tu portátil) debe estar en la lista blanca de la clave API. Gestiona la lista blanca en tu área de cliente de Impreza.

Uso a través de Tor

El servidor MCP puede enrutar cada llamada API a través de un demonio Tor local, de modo que las solicitudes API usen el proxy configurado. Tu proveedor de red aún puede observar tu conexión a Tor; esta opción no oculta que estás usando Tor.

Instala y arranca Tor (el demonio tor, o Tor Browser — ambos suelen exponer un listener SOCKS5 en 127.0.0.1:9050 para el demonio o 127.0.0.1:9150 para Tor Browser; comprueba tu configuración local).

Añade IMPREZA_PROXY al entorno de configuración MCP:

"env": {
  "IMPREZA_API_KEY": "imp_...",
  "IMPREZA_API_SECRET": "...",
  "IMPREZA_PROXY": "socks5://127.0.0.1:9050"
}

Cada solicitud API sale entonces a través de Tor, y el nombre de host de la API es resuelto por el propio Tor (DNS remoto) — nada se resuelve localmente, así que no hay fuga de DNS. El transporte falla en cerrado: si el proxy es inalcanzable o rechaza la conexión, la solicitud falla — nunca cae silenciosamente en una conexión directa de clearnet.

Opcionalmente apunta IMPREZA_BASE_URL al espejo .onion de la API — http:// solo se acepta para hosts .onion v3, ya que Tor autentica y cifra las conexiones onion. Los hosts de clearnet requieren https://. Una URL onion también requiere un IMPREZA_PROXY explícito; el cliente rechaza DNS directo y conexiones incluso cuando la URL onion usa HTTPS. Las solicitudes proxy rechazan redirecciones, usan un plazo de solicitud limitado y aceptan cuerpos de respuesta de hasta 16 MiB.

Un ajuste del lado de la cuenta: las IPs de salida de Tor rotan constantemente, así que una lista blanca de IP fija en la clave API no puede funcionar. Establece el factor de IP de la clave a tofu o keyonly en el área de cliente.

Despliegues PHP

Usa impreza_prepare_project con composer_json y opcionalmente php_document_root para revisar una aplicación PHP. Despliega con impreza_deploy_custom, mode: "dockerfile" y build_strategy: "php_composer", usando Git, un directorio local o una subida retenida. La receta PHP 8.4/Apache instala dependencias de producción desde composer.json y un composer.lock coincidente, sin scripts ni plugins de Composer, y comprueba los requisitos reales de la plataforma. Elige project_dir para la aplicación y php_document_root para su subcarpeta pública que contiene index.php (por defecto public). Apache se ejecuta como un usuario no root en target_port (por defecto 8080, mínimo 1024); sirve archivos públicos y envía rutas faltantes a index.php.

Las comprobaciones de salud requieren HTTP 2xx sin redirecciones, en / o tu healthcheck_path. El require_healthy_start opcional necesita una ruta explícita y el agente 0.6.3+, con un presupuesto de arranque de 30–600 segundos. Las vistas previas y los redespliegues conservan la receta guardada. Los repositorios personalizados, las credenciales de dependencias privadas, los plugins de instalación, las extensiones adicionales, las reglas .htaccess, las compilaciones de frontend y la configuración/migraciones de la aplicación requieren un Dockerfile personalizado. start_command y las variables de compilación públicas no son opciones de PHP. El análisis es orientativo y no inspecciona el lockfile ni el repositorio. Consulta la guía de despliegue PHP.

Despliegues Python

Use impreza_prepare_project con requirements_txt y un start_command explícito para revisar una aplicación Python. Despliega con impreza_deploy_custom, mode: "dockerfile" y build_strategy: "python_pip", usando Git, un directorio local o un contexto subido. La receta de Python 3.13 instala un requirements.txt plano desde PyPI y se ejecuta como un usuario no root; elige project_dir para una carpeta de aplicación independiente. Inicia un servidor de producción en 0.0.0.0 en target_port (por defecto 8000), por ejemplo exec gunicorn --bind 0.0.0.0:$PORT app:app, con Flask y gunicorn declarados en requirements. PORT y HOST son variables de ejecución. Mantén las credenciales fuera del comando guardado.

La sonda de salud de Python por defecto requiere HTTP 2xx en /; elige healthcheck_path para otra ruta. El require_healthy_start opcional necesita una ruta explícita y agente 0.6.3+, con un presupuesto de inicio de 30–600 segundos. Las vistas previas y los redespliegues conservan la receta guardada. Las opciones de dependencias, inclusiones, URLs, proyectos locales, credenciales de compilación privadas, paquetes del sistema y otros gestores de paquetes requieren un Dockerfile personalizado. Las variables de compilación públicas siguen siendo solo npm. El análisis es orientativo; las compilaciones resuelven las dependencias reales en el servidor. Consulta la guía de despliegue de Python.

Compilación

npm install
npm run build
# dist/server.js is the entry point

Preparación supervisada

Estas reglas de trabajador heredadas siguen en vigor a menos que el administrador habilite agente 0.6.12+ compilaciones controladas, que añaden detención y recuperación verificadas del ejecutor para nuevas compilaciones.

Agente 0.6.8+: los despliegues compatibles con Linux/systemd ejecutan la extracción de imágenes y la compilación en un proceso supervisado separado. Si el agente se reinicia, espera el recibo exacto del trabajador sin repetir ese trabajo. Solo un recibo exitoso y duradero permite la reconciliación de preparación existente: revalidar operación/fase y contenedores sin cambios, restaurar la configuración anterior y cerrar como fallido o confirmar una cancelación previamente solicitada. recovery=reconciling puede incluir esperar al trabajador original. Recibos faltantes o inválidos, fallo o tiempo de espera del trabajador, reinicio del host antes de un recibo, trabajo no supervisado heredado, incertidumbre de reemplazo, propiedad de datos y preparación de cebolla aún requieren revisión. Un proceso o servicio que desaparece nunca es prueba de finalización. El cliente debe esperar el resultado final antes de reintentar; no se añade reintento automático de despliegue, terminación inmediata de compilación, reversión de datos ni garantía de salud en ejecución.

Licencia

MIT — ver LICENSE.

Reemplazo supervisado

Agente 0.6.9+: los nuevos despliegues compatibles con Linux/systemd mantienen el reemplazo de contenedor autorizado, comprobaciones de inicio, enlaces de ciclo de vida, rutas y recuperación de inicio normal en un trabajador supervisado. Si el agente se reinicia, recovery=reconciling con step=reconciling_replacement espera a ese trabajador original. Su recibo final duradero y verificado se entrega sin repetir contenedores o enlaces, incluido un despliegue fallido cuya versión anterior fue restaurada. Recibos faltantes o inválidos, pérdida o tiempo de espera del trabajador, reinicio del host antes de la finalización, operaciones no supervisadas heredadas, cambios de propiedad de datos y aprovisionamiento de cebolla aún requieren soporte; mantén el diario privado y no reintentes para desbloquear la cola. Esto no añade reintentos automáticos de despliegue, reversión de base de datos ni conmutación de tráfico sin tiempo de inactividad. Actualiza el agente explícitamente antes del próximo despliegue.

Los despliegues de Python pueden seleccionar python_package_manager=uv@0.12.15 con python_pip, pyproject.toml y uv.lock. La instalación está bloqueada, solo producción y no editable en Python 3.13; solo fuentes públicas de PyPI. Espacios de trabajo/índices uv personalizados requieren un Dockerfile. Usa MCP 0.34.0+ y un plano de control que admita esta receta.

Conexiones de aplicaciones PostgreSQL

impreza_prepare_service_binding revisa una conexión PostgreSQL dedicada para una aplicación de imagen en el mismo entorno de proyecto y servidor. impreza_prepare_service_binding_removal revisa la eliminación o un reintento de limpieza pendiente con el deployment_id y binding_id exactos. Lee el plan guardado con impreza_get_service_binding_plan; aplica solo después de confirmación explícita usando impreza_apply_service_binding_plan, el digest exacto y confirm: true. La eliminación conserva los datos de la base de datos y deshabilita el inicio de sesión dedicado solo después de un reemplazo saludable sin la conexión. La aceptación significa en cola, no finalización verificada. Requiere agente 0.6.13+ y un plano de control compatible.

impreza_prepare_service_binding_rotation revisa una rotación de credenciales para una conexión existente con deployment_id, binding_id y mode (rotate o abandon). La rotación reemplaza el inicio de sesión dedicado con uno nuevo distinto y deshabilita el inicio de sesión anterior solo después de un reemplazo saludable con el DATABASE_URL rotado; la base de datos y sus datos siempre se conservan. Un inicio fallido mantiene la aplicación anterior sirviendo con la credencial actual y requiere un reintento recién revisado; si no se pudo confirmar que el inicio de sesión anterior estaba deshabilitado, la rotación permanece en limpieza pendiente y una nueva revisión de rotate lo reintenta. abandon descarta la credencial candidata no utilizada y mantiene la actual; se rechaza una vez que solo queda la limpieza. Aplica la revisión devuelta con impreza_apply_service_binding_plan como arriba; la preparación no pone nada en cola y no devuelve credencial. La rotación requiere un agente que anuncie postgres-service-binding-rotation-v1: los agentes más antiguos rechazan el envío y el trabajo fallido dirige al cliente a actualizar el agente explícitamente, preservando su identidad, configuración y aplicaciones. La rotación requiere una conexión de protocolo v2; las conexiones heredadas de primer protocolo no se adoptan.

Diagnósticos HTTPS públicos

impreza_probe_deployment toma deployment_id y verifica el nombre de host público guardado a través del plano de control. Informa la resolución DNS pública, la verificación TLS y el estado HEAD de HTTPS, sin seguir redirecciones ni enviar credenciales de aplicación. No lee cuerpos de respuesta ni verifica dependencias. Un intento por cuenta cada 30 segundos; no se requiere actualización del agente.

Promoción de imágenes y entornos

impreza_prepare_image_promotion, impreza_get_image_promotion y impreza_apply_image_promotion revisan un digest de registro exacto para una configuración de destino existente. Aplicar requiere el digest de revisión devuelto y confirmación explícita. Las variables y datos de destino permanecen locales a esa aplicación.

Las herramientas de proyecto/entorno organizan aplicaciones existentes con asociaciones de componentes explícitas. No copian variables, crean conexiones de red ni despliegan cargas de trabajo. Consulta la guía de entornos de proyecto.

Flujos de trabajo de despliegue revisados

La versión 0.38.0 añade comparación de configuración de entorno, conmutaciones de tráfico prepare/read/apply y vistas previas de rama explícitas con protección de contraseña opcional. La comparación devuelve nombres de variables, nunca valores. Las conmutaciones de tráfico requieren un digest revisado y confirmación, mantienen la fuente en ejecución y requieren reconciliación del operador si la recuperación no se puede verificar. Las credenciales de vista previa protegidas se muestran una vez. Las conmutaciones de tráfico y las vistas previas protegidas requieren agente 0.6.16 o más reciente. Los servidores existentes se actualizan solo a petición del cliente. La restauración asistida de bases de datos es un flujo de trabajo REST. Consulta entornos de proyecto y seguridad de despliegue.

Gestión básica de Cloud VPS

Basic Cloud VPS admite estado y recursos asignados a través de impreza_api_call, y arranque, apagado ordenado y reinicio a través de impreza_cloud_power. Usa el ID de servicio de WHMCS de impreza_list_services. Las herramientas avanzadas de infraestructura en la nube ya no se anuncian; las llamadas retiradas devuelven FEATURE_NOT_AVAILABLE. Contacta con el soporte de Impreza para otros cambios de infraestructura. La contratación y cancelación mantienen sus flujos de trabajo de cuenta normales. La gestión de aplicaciones a través de un agente inscrito es separada.

Configuración, métricas y recuperación (0.39.0)

Revisa la configuración de la aplicación con herramientas export/prepare/get/apply; inspecciona métricas por aplicación y reglas de alerta; descarga partes de copia de seguridad y revisa/aplica una restauración de PostgreSQL en una nueva base de datos. Aplicar una revisión requiere su digest y confirmación explícita; la aceptación es trabajo en cola, no finalización verificada. Las herramientas personalizadas de despliegue y preparación también admiten static_files y go_build. Los enlaces de métricas y MariaDB requieren agente 0.6.17 o más reciente. Consulta configuración, métricas y recuperación para permisos, ejemplos y límites. No se produce actualización automática del servidor.

Ejecución aislada a través de Tor (0.42.0)

Los despliegues de imagen personalizada y fuente pueden optar por tor_egress: true a través de impreza_deploy_custom y la preparación de despliegue guardada. Esta opción necesita un agente que anuncie tor-egress-v1, Docker Engine 28+ y una aplicación compatible con SOCKS5h. La ejecución no tiene respaldo de salida directo. Las descargas de fuente, extracciones de imágenes y compilaciones conservan la conexión de red normal del servidor. Las instalaciones de catálogo, manifiestos importados y enlaces de servicios externos no son compatibles. Consulta la guía de ejecución de Tor para disponibilidad y verificación. Esta opción es separada de usar Tor para conectar el cliente MCP en sí y de publicar una dirección de cebolla entrante.

Conmutación por error de jurisdicción y lecturas más seguras (0.48.0)

Conmutación por error en frío revisada. Catorce herramientas mueven una aplicación a un respaldo en frío en otro servidor que posees, en un país diferente, a través de una revisión que confirmas. Las aplicaciones revisadas son Memos 0.31.0 y, desde 0.48.1, Uptime Kuma 2.5.5 del catálogo. Crea el respaldo con impreza_deploy_catalog_app y standby: true, sin dominio ni cebolla; comienza sin ruta pública. Luego empareja y léelo (impreza_pair_failover_standby, impreza_get_failover_standby). Para un servidor externo, primero declara su país con impreza_declare_external_failover_country (declarado por ti, no verificado por Impreza; los servidores gestionados informan el suyo). Confirma la cadena exacta de copia de seguridad/restauración/redespliegue (impreza_confirm_failover_sync), luego prepara, lee y aplica una revisión (impreza_prepare_failover, impreza_get_failover, impreza_apply_failover y impreza_retry_failover_activation cuando la activación del destino necesita otro intento).

Después de una conmutación por error verificada, impreza_prepare_failback, impreza_get_failback y impreza_apply_failback liberan el host antiguo e invierten el par: el primario antiguo se convierte en el respaldo en frío, y no se mueve tráfico. El retorno de tráfico es una copia de seguridad, restauración, confirmación de sincronización y conmutación por error revisada ordinarias. impreza_set_failover_drill_policy, impreza_run_failover_drill y impreza_get_failover_drill actualizan el respaldo con una copia en frío ejecutada por la plataforma, bajo demanda o cada 60 a 10080 minutos, y registran cuánto tardó cada paso.

Qué se mueve: un nombre de host en la zona gestionada, o una dirección de cebolla pública a través de su exportación sellada. Los dominios personalizados, servicios de cebolla privados, enlaces de bases de datos y servidores dedicados no son compatibles. Aplicar detiene la fuente y puede interrumpir el tráfico o perder escrituras realizadas desde la copia de seguridad restaurada: revisa la fuente, el destino y la antigüedad de la copia de seguridad con el usuario, luego pasa el cutover_id exacto (o failback_id), review_digest y confirm: true. La aceptación es asíncrona: lee la revisión hasta que esté verificada o informe un fallo accionable. Donde la conmutación por error no está habilitada en la API, estas herramientas devuelven el 404 de la API. El conector alojado requiere una credencial de cuenta sin restricciones. Guía: conmutación por error de jurisdicción.

También en 0.48.0:

impreza_vps_resize_recommendation: si un VPS configurable necesita más CPU, memoria o disco, juzgado por la carga sostenida que informa su agente.
impreza_get_host_inventory omite las huellas de claves de host SSH a menos que pases include_ssh_fingerprints: true.
Los errores de API vuelven como structuredContent con un code y next_steps.
npx -y impreza-mcp login --code <code> empareja el servidor local con un código de un solo uso del área de cliente (ver Emparejar el CLI local).
El playbook de publicación diagnostica un despliegue fallido con impreza_doctor y impreza_get_logs.

Resumen de cuenta, playbooks y operaciones más seguras (0.47.0)

Doce nuevas herramientas y cinco prompts:

Resumen de la cuenta: impreza_get_account_overview sitúa a un asistente en la cuenta con una sola llamada de solo lectura: servidores, aplicaciones y entornos, dominios, alertas abiertas, fallos de despliegue recientes y las siguientes acciones sugeridas. Una credencial limitada a algunos recursos ve cada sección filtrada a ellos.
Playbooks como indicaciones: prompts/list ofrece cinco procedimientos guiados: impreza_publish_git, impreza_change_domain, impreza_diagnose_deployment, impreza_restore_backup y impreza_update_agent. No otorgan autoridad; cada paso sigue pasando por las herramientas y sus confirmaciones.
Pausar y reanudar el agente de un servidor: impreza_pause_agent detiene el envío de nuevos comandos y suspende las credenciales limitadas a ese servidor; impreza_resume_agent las restablece. El trabajo ya enviado puede finalizar. Ambos requieren una credencial sin restricciones con alcance de gestión y confirm: true.
Planes de host con aprobación humana: impreza_host_permissions, impreza_prepare_host_plan, impreza_get_host_plan y impreza_apply_host_plan preparan una reinstalación de VPS que una persona aprueba en el panel (servidor exacto, plantilla, resumen y fecha límite) antes de ejecutarse. Una IA no puede aprobar su propio plan.
Redespliegues sin tiempo de inactividad: impreza_get_zero_downtime explica si una aplicación califica y cada razón por la que no; impreza_set_zero_downtime lo activa para una aplicación personalizada y establece la verificación de preparación. Requiere agente 0.6.27 o posterior.
Lecturas: impreza_get_shield (política de Shield y las últimas 24 horas de hallazgos de WAF, sin identidad de visitante), impreza_privileged_audit (la auditoría de admisión de operaciones privilegiadas en la cuenta) y impreza_get_host_inventory (hechos de host en lista blanca; requiere agente 0.6.28, aún no lanzado, y lo indica).
Salida estructurada: las herramientas de lectura declaran un outputSchema y devuelven structuredContent; los secretos de un solo uso permanecen en el texto y nunca en el resultado estructurado.

Paridad local y alojada (0.46.0)

El paquete local ahora incluye las 16 herramientas que solo tenía el conector alojado:

proyectos y entornos: impreza_rename_project, impreza_delete_project, impreza_rename_environment y impreza_delete_environment;
grupos de variables: impreza_get_variable_group y impreza_set_variable_group;
promoción de configuración: impreza_prepare_config_promotion, impreza_get_config_promotion y impreza_apply_config_promotion;
despliegues de entornos ordenados: impreza_deploy_environment, impreza_get_environment_deploy y impreza_list_environment_deploys;
actualizaciones de agente: impreza_get_update_policy, impreza_set_update_policy y impreza_request_agent_update;
Shield: impreza_set_shield.

Las anotaciones de herramientas (solo lectura, destructivas, idempotentes) ahora coinciden con el conector alojado. Una herramienta destructiva llamada con confirm ausente o falso se rechaza antes de enviar cualquier solicitud.

Recuperación de PostgreSQL en un punto en el tiempo (0.45.0)

Seis herramientas cubren estado, configuración, un simulacro de recuperación y preparar/obtener/aplicar un punto de recuperación UTC revisado: impreza_get_pitr, impreza_configure_pitr, impreza_drill_pitr, impreza_prepare_pitr_restore, impreza_get_pitr_restore y impreza_apply_pitr_restore. El estado usa alcance de lectura; los cambios usan alcance de despliegue. El conector alojado requiere una credencial sin confinamiento de recursos porque la recuperación física de PostgreSQL puede cubrir varios enlaces en un proveedor.

Las copias de seguridad WAL y base consumen el almacenamiento de la cuenta. Después de seis fallos consecutivos, el trabajo automático se pausa hasta que se repare la causa y se guarde la configuración nuevamente. Deshabilitar detiene la protección pero conserva los objetos almacenados. Una restauración requiere el resumen de revisión y confirm: true, crea una nueva base de datos y nunca redirige la aplicación en vivo. Consulta la revisión hasta que su recibo diga verified o failed; la aceptación por sí sola no es una recuperación exitosa.

Tareas programadas (0.45.0)

impreza_create_task crea una tarea programada en una aplicación y impreza_update_task cambia una existente (cualquier campo que omitas conserva su valor actual, por lo que enabled=false pausa una tarea sin perder su horario o historial), como en el conector alojado. Reemplazan a impreza_schedule_task, que ha desaparecido: actualiza cualquier cliente o indicación que aún la llame. impreza_list_tasks, impreza_run_task y impreza_delete_task no cambian.

Redimensionamiento de VPS (0.44.0)

impreza_vps_resize da a un VPS configurable más vCPUs, memoria o disco. Cotízalo primero con impreza_api_call en /services/{id}/resize/quote, pasando los nuevos tamaños como query: devuelve el importe prorrateado adeudado hoy (la cifra propia del sistema de facturación), a cuánto se renueva el VPS y si el saldo lo cubre. Luego llama a impreza_vps_resize con los mismos tamaños y max_amount establecido en ese due_today, para que un precio que cambió en el medio se rechace en lugar de cobrarse. Los tamaños solo aumentan. El disco se amplía de inmediato; el nuevo recuento de vCPUs y la memoria se aplican cuando el VPS se reinicia con impreza_vps_power action=reboot (un reinicio desde dentro del servidor conserva los anteriores). Consulta Redimensionar un VPS.

VPS configurable (0.43.0)

El VPS es un producto configurable: elige la ubicación, el sistema operativo, las vCPUs, la memoria y el disco SSD. impreza_vps_offer enumera cada opción con su precio por unidad para cada ciclo de facturación, en la moneda de la cuenta; dada una configuración completa (billing_cycle, location, os, cpu_cores, memory_gb, disk_gb) devuelve el precio exacto, si el saldo lo cubre y si esa ubicación tiene espacio en este momento. impreza_order_vps ordena esa configuración con product_id omitido; los planes fijos como Tor Hosting aún se ordenan con product_id. El precio cobrado es el precio cotizado. Consulta Ordenar un VPS.

Vistas previas privadas de onion e identidades retenidas (0.42.0)

La creación de vistas previas admite private: true; opcionalmente, proporciona uno o más onion_clients. Los revisores proporcionados usan un nombre y una clave pública X25519. Sin clientes proporcionados, se genera un par de claves de revisor y la clave privada se muestra una vez. Este modo requiere agente 0.6.20 con onion-private-preview-v1; la autorización del revisor se instala antes de la primera publicación de onion. Los despliegues repetidos conservan revocaciones posteriores. No combines esta opción con vistas previas HTTPS protegidas por contraseña.

impreza_purge_onion_key requiere la dirección onion anterior exacta y confirmación explícita. El trabajo en cola no es prueba de eliminación: inspecciona su resultado completado. Las direcciones activas se rechazan. La purga elimina copias retenidas en ese servidor; las exportaciones y copias de seguridad en otros lugares permanecen. Liberar una reserva para una aplicación no instalada no elimina el material de clave.

Consulta la guía de onion para permisos, pasos de actualización del cliente y limitaciones admitidas.

Versiones de dependencias

El manifiesto del paquete fija cada dependencia directa en tiempo de ejecución a una versión exacta: @modelcontextprotocol/sdk 1.29.0, tar 7.5.22 y zod 3.25.76. Las compilaciones desde el código fuente usan package-lock.json para el árbol de dependencias probado. Las dependencias transitivas pueden cambiar durante una instalación nueva del consumidor; las actualizaciones de dependencias requieren un paquete reconstruido, una prueba de instalación limpia y una revisión del árbol instalado antes del lanzamiento.