Desarrollo remoto con Zed: SSH, tareas y vistas previas locales

Imagina que trasladas un pequeño proyecto web a un servidor de desarrollo existente. El editor sigue teniendo un aspecto familiar. Pero ¿qué máquina ejecuta una tarea y a dónde apunta el localhost de tu navegador? Estas son las preguntas que debes resolver antes de cambiar la configuración.

El desarrollo remoto de Zed conecta tu editor local con una copia de trabajo mediante SSH. La interfaz permanece en tu portátil; los servidores de lenguaje, las tareas y los terminales se ejecutan en el servidor remoto. La documentación de acceso remoto de Zed explica esta distribución.

Los ejemplos siguientes son propuestas basadas en la documentación. Ninguno se ejecutó para este artículo: no se probó ninguna instalación de Zed ni sesión SSH, y tampoco se validó ninguna aplicación, puerto o llamada de IA. Usa la guía para planificar una configuración y diagnosticar sus límites.

Qué permanece en local y qué se ejecuta en el servidor remoto

Ubica el editor, la copia de trabajo y las rutas de ejecución

Empieza por identificar dónde se realiza el trabajo. Una ventana con aspecto local dice poco sobre el proceso que hay detrás. La arquitectura documentada asigna una ubicación a cada componente:

Un servidor existente con herramientas o datos que tu proyecto necesita te da un motivo para trabajar en remoto. La conexión por sí sola no te proporciona un entorno reproducible ni pruebas de un mejor rendimiento.

Trata las solicitudes de IA como una ruta independiente

La IA necesita su propia revisión. La descripción general del acceso remoto sitúa la comunicación con los modelos en el equipo local, mientras que la documentación de privacidad de IA de Zed distingue las rutas de solicitud para claves de proveedores, pasarelas, agentes externos e hilos de terminal. No puedes deducir a dónde se envía una instrucción a partir de la ubicación de la copia de trabajo.

Empieza con un servidor autorizado y una copia de trabajo dedicada al desarrollo

Confirma el acceso SSH sin debilitar la verificación

Esta guía presupone que ya tienes acceso autorizado a un servidor de desarrollo. Prepara su cadena de herramientas por separado y elige una copia de trabajo dedicada que no sea de producción. El nombre de servidor devbox.example.com es ficticio; sustitúyelo por tu servidor aprobado al planificar la conexión.

En el cuadro de diálogo Proyectos remotos de Zed, elige Conectar un nuevo servidor e introduce la conexión SSH aprobada. Zed utiliza tu binario y tu configuración locales de SSH; su documentación de conexión recomienda la autenticación mediante claves para conexiones repetidas. Mantén activada la verificación de la clave del servidor y sigue el procedimiento de acceso de tu organización. Un error de conexión es un motivo para investigar, nunca para incluir claves privadas en la configuración del proyecto o desactivar la verificación.

Selecciona la propia carpeta del proyecto. La misma documentación advierte de que no se deben abrir directorios raíz demasiado grandes, incluidos la raíz del sistema de archivos o un directorio personal completo.

Comprueba los requisitos del servidor remoto y de la cadena de herramientas

El equipo necesita un binario del servidor de Zed de la versión correspondiente. La documentación de desarrollo remoto enumera equipos con macOS, Linux y Windows con ciertas salvedades, entre ellas que las pruebas de distribuciones de Linux no son exhaustivas. Lee los requisitos de tu equipo concreto antes de adoptar la configuración.

Usa esta lista de preparación:

• Tu acceso SSH aprobado funciona sin debilitar la verificación.
• La plataforma remota puede ejecutar el servidor de Zed de la versión correspondiente.
• La copia de trabajo dedicada y el entorno de ejecución del proyecto ya existen.
• El binario del servidor dispone de una vía de descarga o entrega aprobada.

