Despliegue en Vercel o Netlify desde un IDE de navegador

El caso evidente es una máquina donde instalar una CLI resulta incómodo o está prohibido. Un Chromebook, un equipo de laboratorio o un escritorio corporativo bloqueado pueden abrir una pestaña, pero no siempre permiten instalar Node.js, Git y la CLI del proveedor. Un IDE de navegador ya elimina esos requisitos para editar. El despliegue suele ser el último paso que devuelve al desarrollador a una terminal; mantenerlo en la misma pestaña cierra el circuito: el proyecto se edita, se previsualiza y se publica sin toolchain local. El segundo caso es la velocidad. Una landing page, un prototipo o una demo para un cliente pueden necesitar una URL antes de necesitar un repositorio o un pipeline de CI. El panel del navegador publica la instantánea actual y dice dónde está viva. Esa comodidad tiene un límite. Esto es una carga directa, no un pipeline de despliegue. No vigila una rama, no ejecuta pruebas ni promueve compilaciones entre entornos; eso corresponde a la integración Git del proveedor o a CI. El camino del navegador sirve para la primera URL, no para todo el proceso de release.

El diálogo Deploy es una superficie de control fina sobre dos API de proveedor. Al pulsar Deploy now, GB Coder construye el mismo paquete de archivos que genera Download ZIP. Ese detalle importa: no hay una segunda ruta de empaquetado que pueda omitir una hoja de estilos o una biblioteca externa. Un proyecto simple se convierte en index.html, style.css, script.js y un README. Un proyecto React o Vue se convierte en un árbol con forma de Vite: index.html, package.json, vite.config.js, .gitignore, un README y archivos fuente bajo src/. El resumen del paquete muestra el número exacto de archivos y el tamaño sin comprimir antes de que algo salga de la pestaña. Vercel recibe los archivos como JSON en línea en su endpoint de despliegue. Netlify recibe un ZIP como cuerpo bruto de la petición. Vercel compila o sirve el proyecto; Netlify publica los archivos subidos como despliegue manual. Ningún servidor de LadeStack se interpone y no se ejecuta ninguna CLI en tu máquina. El navegador es el cliente, el proveedor es el host y el token es la única credencial. Un clic describe la interfaz, no el trabajo: empaquetado, carga, procesamiento remoto y TLS siguen ocurriendo en secuencia.

El paquete es distinto porque los dos tipos de proyecto necesitan trato distinto. Un proyecto HTML/CSS/JavaScript simple no tiene package.json. A Vercel se le indica que no use framework y sirve los archivos como sitio estático. Netlify publica el ZIP tal cual, lo que también es correcto para archivos estáticos. No hay nada que instalar ni compilar, así que el primer despliegue suele ser rápido. Un proyecto React o Vue incluye un package.json generado, una configuración de Vite y archivos fuente. En Vercel, el proveedor detecta Vite, instala dependencias, ejecuta la compilación de producción y publica la salida. Es una compilación real en la nube, no una simulación en el navegador, y por eso puede tardar un minuto o más. Vercel también usa las versiones registradas en package.json, no lo que estuviera cargado en el editor. El despliegue manual por ZIP de Netlify no ejecuta una orden de compilación, así que el mismo árbol de fuentes Vite se publica tal como se subió, sin compilar. Para React o Vue en Netlify, usa la integración Git del proveedor; la ruta de un clic de Netlify solo publica salida estática. Las bibliotecas externas y los ajustes de inyección ya están en el paquete. Si una compilación de Vercel depende de un paquete privado, un binario nativo o un servicio inalcanzable desde su imagen de compilación, la compilación fallará aunque la vista previa funcione. Los logs indican en cuál de esos casos estás.

