Sube tu web a tu hosting: HTML, React compilado o PHP, con tu IA

Publica en tu hosting Linux la web que has hecho con IA (ChatGPT, Lovable, v0, Bolt) o crea una en PHP con base de datos: sin SSH o con tu IA por SSH.

Plan
Plan Linux (también aloja WordPress)
Tiempo
De 20 minutos si ya tienes la web hecha; de 2 a 4 horas si la programas en PHP
Nivel
Principiante si subes una web hecha; intermedio si programas en PHP con tu IA

Publicado: . Última revisión: . Autor: HostCarriel.

Tu IA
0 de 7 pasos hechos

En resumen

Con el plan Linux publicas tu web de dos maneras. Si ya la tienes hecha (con ChatGPT, Lovable, v0 o Bolt), la subes sin SSH con el gestor de archivos, SFTP o Git. Si quieres crearla con tu IA, la conectas por SSH y subes el resultado por rsync o Git. Sirve para HTML, React compilado, PHP con base de datos MySQL y WordPress. En ningún plan hay Node.js, Docker, procesos permanentes ni sudo.

Antes: conecta tu IA por SSH →

Lo que podrás hacer

  • Tu web hecha con IA (HTML, React compilado) publicada en tu dominio en unos minutos, sin SSH.
  • O un proyecto PHP con una estructura limpia, guardado en Git en tu ordenador.
  • Una base de datos MySQL creada desde el panel de hosting, con las claves fuera del código.
  • El proyecto subido por rsync (o desde Git) y funcionando en tu dominio.
  • Un plan para volver atrás con Git y con las copias del panel de hosting.

Qué plan necesitas

El plan Linux aloja WordPress, PHP, HTML y React compilado, con varias webs y subdominios en el mismo plan. Los planes WordPress están hechos para WordPress y, a cambio, traen staging, WP-CLI y caché. Para PHP, HTML, React o WordPress más PHP a medida, el plan Linux.

Si tu web está en un plan WordPress y necesitas PHP a medida, contrata el plan Linux. Si ya eres cliente, abre un ticket y te orientamos.

Qué quieres publicar¿Funciona?Dónde
HTML, CSS y JavaScriptSíPlan Linux
React compilado (Vite, Create React App)Sí, subiendo la carpeta compiladaPlan Linux
PHP con base de datos MySQL/MariaDBSíPlan Linux
Scripts en Perl, Ruby o PythonSí, como scripts; sin frameworksPlan Linux
WordPressSíPlan Linux (sin WP-CLI ni staging) o planes WordPress (con staging, WP-CLI y caché)
Node.js, Next.js o Remix con renderizado en servidorNo—
Docker, Django, Redis, ElasticsearchNo—
Cualquier comando con sudoNo: bloquea tu acceso SSH—

Si tu proyecto necesita algo de lo que no funciona, abre un ticket y te orientamos. No lo adivines.

Ya tengo mi web hecha (sin SSH)

¿La hiciste con ChatGPT, Lovable, v0, Bolt u otra herramienta? No necesitas SSH ni una IA conectada para publicarla: es subir archivos. Tienes tres caminos, del más sencillo al más técnico:

  1. Descarga tu proyecto desde la herramienta con la que lo hiciste.
  2. Si es solo HTML, CSS y JavaScript, ya está lista. Si es una aplicación React (Vite, Create React App), compílala en tu ordenador y quédate con la carpeta compilada (suele llamarse dist o build): en el hosting no hay Node.js, así que se sube el resultado, no el proyecto.
  3. Sube el contenido de esa carpeta a la carpeta de tu dominio (por defecto, public_html), con index.html en la raíz.
  4. Activa el SSL gratis desde el panel de hosting.
  5. Si la web es de una sola página, añade el .htaccess de la sección «Web estática o React compilado», más abajo.

Si no sabes cómo compilarla, pregúntaselo a la IA con la que la hiciste:

