Desplegar en tu propio servidor significa dar a un agente acceso equivalente a SSH a una máquina que estás pagando y en la que puede que ya haya otras cosas alojadas. Eso es un nivel de confianza distinto al de publicar en un subdominio gratuito, y la configuración lo refleja: unos pocos campos, rellenados una vez, y después cada build siguiente es un botón. Esto es lo que la gente realmente pregunta antes y después de configurar uno.
¿Qué necesito para crear un destino?
Cinco cosas, en Configuración → Despliegue:
- Un nombre que reconocerás más tarde: "prod-vps", "cliente-hostgator", lo que sea que sobreviva en un menú desplegable a las 11 de la noche
- Host y puerto
- Credenciales SFTP
- Una ruta de webroot
Sin tokens de API, sin CLI que instalar en el servidor, sin tarea cron que vigilar. Si tu proveedor ofrece acceso SFTP —lo cual cubre casi todo hosting compartido, todo VPS, todo box de WordPress gestionado— terminas en unos dos minutos.
¿Contraseña o clave?
Clave, si tu proveedor la admite. Las contraseñas funcionan bien y las guardamos limitadas a tu cuenta, pero una clave es un secreto menos por ahí: la diferencia entre "revocar una clave" y "restablecer una contraseña en todos los sitios donde por casualidad se reutilizó" si algo sale mal más adelante. Muchas configuraciones SFTP de hosting compartido económico solo ofrecen autenticación por contraseña, y eso también está bien. Simplemente no reutilices esa contraseña en ningún otro sitio.
¿Cómo encuentro la ruta de webroot correcta?
Este es el campo en el que la gente se equivoca la primera vez, porque la respuesta incorrecta aun así parece plausible. No es tu directorio de inicio, no es /var/www — es exactamente la carpeta desde la que tu servidor web está configurado para servir contenido.
| Servidor | Webroot típico |
|---|---|
| Apache / cPanel | public_html |
| Nginx | /var/www/mysite/html — o alguna ruta que un desarrollador anterior nombró hace tres años por razones que nadie recuerda |
Si no estás seguro, coloca un archivo de prueba desechable test.txt en la carpeta que crees correcta usando cualquier cliente SFTP, y luego revisa si carga en yoursite.com/test.txt. Si te equivocas en esto, el despliegue igualmente reportará éxito — el agente escribe fielmente los archivos en la carpeta equivocada, y terminas viendo un sitio en vivo que no cambió, preguntándote por qué.
¿Puede un solo destino cubrir más de un dominio?
Sí, y esta es la parte que ahorra tiempo real una vez que pasas de tu primer sitio. Un destino es un servidor y un conjunto de credenciales; no está ligado a un solo dominio. En Gestión de dominios asocias cada dominio a un destino con su propia sobreescritura de webroot. ¿Tienes tres sitios en un VPS con bloques de servidor de Nginx?
site-a→/var/www/site-asite-b→/var/www/site-bsite-c→/var/www/site-c
Un destino, tres asociaciones. No estás volviendo a introducir una contraseña SSH tres veces, y no estás manteniendo tres destinos casi idénticos que se desincronizan el día que rotas una clave y te olvidas de uno de ellos. Haz clic en desplegar en cualquiera de los tres dominios y ya sabe qué servidor y qué carpeta usar: nunca eliges eso en el momento del despliegue.
¿Qué hace realmente el agente cuando se conecta?
Primero, echa un vistazo, solo lectura, nada se escribe todavía. Esa inspección comprueba si hay:
- Una carpeta vacía
- Una versión anterior de este mismo build
- Una instalación antigua de WordPress
- Un marcador de "próximamente" que tu proveedor puso ahí por defecto
Eso decide la estrategia. Un webroot vacío recibe una subida directa. Un webroot con algo ya dentro se maneja con más cuidado, porque muchas configuraciones reales tienen cosas conviviendo junto al sitio que no deberían desaparecer:
- A
.well-knowncarpeta para validación SSL - Un
uploadsdirectorio que nadie subió a git - A
wp-config.phpque nadie quiere que se toque
El trabajo aquí se acerca más a "averiguar qué cambió y conciliarlo" que a "borrar y reemplazar".
Después, antes de que se sobrescriba un solo byte, el webroot existente se captura como una versión en tu propio host. No un registro de base de datos, no un diff que calculamos y esperamos que sea correcto: una instantánea real de lo que había ahí. Esto importa más en el primer despliegue a cualquier destino, porque ese despliegue siempre aterriza encima de algo, aunque ese algo sea nada. Carpeta vacía, instantánea vacía. Un sitio estático de hace cinco años que nadie recuerda haber creado: preservado exactamente, gratis, antes de tocarlo. Ese primer despliegue es también el que menos seguridad tienes de cómo saldrá, así que es donde esto importa más.
¿Sube mi código fuente o el sitio compilado?
El sitio compilado, siempre. Para un sitio estático, eso son las páginas generadas. Para un build con framework — Next.js, Vite, lo que corresponda según el tipo de sitio — es la salida compilada, la carpeta dist o build , nunca el árbol de código fuente. Creo que esta es la decisión correcta aunque signifique que no puedas conectarte por SSH y ejecutar npm run dev sobre lo que hay en el servidor. Subir el código fuente implicaría que tu webroot de producción necesite un runtime de Node y un conjunto de herramientas de build solo para servir HTML — convirtiendo un servidor de hosting compartido que nunca fue pensado para ejecutar un pipeline de build en uno, y convirtiendo cada despliegue en "espero que el servidor tenga suficiente memoria para terminar npm install." Enviar solo la salida compilada mantiene el webroot exactamente como lo espera un servidor de archivos estático. Aburrido. Aburrido es lo que quieres a las 2am cuando algo falla y estás mirando esa carpeta tratando de entender qué se está sirviendo realmente.
¿Cómo sé que un despliegue realmente funcionó?
Después de la subida, el agente accede a la URL en vivo y verifica si resuelve correctamente — sin 500, sin página en blanco. Lo que encuentre, junto con cualquier cosa que haya notado durante la inspección sobre la que quiera tu opinión ("este webroot tiene una carpeta wp-content que dejé intacta, confirma que eso es lo esperado"), aparece en el hilo de chat del build. Ese es el patrón en toda esta plataforma: sin éxitos silenciosos, sin fallos silenciosos que terminen en un ticket de soporte. El agente te dice qué vio y qué decidió, en el mismo hilo donde pediste el build.
¿Qué hay realmente en el historial de versiones?
Cada despliegue agrega una versión, no solo el primero. Así que el historial no es tu conjunto de builds ubicados sobre una línea de tiempo abstracta; es la secuencia literal de lo que se sirvió desde ese webroot, en orden, comenzando desde lo que hubiera antes de que llegaras. La versión uno siempre es ese estado previo a la plataforma, capturado automáticamente. No tienes que pensar en ello.
¿Qué restaura realmente revertir?
La versión anterior en vivo, exactamente — no una nueva ejecución de un build antiguo, no una aproximación. Los archivos reales que estaban sirviendo el tráfico antes. Esa es una garantía considerablemente más sólida que la mayoría de las funciones de "rollback" que he usado en otros lugares, que normalmente significan "volver a desplegar desde un commit antiguo" y asumen tácitamente que tu proceso de build es determinista y que tu entorno no ha cambiado desde entonces. Aquí, revertir es una restauración de una instantánea conocida y funcional, por eso es seguro recurrir a ella bajo presión — no tienes que preguntarte si el rollback podría comportarse de forma distinta a aquello que está revirtiendo.
Y el momento en el que realmente lo necesitas nunca es tranquilo; es "el nuevo build rompió el checkout y hay tráfico en vivo ahora mismo".
Un clic, versión anterior restaurada, listo. El razonamiento detrás de tratar esto como una función de primera clase en lugar de un añadido tardío está en Iterar sin miedo — vale la pena leerlo una vez, antes de necesitarlo. Tanto el historial como el control de restauración están en la tarjeta del build y en la vista de historial propia del destino.
¿Esto también respalda mi base de datos?
No, y prefiero decirlo con claridad antes de que alguien asuma lo contrario. El historial de versiones en el host cubre lo que este pipeline de despliegue colocó en el webroot. Si tu sitio tiene una base de datos, o archivos subidos por usuarios, o cualquier otra cosa que cambie fuera de los despliegues, eso es un asunto completamente aparte — revertir no lo toca y no debería confundirse con una estrategia de respaldo que sí lo haga.