Ambos proveedores se autentican con un token de acceso personal. No es la contraseña del proveedor ni una cuenta de GB Coder. El diálogo enlaza a la página de tokens del proveedor seleccionado y explica el alcance con claridad. Un token de Vercel puede publicar en todos los proyectos a los que llega la cuenta o el equipo; cuando existan tokens con alcance de equipo, úsalos. Un token de Netlify actúa sobre los sitios a los que accede la cuenta, así que trátalo como global salvo que haya una opción más estrecha. Crea el token para este propósito, dale la vida útil más corta posible y revócalo cuando el proyecto ya no lo necesite. GB Coder comprueba que hay un token y que el paquete cabe en los límites locales antes de habilitar Deploy now. El token se mantiene en memoria para la pestaña por defecto. Recordar en este dispositivo es un opt-in: en un origen seguro, el token se sella con AES-GCM antes de escribirse en localStorage; si no, el diálogo advierte de que recordarlo lo guardaría en texto plano. El alcance y la revocación son los controles que más importan.

Abre un proyecto y elige Deploy en la barra de herramientas; en pantallas estrechas está en el menú de desbordamiento. Vercel aparece seleccionado por defecto; Netlify está a un clic. El nombre del proyecto se rellena con el proyecto actual. GB Coder lo pasa a minúsculas, sustituye caracteres inválidos por guiones y muestra el hostname que solicitará, por ejemplo tu-proyecto.vercel.app. Pega el token, decide si quieres recordarlo y revisa el resumen del paquete. Si el número de archivos o el tamaño supera el límite, el diálogo explica el problema y mantiene el botón desactivado. Pulsa Deploy now. El proveedor crea el proyecto o sitio, recibe el paquete y empieza a procesar el despliegue. Cuando el despliegue está listo, la pantalla de éxito muestra la URL pública, el número de archivos, el tamaño subido, el tiempo transcurrido y un código QR para abrir la página en el móvil. Copy URL y Visit site sirven para el traspaso, y Build logs abre los logs del proveedor. Los nombres de sitio de Netlify son globales, así que uno solicitado puede estar ocupado. Entonces el proveedor asigna otro y GB Coder informa la dirección que está viva de verdad, no la que escribiste.

La barra de progreso pasa por empaquetado, carga, compilación, asegurado y listo. En Netlify, la etiqueta de compilación cubre el procesamiento del proveedor, no una orden de compilación. Es un informe del cliente, no una predicción del proveedor. El porcentaje avanza por las dos primeras fases y se queda por debajo de 100 mientras el proveedor termina el trabajo remoto. Es deliberado: el trabajo remoto puede tardar un tiempo imprevisible y una barra que llegara al 99 % estaría mintiendo. GB Coder consulta al proveedor cada segundo y medio y actualiza el mensaje cuando cambia el estado. Una petición de carga tiene un tiempo de espera de dos minutos. El panel deja de esperar tras tres minutos de sondeo del despliegue y te remite al panel del proveedor, porque el despliegue puede terminar aunque el navegador haya dejado de mirar. Cancelar, cerrar el diálogo o pulsar Escape aborta la petición en curso y el bucle de sondeo. Si el proveedor ya aceptó el despliegue, el despliegue puede continuar de su lado; revisa el panel antes de suponer que cancelar equivale a revertir. Los logs del proveedor son la fuente autoritativa cuando falla un despliegue.

Deploy again vuelve al formulario; no reenvía el último paquete de inmediato. Es útil cuando el proyecto cambió, el nombre necesita ajustes o el token caducó. Vercel y Netlify toman rutas distintas hacia la misma dirección. Vercel crea un despliegue contra el proyecto nombrado y apunta a producción. Los despliegues repetidos con el mismo nombre actualizan ese proyecto, y el alias de producción se prefiere sobre la URL específica del despliegue, así que la dirección que compartes suele mantenerse estable. Netlify necesita un id de sitio para actualizar uno existente en vez de crear otro. GB Coder recuerda el id en localStorage, asociado al nombre saneado. Si borras el almacenamiento del navegador, cambias de navegador, cambias el nombre o eliminas el sitio en Netlify, el siguiente despliegue no encuentra el anterior y crea uno nuevo. Por eso renombrar un proyecto de Netlify puede dejar el sitio viejo en la cuenta. Ambos proveedores guardan historial de despliegues, dominios personalizados, controles de acceso y rollback en sus paneles; el panel de GB Coder expone la carga y la URL pública, no esos controles. Cada despliegue desde aquí es de producción; no hay selector de previews por rama ni de entorno.