Prompt: Ya tengo mi web hecha (sin SSH)Cópialo y pégalo en tu IA
Prepara este proyecto para publicarlo en un hosting con Apache y PHP que no ejecuta Node.js. Dime los comandos exactos para generar la versión de producción como archivos estáticos (una carpeta `dist` o `build` con index.html en la raíz) y qué carpeta tengo que subir. No incluyas node_modules, .git ni archivos .env.

Si tu web necesita un servidor (formularios que guardan datos, inicio de sesión, base de datos), pasa a PHP con MySQL: sigue los pasos de esta guía.

WordPress en tu plan Linux

El plan Linux también aloja WordPress: lo instalas con el instalador de 1 clic del panel de hosting y tu IA trabaja por SSH, Git o SFTP. Esto es lo que cambia respecto a un plan WordPress:

  • Sin WP-CLI ni staging. Esas herramientas son de los planes WordPress. Tu IA escribe el tema hijo o el plugin en tu ordenador y lo subes por SFTP, rsync o Git; los ajustes de WordPress los haces tú desde el escritorio.
  • Volver atrás. Las copias automáticas del panel de hosting («Timeline Backups») y Git: guarda tu tema o plugin en Git y haz una copia de la base de datos (phpMyAdmin, en el panel de hosting) antes de cada cambio.
  • Confirma la carpeta. Si tienes varias webs o subdominios en el plan, cada web vive en su propia carpeta: pídele a tu IA que la confirme antes de tocar nada.
  • ¿Quieres WP-CLI y staging? Los planes WordPress los traen, junto con la caché; si tu web es solo WordPress, ahí tienes más herramientas.
Prompt: WordPress en tu plan LinuxCópialo y pégalo en tu IA
Mi web WordPress está en un plan Linux de HostCarriel: no hay WP-CLI ni staging. Trabaja solo por SSH, SFTP o Git.
1. Antes de tocar nada, pregúntame en qué carpeta del servidor está esta web (la raíz de su dominio) y confírmala listando su contenido en modo lectura.
2. Haz los cambios en mi ordenador (tema hijo o plugin) y súbelos con rsync, primero en simulación (-n).
3. No edites wp-config.php ni toques la base de datos: si hace falta, dame los pasos y los hago yo desde el panel de hosting.
4. Dime cómo deshacer cada cambio.

Antes de empezar

Esta parte es para programar con tu IA por SSH; si solo subes una web hecha, ya puedes seguir la sección anterior.

  • Un plan Linux activo con tu dominio apuntando a HostCarriel.
  • Tu IA conectada por SSH. Si aún no lo has hecho: conecta tu IA por SSH.
  • Un AGENTS.md con las reglas. Usa la plantilla de PHP de la guía de AGENTS.md.
  • Git en tu ordenador. PHP en tu ordenador es útil para probar, pero no obligatorio.

Abre la terminal en la carpeta de tu proyecto y arranca tu IA:

Con Claude Code

Abre tu IA en la carpeta de tu webComandos para Claude Code
cd ~/tu-dominio.com
claude

Con Codex CLI

Abre tu IA en la carpeta de tu webComandos para Codex CLI
cd ~/tu-dominio.com
codex
Antes de usar Codex CLI

Codex puede pedirte aprobación antes de ejecutar ssh, porque su sandbox trae la red cerrada; apruébalo o activa el acceso a red.

Con Antigravity

Abre tu IA en la carpeta de tu webComandos para Antigravity
# Antigravity 2.0 (app de escritorio): añade ~/tu-dominio.com como proyecto en la app.
# O con su CLI agy, que usa el mismo agente:
cd ~/tu-dominio.com
agy

Con Grok Build

Abre tu IA en la carpeta de tu webComandos para Grok Build
cd ~/tu-dominio.com
grok
Antes de usar Grok Build

Está en beta temprana: puede cambiar de una versión a otra. Lee cada comando antes de aprobarlo.

Con DeepSeek Harness

Abre tu IA en la carpeta de tu webComandos para DeepSeek Harness
cd ~/tu-dominio.com
npx @deepseek-ai/dsh web
# Se abre en tu navegador, en http://127.0.0.1:3080
Antes de usar DeepSeek Harness