La opción documentada upload_binary_over_ssh descarga el binario del servidor en local y después lo sube mediante SSH. Las dependencias del proyecto siguen necesitando una preparación independiente, y esta opción no permite utilizar todas las funciones sin conexión. La lista anterior sigue siendo una propuesta hasta que la verifiques en tu servidor.

Sitúa la configuración y las comprobaciones del entorno de ejecución donde corresponda

Separa la configuración local, del servidor y del proyecto

Un cambio de configuración solo ayuda si lo lee el proceso que lo necesita. Ambos procesos de Zed leen la configuración del proyecto, pero ninguno lee el archivo de configuración principal del otro. La documentación de configuración te permite elegir el ámbito adecuado:

Mantén las rutas específicas de cada máquina fuera de la configuración compartida. De lo contrario, la siguiente persona que abra la copia de trabajo heredará una dependencia de tu sistema de archivos.

Comprueba el entorno de ejecución remoto sin volcar las variables de entorno

Para un proyecto Node.js en un servidor de desarrollo de tipo Unix, considera estas comprobaciones de solo lectura en el terminal remoto. Se presupone un intérprete de órdenes de tipo POSIX, la disponibilidad de la utilidad hostname y un entorno de ejecución de Node.js instalado. Ejecutarlas en un intérprete de órdenes independiente del portátil responde a una pregunta distinta de la que necesitas resolver.

hostname
pwd
command -v node
node --version

Sin argumentos, hostname muestra el nombre del equipo; pwd indica el directorio de trabajo. command -v muestra cómo resuelve el intérprete una orden, lo que puede identificar un alias o una función en lugar de la ruta de un ejecutable. node --version muestra la versión de Node.js. La referencia de hostname documenta el comportamiento de la orden, no la compatibilidad de Zed con OpenBSD.

Inspecciona los resultados en privado. ¿Coincide el servidor con la máquina prevista? ¿Pertenece el directorio a la copia de trabajo? Compara el entorno de ejecución encontrado con los requisitos del proyecto. Si falla la localización de la orden, resuélvelo antes de consultar la versión. Aquí no se afirma ninguna salida ni versión esperada, y no es necesario compartir nombres de servidor sensibles ni volcar todas las variables de entorno.

Un resultado correcto en el terminal solo responde a la cuestión del terminal. La documentación del entorno de Zed describe diferencias en el tratamiento de los inicios desde la línea de órdenes y la interfaz gráfica, las tareas, los terminales y la búsqueda de servidores de lenguaje. Comprueba por separado la localización del binario del servidor de lenguaje. No supongas que las variables o los secretos del portátil se reenvían automáticamente.

Para proyectos de empaquetado de Python, la lista de comprobación de compilación y publicación con uv aborda otro límite: que una copia de trabajo funcione no demuestra que el paquete distribuido funcione.

Haz que las tareas remotas utilicen el directorio, el archivo guardado y el contexto previstos

Elige deliberadamente el ámbito de la tarea y la política de guardado

Coloca las tareas del proyecto en .zed/tasks.json. Las tareas globales están disponibles en todos los proyectos. La documentación de tareas de Zed define ambos ámbitos y establece como directorio de trabajo predeterminado la raíz del proyecto actual.

Esta definición propuesta de una tarea de proyecto solo muestra ese directorio en un equipo de tipo Unix:

[
  {
    "label": "inspect-task-directory",
    "command": "pwd",
    "save": "none"
  }
]

Escribir ese archivo cambia la configuración aunque pwd sea de solo lectura. El ejemplo no se ha instalado ni ejecutado. Su etiqueta es un identificador para la máquina y su orden indica el directorio de trabajo. Si añades un cwd explícito para un subproyecto, utiliza el directorio remoto previsto. Una ruta del portátil no lo identificará.

El valor de guardado predeterminado merece atención. Con none, el contenido editado en memoria puede diferir del archivo que lee una herramienta. Elige current para guardar el contenido del archivo activo o all para guardar el de todos los archivos modificados, como se documenta en la referencia de tareas. Comprueba qué archivos cambiaría esa elección antes de adoptarla.