Hay dos límites que se aplican antes de que la petición salga de la pestaña: 900 archivos y 64 MB de contenido sin comprimir. Están por debajo de los techos de los proveedores para que una carga enorme no falle a mitad de una sesión de navegador. Un sitio con muchos medios debería mantener imágenes y vídeo grandes en un CDN o en Git, no dentro del paquete del proyecto. Los errores se separan por causa. Un 401 significa que el token fue rechazado; un 403 suele indicar falta de permiso para la cuenta o el equipo; un 413 o 429 significa que el payload es demasiado grande o que el proveedor limita la tasa; un 422 indica que el proyecto se rechazó como inválido; un 5xx suele ser temporal. En Vercel, un fallo de compilación es distinto: la carga funcionó y falló el build, así que lee los logs en vez de pegar otro token. Una compilación de Vercel que necesita variables de entorno es otra frontera. El diálogo no tiene editor para ellas. Configúralas en los ajustes del proyecto de Vercel y vuelve a desplegar; la primera compilación puede fallar antes de que exista el proyecto. La ruta ZIP manual de Netlify no tiene paso de compilación, así que esto no se aplica allí. Un límite de sondeo de tres minutos no es un despliegue fallido, solo una espera fallida.

El despliegue es directo: el navegador llama a api.vercel.com o api.netlify.com con tu token. No hay un proxy que guarde la credencial y no hace falta una cuenta de LadeStack para usar el panel. Los tokens viven solo en la sesión por defecto y se sellan con AES-GCM únicamente si eliges recordarlos en un origen seguro. Eso protege frente a un token legible en una copia del perfil o en un paquete de soporte, pero no frente a código malicioso en el mismo origen mientras la pestaña está abierta. Usa el token más estrecho disponible, ponle caducidad y revócalo en el proveedor al terminar. La propiedad sigue al token: el proyecto o sitio se crea en la cuenta del proveedor que lo posee, bajo sus términos, cuotas, logs y facturación. GB Coder sigue siendo local-first, pero desplegar es una exportación explícita del proyecto al proveedor. El proveedor recibe el código del sitio y el resultado es una URL HTTPS pública por defecto; la protección con contraseña, el SSO y los dominios personalizados son funciones del proveedor. Guarda un ZIP o una copia en GitHub si el perfil del navegador es el único otro lugar donde existe el proyecto.

Usa este camino para poner un sitio pequeño en línea rápido: una landing page, un portafolio, una demo de clase, un prototipo para revisión de cliente o una página de documentación estática. También encaja cuando el proyecto ya vive en GB Coder y la alternativa es exportar un ZIP, abrir una terminal y configurar una CLI en una máquina que no es tuya. No encaja para un monorepo, una aplicación renderizada en servidor con base de datos, una compilación que necesita credenciales de un registro privado, un equipo que publica con previews por rama y aprobaciones, o activos que superan los límites de carga. Esos son trabajos de la integración Git del proveedor, un pipeline de CI o un entorno de escritorio. Los dos enfoques pueden convivir: borra e itera en el navegador, sube el código a GitHub cuando merezca historial y deja que CI publique la compilación de producción. Una rutina práctica: prueba la vista previa a ancho de móvil, revisa el resumen del paquete, despliega, abre la URL en un segundo dispositivo y guarda el log. Para probarlo, abre el Panel de Proyectos en /app/projects, crea o abre un proyecto y elige Deploy. La referencia de configuración está en la documentación.