Es una vista previa para desarrolladores. Su propia guía de seguridad (SAFETY.md) avisa de que no ha pasado una auditoría y recomienda usarlo dentro de una máquina virtual o un contenedor, con copias de seguridad.

Qué se ejecuta en este hosting y qué no

  • Se ejecutan: PHP (de la 5.3 a la 8.5 en la plataforma Linux, con la versión que elijas en el panel de hosting), Apache con .htaccess y mod_rewrite, MySQL/MariaDB, Git, rsync y tareas programadas.
  • No se ejecutan: Node.js, Docker, procesos permanentes (Redis, Elasticsearch, colas con workers, WebSockets) ni sudo.
  • Tu editor no puede conectarse en remoto: VS Code Remote, Cursor y Windsurf necesitan reenvío de puertos por SSH y el hosting no lo permite. Edita en tu ordenador y publica por rsync, SFTP o Git.
  • Si tu proyecto compila con Node.js (React, Vite, Tailwind), compílalo en tu ordenador y sube el resultado.

Web estática o React compilado

Si no necesitas PHP, el flujo es más corto: tu IA genera la carpeta de producción y tú la subes a la raíz de la web.

Prompt: Web estática o React compiladoCópialo y pégalo en tu IA
Prepara este proyecto para publicarlo en un hosting compartido con Apache y PHP. Ese hosting no ejecuta Node.js ni Docker.
1. Genera la versión de producción como archivos estáticos en una carpeta `dist`, con index.html en la raíz y rutas relativas.
2. Añade un .htaccess con las reglas que hagan falta (si es una aplicación de una sola página, que todas las rutas carguen index.html). No fuerces HTTPS en el .htaccess: lo activo yo desde el panel de hosting.
3. No incluyas node_modules, .git, archivos .env ni claves.
4. Si algo necesita un servidor (formularios, base de datos), avísame antes y propón una alternativa en PHP.
5. No uses sudo.
6. Termina diciéndome qué archivos subir y a qué carpeta.

Regla de .htaccess típica para una aplicación de una sola página:

.htaccess
<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule ^ index.html [L]
</IfModule>

La redirección a HTTPS se activa desde el panel de hosting («activar SSL gratis»), no desde .htaccess.

Pasos

  1. Pide un plan antes de escribir código

    Cambia lo que está entre corchetes por lo que quieres.

    Prompt: Pide un plan antes de escribir códigoCópialo y pégalo en tu IA
    Quiero crear [QUÉ: p. ej. una agenda de citas / un formulario de contacto con panel de administración / una calculadora] en PHP, para publicarlo en un hosting compartido Linux con Apache.
Condiciones del hosting: PHP [VERSIÓN DE PHP: la que elijas en el panel de hosting], MySQL/MariaDB, mod_rewrite y .htaccess. NO hay Node.js, Docker, procesos permanentes ni sudo, y no puedo instalar extensiones de PHP.
Todavía NO escribas código. Dime:
1. La estructura de carpetas (qué va en `public/` y qué queda fuera) y para qué sirve cada archivo.
2. Qué librerías necesitarías con Composer y por qué. Prefiere pocas, mantenidas y sin extensiones raras.
3. Las tablas de la base de datos, con sus columnas.
4. Cómo guardarías los datos de acceso a la base de datos (deben ir fuera del código y fuera de la carpeta pública).
5. Qué riesgos de seguridad ves en esta idea.
Espera a que te diga «adelante».

    Si quieres que además el programa no pueda editar archivos mientras planifica:

    Con Claude Code

    Claude CodeComandos de este paso
    # Al abrirlo
claude --permission-mode plan
# O, ya dentro: pulsa Shift+Tab hasta ver el modo plan

    Con Antigravity

    AntigravityComandos de este paso
    # Con la CLI agy, al abrirlo