Para una tarea posterior que trabaje con archivos, sigue la separación entre command y args que establece la documentación de tareas, incluido el tratamiento de variables en rutas con espacios. Este ejemplo de pwd no tiene ningún argumento de archivo. No te indica qué entrada leería una prueba.

Distingue el contexto de la reejecución de la reutilización del terminal

Seleccionar otro archivo no cambia necesariamente una reejecución. De forma predeterminada, Zed reutiliza el contexto resuelto, incluidas las variables de archivo capturadas anteriormente. El ejemplo de control de reejecución sitúa reevaluate_context en la acción task::Rerun de una asignación de teclas. No es un campo de la plantilla de tarea.

La reutilización del terminal controla otra cosa. Los valores predeterminados documentados reutilizan un terminal y esperan a que termine la tarea anterior. Una pestaña nueva no seleccionará otro servidor ni otro archivo. La concurrencia tampoco resolverá una discrepancia en la entrada.

Antes de ejecutar la orden real del proyecto, inspecciona la copia de trabajo y el directorio de trabajo; después, contrasta la entrada guardada con el contexto resuelto. Mostrar correctamente un directorio no verifica las pruebas de la aplicación.

Sigue la ruta de una aplicación web remota hasta su vista previa en un navegador local

Separa el puerto de escucha de la aplicación del reenvío SSH

Para una vista previa hipotética, supón que inicias por separado una aplicación de desarrollo en el puerto de bucle local 3000 del servidor remoto. La aplicación queda fuera de la configuración de esta guía. Aquí no se proporcionan ni se ejecutan sus instrucciones de instalación y arranque.

Este fragmento propuesto asigna el puerto local 8080 al puerto remoto mediante la configuración ssh_connections.port_forwards documentada por Zed. Intégralo en la conexión de tu servidor autorizado y conserva el resto de la lista de conexiones.

{
  "ssh_connections": [
    {
      "host": "devbox.example.com",
      "port_forwards": [
        { "local_port": 8080, "remote_port": 3000 }
      ]
    }
  ]
}

Sigue la ruta prevista de la solicitud hasta la aplicación que ya está en ejecución:

El reenvío no puede iniciar la aplicación. Si falla la vista previa, comprueba primero si la aplicación está escuchando. Después, investiga la ruta de reenvío, incluidos los conflictos de puertos locales y el destino remoto. Tener un túnel configurado no verifica que la aplicación esté lista.

Mantén la vista previa vinculada a localhost

Los valores predeterminados de reenvío de Zed vinculan ambos extremos a localhost. Consérvalos para esta vista previa. Establecer local_host en 0.0.0.0 vincula todas las interfaces locales. Configura la conexión y el reenvío previstos antes de visitar http://localhost:8080; el localhost del navegador sigue haciendo referencia a tu portátil.

La vinculación al bucle local no proporciona autenticación de la aplicación ni un despliegue público. Una vez que puedas acceder a la aplicación prevista, las pruebas de estados de accesibilidad con Playwright ofrecen una tarea independiente para comprobar la aplicación. Acceder a la vista previa no demuestra que se haya superado una prueba.

Usa la guía Servidor-Tarea-Vista previa para comprobar un proyecto de desarrollo

Servidor-Tarea-Vista previa es la lista de comprobación editorial propuesta en esta guía. Combina los límites documentados en una matriz de decisión; no es una función de Zed ni un estándar del sector, y no se ha probado como método de despliegue.

Servidor: identifica la copia de trabajo y el ámbito de configuración

Usa una copia de trabajo de desarrollo sin información sensible. Determina qué servidor y qué ámbito de configuración estás inspeccionando antes de diagnosticar la aplicación.

Tarea: inspecciona el entorno de ejecución y la entrada guardada

