Cómo pasar una web de localhost a Internet

Una web que abre en localhost solo está disponible en el ordenador donde la ejecutas. Para que otras personas puedan entrar, tienes que publicar cada parte del proyecto en un servicio accesible por Internet. No elijas el alojamiento por el editor o la IA que generó el código: elige según lo que debe ejecutarse.

Si vienes de HTML creado con IA, consulta la guía de publicación de HTML y CSS. Si usas React y Vite, sigue la guía de publicación desde Git. Si Codex creó el proyecto, compara ChatGPT Sites con la publicación desde un repositorio antes de elegir dónde alojarlo.

1. Identifica qué hay detrás de la pantalla

Abre la carpeta del proyecto y mira sus archivos, package.json, documentación y scripts. Anota si contiene:

• Archivos estáticos: HTML, CSS, imágenes y quizá JavaScript que el navegador descarga. Algunos proyectos React/Vite o Astro también producen archivos estáticos con un build.
• Un proceso de servidor: una API, páginas renderizadas en cada petición, autenticación propia, tareas en segundo plano o un servicio Node/Python.
• Servicios externos: una base de datos, almacenamiento de archivos, correo, login o APIs. Que la web se vea no significa que esas integraciones estén conectadas.

Un servidor de desarrollo como npm run dev solo sirve para trabajar en tu ordenador. No es la versión pública. Comprueba el comando de build y el directorio de salida del framework; Vite, por ejemplo, suele generar dist, pero la configuración puede cambiarlo (documentación de Vite).

2. Guarda y prepara el proyecto

Pon el código en un repositorio Git y conserva una copia antes de cambiar su configuración. No publiques .env, contraseñas, claves privadas ni datos reales. Busca referencias a localhost, rutas de tu disco y URLs de prueba; en la web pública, localhost apuntaría al dispositivo de cada visitante.

Si la carpeta todavía no está en Git, añade primero reglas para dependencias y secretos a .gitignore, por ejemplo:

node_modules/
.env
.env.*
!.env.example

Desde la carpeta del proyecto, inicializa y revisa el repositorio antes del primer commit:

git init -b main
git add .
git status --short
git commit -m "Primera versión"

Si git status muestra una clave, un .env o datos privados, no hagas el commit: sácalos de lo preparado y corrige .gitignore. Esta regla no deja de seguir archivos que Git ya tenía registrados. Después crea un repositorio vacío —privado si el código es de un cliente— y conecta su URL:

git remote add origin https://github.com/USUARIO/REPOSITORIO.git
git push -u origin main

Si ya existe una carpeta .git, no inicialices otro repositorio dentro: revisa la rama y el remoto con git branch --show-current y git remote -v. La documentación de GitHub para subir código local cubre variantes del flujo. Luego conecta ese repositorio a Hostbrid Projects; el manual de Projects explica los permisos y la selección del repositorio.

Si el proyecto es un monorepo, anota qué carpeta contiene la aplicación y qué archivos necesita durante la instalación y el build. No borres una API, una carpeta de servidor o una integración solo para que la página principal parezca funcionar.

3. Elige dónde ejecutar cada componente

Para HTML, CSS y otros archivos estáticos, necesitas un alojamiento que sirva esos archivos y permita abrir sus rutas públicas. Hostbrid Sites cubre sitios web gestionados como WordPress; comprueba su catálogo y límites para el proyecto concreto.

Para un repositorio que necesite build y despliegue desde Git, mira Hostbrid Projects. Projects también ejecuta servicios Docker dentro de la cuota del plan: Dev publica proyectos estáticos, mientras que los servicios permanentes requieren un plan de pago. Comprueba en Projects y sus precios el número de servicios y los recursos disponibles antes de contratar. Un build estático no ejecuta por sí solo una API Node que tu aplicación necesite.

Evalúa un VPS si necesitas acceso root, control del sistema operativo, configuración de red o procesos que no encajen en los límites del plan Projects. En un VPS tú administras sistema, actualizaciones, seguridad, copias y despliegues. Compara las condiciones y precios actuales con las necesidades reales, no solo con el tamaño de la carpeta.

4. Configura build, variables y datos

Introduce la orden de instalación, la orden de compilación y la carpeta de salida que correspondan a tu framework. Las variables usadas en el frontend pueden acabar dentro de los archivos que recibe el navegador; nunca pongas ahí secretos. Las claves privadas deben permanecer en el servidor y configurarse como variables protegidas del entorno.

Si usas una base de datos local, migrarla significa trasladar el esquema y los datos con un procedimiento adecuado, y cambiar la conexión de producción. Publicar el código no copia automáticamente SQLite ni otra base de tu portátil. Revisa cómo preparar una migración de PostgreSQL antes de conectar datos reales.

Un formulario también necesita un destino que acepte y procese los envíos. Revisa cómo comprobar el backend y la entrega del formulario; el mensaje «enviado» en pantalla no demuestra que el correo haya llegado.

5. Prueba la versión pública antes de anunciarla

Abre la URL HTTPS desde otro dispositivo y prueba tanto la portada como una ruta interna pegada directamente en la barra. Comprueba imágenes, estilos, consola, enlaces, login, formularios y llamadas a API que realmente tenga el proyecto. Si cambias una variable de build, vuelve a construir: editarla después no modifica los archivos ya publicados.

Conecta el dominio cuando la versión temporal funcione. Configura los registros DNS indicados por el proveedor, espera a que se propaguen y comprueba el certificado HTTPS. Mantén el sitio anterior hasta verificar el nuevo y conserva una forma de volver a la versión previa.

Qué contratar según el proyecto

HTML o un frontend compilado sin servidor propio: revisa destinos compatibles con esos archivos y rutas. Aplicación con build desde Git o servicio Docker dentro de la cuota: revisa Projects y sus límites. Acceso root, control del sistema o necesidades fuera de esos límites: evalúa VPS. Para WordPress y otros servicios PHP gestionados, consulta Sites. Si no sabes dónde termina el frontend y empieza el backend, cuéntanos el framework y los servicios que usa, sin adjuntar secretos.

Publicar hace que la web sea accesible; no garantiza que Google la indexe, que aparezca en una posición concreta o que una IA la recomiende. Primero confirma que el sitio funciona y que el contenido público responde a las preguntas de tus visitantes.