agy --mode=plan
# O, ya dentro: Shift+Tab cicla entre los modos
# En la app Antigravity 2.0, el propio prompt ya le pide que espere tu «adelante».

    Con Codex CLI, Grok Build y DeepSeek Harness no damos un comando de modo plan: el prompt ya les pide que esperen tu «adelante».

    Por qué

    una estructura mal pensada es lo más caro de arreglar después. Pedir el plan primero te deja corregirla gratis.

    Revisa antes de aprobar
    • El plan deja fuera de public/ todo lo que no tenga que ser visible.
    • No propone Node.js, Docker, workers ni extensiones de PHP.
    • Usa pocas librerías y todas reconocibles.

  2. Crea el esqueleto y el repositorio

    Estructura recomendada en tu ordenador:

    Estructura de carpetas
    tu-dominio.com/
├── public/          ← lo único que se sirve (index.php, .htaccess, assets)
├── src/             ← código de la aplicación
├── config/
├── templates/
├── database/        ← schema.sql, migrate.php
├── .env.example     ← nombres de variables, sin valores reales
├── .gitignore
├── composer.json
└── AGENTS.md        ← reglas del agente (no se publica)

    En el servidor, subirás todo el proyecto a una carpeta propia (por ejemplo mi-app/) y harás que tu dominio sirva solo mi-app/public. Así, src/, config/ y .env nunca quedan al alcance de internet.

    Prompt: Crea el esqueleto y el repositorioCópialo y pégalo en tu IA
    Adelante con la estructura. En mi ordenador, en esta carpeta:
1. Crea el esqueleto: `public/index.php` (único punto de entrada), `src/`, `config/`, `templates/`, `database/`, `composer.json`.
2. Crea `.gitignore` con `.env`, `vendor/` y archivos del sistema, y `.env.example` con los nombres de las variables SIN valores reales.
3. Haz `git init` y un primer commit.
4. Haz un commit después de cada bloque de cambios, con un mensaje claro.
No pongas ningún dato de acceso en ningún archivo.

    Para probar en tu ordenador, si tienes PHP instalado: php -S localhost:8000 -t public.

    Por qué

    con Git puedes volver a cualquier versión si tu IA rompe algo. Y con .gitignore no subes por error tus contraseñas.

    Revisa antes de aprobar

    .env está en .gitignore y no existe ningún archivo con contraseñas reales.

  3. Base de datos MySQL

    Créala tú en el panel de hosting: «Web Tools» → «MySQL Databases». Cada base de datos puede ocupar hasta 1 GB, el nombre lleva entre 6 y 20 caracteres y el sistema le añade un sufijo. Desde ahí cambias la contraseña generada y entras a phpMyAdmin.

    Apunta en un lugar privado el nombre de la base de datos, el usuario, la contraseña y el servidor de base de datos. No se los des a tu IA.

    El servidor de base de datos (el valor de DB_HOST) no es localhost: usa el que te muestra el área «MySQL Databases» de tu plan en el panel de hosting.

    Prompt: Base de datos MySQLCópialo y pégalo en tu IA
    Escribe el esquema de la base de datos en `database/schema.sql` (MySQL/MariaDB, utf8mb4, InnoDB) y un script `database/migrate.php` que lo aplique usando las variables de entorno DB_HOST, DB_NAME, DB_USER y DB_PASS leídas del archivo .env.
Usa siempre PDO con consultas preparadas.
No me pidas la contraseña de la base de datos ni la escribas en ningún sitio: crearé yo el archivo .env en el servidor.
    Por qué

    una contraseña que se queda en un chat, en un commit o en un prompt puede acabar en logs. Las que no escribes no se filtran.

    Revisa antes de aprobar
    • schema.sql no contiene DROP DATABASE ni DROP TABLE sin que lo hayas pedido.
    • El script lee la configuración del .env, no de valores escritos en el código.
    • Todas las consultas usan PDO preparado.

  4. Escribe la aplicación por funciones

    Pide una funcionalidad cada vez y haz commit en cada una. Cambia lo que está entre corchetes.

    Prompt: Escribe la aplicación por funcionesCópialo y pégalo en tu IA
    Implementa [FUNCIONALIDAD 1]. Reglas:
- PHP en la versión de mi web ([VERSIÓN DE PHP]) y solo extensiones que vengan en una instalación normal.
- Consultas con PDO preparadas; nada de concatenar variables en SQL.
- Escapa toda salida HTML con htmlspecialchars; valida y limita cada entrada.
- Formularios con token CSRF; contraseñas solo con password_hash y password_verify.
- Subida de archivos: comprueba tipo y tamaño, renombra el archivo y guárdalo fuera de `public/` si no tiene que ser público.
- Errores: no los muestres al visitante (`display_errors` desactivado) y regístralos en un archivo fuera de `public/`.
- Sin eval, sin código ofuscado y sin llamadas a servicios externos que no te haya pedido.
- Al terminar: `php -l` en cada archivo creado o cambiado (si hay PHP en mi ordenador) y un commit.
    Por qué

    inyección SQL, XSS y CSRF son los fallos más comunes del código PHP generado sin supervisión. Lo mejor es que tu IA los evite desde el principio y que tú lo compruebes.

    Revisa antes de aprobar
    • Abre los archivos nuevos y busca $_GET, $_POST y query(: cada uno debe pasar por validación o por una consulta preparada.
    • No hay eval, exec, shell_exec ni base64_decode sin explicación.
    • Las rutas de subida no están dentro de public/ salvo que deban ser públicas.

  5. Prepara el servidor

    Haz esto tú en el panel de hosting y en el servidor, no tu IA:

    1. Versión de PHP. En «Web Tools» → «Change PHP Version», elige una versión actual (el plan Linux admite de la 5.3 a la 8.5). Para una carpeta concreta puedes fijarla en su .htaccess con una línea como AddHandler x-httpd-php83 .php.
    2. Crea la carpeta. Sube primero tu proyecto (paso 6) a mi-app/; la carpeta debe existir y contener archivos antes de seguir.
    3. Raíz de documentos. En «Manage Domains» → «Domains» (o «Subdomains» si pruebas en un subdominio), cambia «Document Root» a mi-app/public y pulsa «Update». Si la carpeta está vacía, la web da 403/404 o muestra un listado.
    4. Archivo .env. Créalo en mi-app/.env (fuera de public/) con el gestor de archivos del panel de hosting y escribe tus datos de la base de datos.
    5. HTTPS. Activa el SSL gratis desde el panel de hosting.
    6. Prueba antes de apuntar el dominio. La URL temporal de tu plan (la ves en el panel de hosting) sirve para ver el sitio antes de cambiar el DNS.

    Un .htaccess mínimo para un controlador frontal, dentro de public/:

    .htaccess
    <IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule ^ index.php [L]
</IfModule>

    mod_rewrite está activado por defecto en el plan Linux.

    Para Composer en el servidor, el PHP por defecto de SSH es una versión reducida: indica la ruta completa de la versión de PHP de tu web (/usr/bin/phpXY, donde XY es la versión sin el punto: 82 para PHP 8.2). Tu archivo de instrucciones la lleva ya escrita; el mensaje de bienvenida de SSH lista las versiones disponibles.

    ComandosLéelos antes de ejecutarlos o aprobarlos
    /usr/bin/phpXY -f /usr/bin/composer install   # XY = la versión de PHP de tu web

    Más sencillo: ejecuta Composer en tu ordenador y sube también vendor/.

    Por qué

    servir solo public/ es la medida de seguridad más simple de un proyecto PHP: nada fuera de esa carpeta es visitable.

    Revisa

    Que .env, src/ y config/ quedan fuera de la carpeta servida, y que borras cualquier info.php que hayas creado para comprobar la versión de PHP.

  6. Súbelo por rsync o Git

    Con rsync (macOS, Linux y Windows con WSL). Primero una simulación, que no cambia nada:

    ComandosLéelos antes de ejecutarlos o aprobarlos
    # 1) Simulación: muestra qué subiría, sin subir nada
rsync -avzn --exclude '.git/' --exclude '.env' --exclude 'node_modules/' ./ hc-tu-dominio.com:mi-app/
# 2) Si la lista es la esperada, repite sin la «n»
rsync -avz --exclude '.git/' --exclude '.env' --exclude 'node_modules/' ./ hc-tu-dominio.com:mi-app/

    Pide a tu IA que lo haga así:

    Prompt: Súbelo por rsync o GitCópialo y pégalo en tu IA
    Sube el proyecto al servidor con rsync a la carpeta `mi-app/`.
1. Primero ejecuta la simulación (`-n`) y enséñame la lista de archivos. No subas nada hasta que yo diga «adelante».
2. Excluye `.git/`, `.env` y `node_modules/`. Nunca uses `--delete` sin que yo lo pida.
3. Agrupa los comandos en una sola llamada SSH; no abras muchas conexiones seguidas.

    Con Git desde el panel de hosting: en «Web Files» → «Git Version Control», inicia sesión en GitHub o introduce tus datos, clona tu repositorio en la carpeta que elijas y despliega con «Deploy HEAD Commit». Para repositorios privados necesitas un par de claves.

    Con Git por SSH: el servidor admite Git; con tu IA conectada por SSH funciona igual que en cualquier máquina.

    Con SFTP: desbloquea FTP en el plan y conéctate con FileZilla por el puerto 22.

    Por qué

    una simulación te deja ver, antes de que ocurra, si vas a subir .git, node_modules o un archivo con claves.

    Revisa antes de aprobar
    • La lista de la simulación no incluye .env, .git/ ni node_modules/.
    • No aparece --delete.
    • El destino es mi-app/, no public_html/ entero.

  7. Comprueba que funciona

    Prompt: Comprueba que funcionaCópialo y pégalo en tu IA
    Comprueba lo que acabo de subir, sin cambiar nada:
1. Ejecuta `php -l` en cada archivo .php de `mi-app/`, con la ruta completa de la versión de PHP de mi web (la de mi archivo de instrucciones; el `php` por defecto de SSH es una versión reducida), y dime si alguno da error.
2. Comprueba que `.env` existe en el servidor, que NO está dentro de `public/` y que `.git/` no se ha subido. No muestres el contenido de .env.
3. Pide a la web su portada con curl (una sola vez) y dime el código HTTP.
4. Dime qué más debería revisar yo en el panel de hosting (versión de PHP, raíz de documentos, registros de errores).

    Si algo falla, mira en el panel de hosting «Logs & Stats» → «Access/Error Logs» y pega a tu IA las últimas líneas del registro.

    Revisa antes de aprobar

    Tu IA solo lee y comprueba. No edita nada ni toca .env.

    Antes de dar la web por terminada, pídele una auditoría de seguridad a tu IA, con las mismas reglas que en el paso 4, y léela tú.

Si algo sale mal

  1. Vuelve a la versión anterior con Git en tu ordenador (git revert o git checkout del último commit bueno) y sube de nuevo con rsync.
  2. Si cambiaste la raíz de documentos y la web da error, vuelve a poner public_html en «Document Root».
  3. Si un .htaccess da error 500, renómbralo (por ejemplo, .htaccess.off) desde el gestor de archivos del panel de hosting y revisa el registro de errores.
  4. Restaura una copia automática del panel de hosting: «Timeline Backups» → «Restore». Elige «Web» o «Database», fecha y hora.
  5. Si ejecutaste sudo y la conexión SSH se cierra, tu acceso está bloqueado. Abre un ticket para que lo desbloqueemos.

Si no consigues volver atrás, abre un ticket: te ayudamos con el hosting y las copias.

Problemas frecuentes

Error 500 tras subir.
Casi siempre es un .htaccess con una regla errónea o una versión de PHP incompatible con el código. Mira el registro de errores y la versión elegida en el panel de hosting.
403, 404 o listado de archivos tras cambiar la raíz de documentos.
La carpeta de destino no existe o está vacía.
«Allowed memory size exhausted».
Sube memory_limit en «PHP Configuration» (256M o 512M suele bastar).
El código PHP se ve como texto en la página.
El archivo no se está ejecutando como PHP. Revisa la extensión del archivo y la configuración de PHP del panel de hosting.
«Access denied for user» o no conecta con la base de datos.
El .env del servidor no tiene el servidor, nombre, usuario o contraseña correctos. Compáralos con «MySQL Databases» en el panel de hosting; DB_HOST no es localhost.
«MySQL server has gone away».
La conexión se quedó abierta demasiado o un resultado era demasiado grande. Revisa la consulta.
La subida de archivos falla en la aplicación.
Revisa el tamaño máximo de subida de PHP en el panel de hosting.
La conexión SSH se corta tras muchos comandos.
Pídele a tu IA que agrupe varios comandos en una sola llamada SSH. Más detalles en la guía de conexión.

Preguntas frecuentes

¿Puedo hacerlo en un plan WordPress?

Los planes WordPress están hechos para WordPress y, a cambio, traen staging, WP-CLI y caché. Para PHP, HTML, React o WordPress más PHP a medida, el plan Linux.

Ya tengo una web hecha con ChatGPT, Lovable, v0 o Bolt: ¿necesito SSH?

No. Con el gestor de archivos, SFTP o Git subes el resultado a tu dominio. Si es una aplicación React, compílala antes en tu ordenador y sube la carpeta compilada: en el hosting no hay Node.js. Tienes el camino corto en la sección «Ya tengo mi web hecha».

¿Puedo tener WordPress y otras webs en el mismo plan Linux?

Sí: el plan Linux aloja WordPress, PHP, HTML y React compilado, con varias webs y subdominios en el mismo plan. WordPress ahí no trae WP-CLI ni staging.

¿Puedo usar Laravel, Symfony u otro framework de PHP?

El hosting ejecuta PHP con Apache y .htaccess, así que un framework que funcione así debería correr. Tiene límites: sin procesos permanentes (colas con workers, WebSockets), sin Node.js para compilar los recursos (compílalos en tu ordenador) y sin sudo.

¿Puedo programar tareas automáticas?

Sí, desde «Scheduled Tasks» en el panel de hosting. Si el comando ejecuta un archivo PHP, indica la ruta de la versión de PHP que quieres.

¿Puedo usar React o Vue?

Sí, si compilas el proyecto en tu ordenador y subes el resultado estático. Lo que necesita un servidor Node.js (Next.js con renderizado en servidor, por ejemplo) no funciona.

¿Puedo editar con VS Code o Cursor conectados al hosting?

No en remoto: necesitan reenvío de puertos por SSH y el hosting no lo permite. Edita en tu ordenador y sube por rsync, SFTP o Git.

¿Me ayuda el soporte de HostCarriel si algo sale mal con mi IA?

Sí, con todo lo del hosting: la conexión por SSH, tus claves, las copias, la versión de PHP, la base de datos y el servidor. Si algo se rompe, te ayudamos a volver atrás con las copias de tu plan. Lo que escribe tu IA lo revisas tú, como con cualquier desarrollador; por eso las guías empiezan siempre con una copia y te piden aprobar cada paso.

Tu web a medida va en el plan Linux

Los planes WordPress están hechos para WordPress y, a cambio, traen staging, WP-CLI y caché. Para PHP, HTML, React o WordPress más PHP a medida, el plan Linux. Con el plan Linux subes tu web hecha con IA o programada en PHP, con base de datos MySQL, SSH, Git, SFTP y varias webs y subdominios en el mismo plan.

US$1/mes los 2 primeros meses (clientes nuevos); luego US$5.99/mes (Básico) o US$13.99/mes. Condiciones

Contratar plan LinuxAbrir Conecta tu IA
Registro de cambios
  • : Sin etiquetas de prueba en las herramientas; requisitos, avisos y condiciones, juntos al final de cada guía.
  • : Nombres unificados (Guías de IA, Potencia tu IA, Conecta tu IA, panel de hosting). WP-CLI y staging, solo en los planes WordPress. Nuevo: varias webs, WordPress en el plan Linux y Novamira.
  • : Primera versión.