Lee las entradas de la orden con tanto cuidado como su etiqueta. Comprueba el comportamiento del servidor de lenguaje por separado de los resultados del terminal.

Vista previa: comprueba el puerto de escucha y la ruta del navegador

Sigue la solicitud hasta encontrar la primera discrepancia. Corrige esa capa antes de cambiar otro ajuste.

Mantén un pequeño registro durante la prueba. Estas observaciones fundamentan una decisión sobre la configuración; no miden una mejora del rendimiento.

Para un registro de planificación legible por máquina, los mismos límites pueden representarse de la siguiente manera. Su estado sigue siendo propuesto y no ejecutado.

{
  "framework": "host-task-preview",
  "checks": ["authorized-checkout", "saved-task-input", "running-app-and-local-forward"],
  "status": "proposed-unexecuted"
}

Antes de añadir repositorios o datos sensibles, asegúrate de poder explicar cada ruta y cada límite de acceso. Mantén las notas en privado y omite las credenciales y los volcados completos de variables de entorno. Este artículo no registra ninguna lista de comprobación completada.

Errores y límites habituales: SSH no es un entorno aislado ni una política de privacidad de IA

Corrige la suposición antes de cambiar el ajuste

Presta atención a estos errores de diagnóstico:

• Comprobar el entorno de ejecución del portátil cuando la tarea se ejecuta en remoto.
• Abrir un directorio personal completo en lugar del proyecto.
• Suponer que la reejecución sigue el archivo recién seleccionado.
• Esperar que los cambios sin guardar sean la entrada de la prueba.
• Reenviar un puerto antes de que la aplicación esté escuchando.

Cada uno remite a una fila concreta de la matriz de decisión. Úsala para aislar el problema.

Revisa por separado la confianza en el árbol de trabajo y el enrutamiento de IA

Zed mantiene registros de confianza en el árbol de trabajo por separado para cada servidor SSH. El modo restringido impide aplicar la configuración del proyecto e instalar o iniciar sus servidores de lenguaje y MCP no confiables; las herramientas consideradas confiables de forma global pueden seguir ejecutándose. Revisa la configuración y las instrucciones del proyecto, junto con las herramientas que puede invocar, antes de otorgarle confianza. Otorgar confianza de forma indiscriminada es una mala solución para una cuestión de permisos. La confianza en el árbol de trabajo no proporciona un aislamiento completo.

Para la IA, inspecciona la ruta de solicitud elegida y las condiciones del proveedor. Los agentes externos y las herramientas basadas en terminal pueden gestionar su propia autenticación, enrutamiento y permisos, como explica la guía de privacidad de Zed. El transporte SSH no te ofrece ninguna garantía universal sobre retención, entrenamiento o confidencialidad.

Si la ruta elegida incluye una pasarela, la guía de Vercel AI Gateway contiene una lista de comprobación independiente para el enrutamiento y la política del proveedor. Ese enlace no implica que tu sesión de Zed utilice la pasarela. La edición remota básica no necesita ninguna llamada de IA; la guía de inicio rápido de IA de Zed remite al control Desactivar IA del editor de configuración.

Identifica cuándo conviene mantener el proyecto en local

El desarrollo remoto debe compensar su coste de mantenimiento. Sopesa la administración y la preparación de la cadena de herramientas frente al trabajo que te permiten realizar. Comprueba también la compatibilidad de la plataforma, la fiabilidad de la conexión y el mantenimiento continuo. Si activas la IA, revisa el comportamiento del proveedor y su política de datos. El ahorro o una menor latencia requieren pruebas con tu propia carga de trabajo.

Mantén las prácticas habituales de guardado y control de versiones; reconectar no es una estrategia de copia de seguridad. Si nadie puede mantener el límite de acceso del servidor, conserva el proyecto en local. De lo contrario, empieza con la copia de trabajo más pequeña cuya ubicación resuelva un problema real de desarrollo. Amplía el alcance cuando entiendas sus rutas de ejecución y vista previa.