Puedes contratar hosting para WordPress con infraestructura en la nube de tres formas: un hosting WordPress gestionado, un hosting empresarial gestionado con recursos aislados o un servidor cloud con acceso root que administras tú. En Dongee esas tres gamas —WordPress PRO desde 6,66 USD/mes, Hosting Empresas desde 25 USD/mes y Dongee Cloud desde 17 USD/mes— son infraestructura en la nube; lo que cambia es quién administra el servidor y cuánto control tienes. Si no quieres administrar un servidor, elige una opción gestionada. Si tienes un equipo técnico que quiere control total, elige el servidor cloud.

Qué significa «WordPress en la nube» cuando lo compras

«WordPress en la nube» es más una etiqueta de marketing que una categoría técnica. Con ese nombre se venden productos que no se parecen mucho entre sí, y si no sabes cuál estás comprando, puedes pagar por algo que no necesitas o quedarte sin algo que sí necesitas. En general, se venden tres cosas:

• Hosting WordPress gestionado sobre infraestructura redundante. El proveedor administra el servidor y ajusta el entorno para WordPress. Tú solo te ocupas de tu sitio.
• Hosting gestionado con recursos aislados en contenedores. Tu cuenta tiene CPU, RAM y velocidad de disco (IO) definidas, separadas de las de otros clientes. El proveedor sigue administrando el entorno.
• Servidor cloud o VPS. Recibes una máquina virtual con acceso root. Tú instalas y mantienes todo lo demás: el servidor web, PHP, la base de datos, la caché, la seguridad y WordPress.

En Dongee, WordPress PRO, Hosting Empresas y Dongee Cloud son precisamente esas tres formas, todas sobre infraestructura en la nube.

Para saber qué te están ofreciendo de verdad, haz estas preguntas antes de pagar:

• ¿Quién actualiza el sistema operativo y PHP: ustedes o yo?
• ¿Los recursos de mi plan están garantizados o se comparten con otras cuentas?
• Si WordPress deja de funcionar a medianoche, ¿su soporte lo revisa o solo atiende fallas del servidor?
• ¿Las copias de seguridad son automáticas? ¿Quién las restaura y cómo?
• ¿Qué pasa con mi correo electrónico? ¿Está incluido o lo tengo que resolver aparte?

Si quieres entender la diferencia técnica entre compartir un servidor y tener una infraestructura con alta disponibilidad, revisa nuestra guía sobre la diferencia técnica entre hosting compartido y nube empresarial.

Tres formas de contratarlo

1. Hosting WordPress gestionado

Para quién es: dueños de pymes, profesionales independientes, blogs, sitios corporativos y tiendas WooCommerce pequeñas o medianas que no tienen a alguien dedicado a administrar servidores. También sirve a agencias que manejan varios sitios de clientes y prefieren no mantener la infraestructura.

Qué hace el proveedor: mantiene el servidor, configura PHP y la base de datos para WordPress, ofrece caché, aplica capas de seguridad, programa copias automáticas y da soporte que entiende WordPress.

Qué haces tú: actualizas WordPress, el tema y los plugins, cuidas el contenido y decides qué instalar.

• Pros: no necesitas saber de servidores, el entorno ya viene preparado para WordPress, suele incluir staging y migración, y el costo es predecible.
• Contras: no puedes cambiar el stack del servidor a tu gusto, y hay límites por plan (sitios, almacenamiento, visitas) que conviene revisar.

2. Hosting empresarial gestionado con recursos aislados

Para quién es: sitios y tiendas críticos para el negocio, donde una caída cuesta ventas o reputación, y donde prefieres que un equipo externo administre la infraestructura.

Qué hace el proveedor: asigna recursos definidos (CPU, RAM, IO), administra el entorno, monitorea, hace copias, protege con firewalls y antivirus, y te ayuda a migrar y a restaurar.

Qué haces tú: lo mismo que en el gestionado: mantener WordPress, plugins y contenido.

• Pros: rendimiento más predecible porque otros clientes no consumen tus recursos, más acompañamiento y monitoreo constante.
• Contras: cuesta más que un hosting WordPress de entrada, y sigues sin control total del sistema operativo.

3. Servidor cloud administrado por ti (o por tu agencia)

Para quién es: desarrolladores, agencias con equipo técnico y empresas que necesitan un stack propio, varias aplicaciones en el mismo servidor o una arquitectura con varias instancias.

Qué hace el proveedor: entrega la máquina virtual, la red, el almacenamiento y las herramientas de la infraestructura (por ejemplo, snapshots o backups de disco), y mantiene funcionando el hardware.

Qué haces tú: todo lo que va dentro del servidor. Eliges el sistema operativo, instalas el servidor web (Nginx, Apache o LiteSpeed, por ejemplo), PHP-FPM, MySQL o MariaDB, una caché de objetos como Redis, herramientas como WP-CLI, el firewall, los certificados SSL y WordPress. También aplicas parches y resuelves los incidentes.

• Pros: control total, libertad de configuración y crecimiento flexible.
• Contras: exige conocimientos de administración de sistemas, tiempo y guardias. Si algo falla en WordPress o en el stack, lo resuelves tú.

Si no tienes claro qué es una máquina virtual o un VPS, empieza por qué es un VPS.

Quién hace qué: gestionado frente a servidor propio

Esta es la diferencia que más pesa en el día a día y la que más se pasa por alto al comprar:

• Sistema operativo y parches: en el gestionado, el proveedor. En el servidor propio, tú.
• PHP y base de datos: en el gestionado, el proveedor los instala y mantiene, y tú normalmente eliges la versión de PHP desde el panel. En el servidor propio, tú los instalas, configuras y actualizas.
• Caché: en el gestionado, suele venir integrada y tú la activas. En el servidor propio, tú configuras la caché de página y la de objetos.
• Firewall y antivirus: en el gestionado, los incluye el proveedor. En el servidor propio, tú los instalas y vigilas.
• Copias y restauración: en el gestionado, son automáticas y el proveedor te ayuda a restaurar. En el servidor propio, la infraestructura puede ofrecer snapshots o backup de disco, pero la estrategia de copias de WordPress y las pruebas de restauración te tocan a ti.
• SSL: en el gestionado, el certificado suele estar incluido y se renueva solo. En el servidor propio, tú lo configuras y automatizas.
• Migración: en el gestionado, muchas veces la hace el proveedor. En el servidor propio, a menudo la haces tú o tu agencia, aunque algunos proveedores ofrecen migración asistida.
• Monitoreo: en el gestionado, el proveedor vigila el servidor. En el servidor propio, tú configuras alertas.
• Soporte cuando WordPress falla: en el gestionado especializado, el soporte te ayuda a diagnosticar. En el servidor propio, el proveedor atiende la infraestructura y tú, la aplicación.

Si vienes de un hosting compartido y te preguntas si ya es momento de cambiar, consulta cuándo pasar de hosting compartido a un servidor en la nube administrado.

Cómo dimensionar sin adivinar

No hay una cifra mágica de recursos para WordPress. Lo que tu sitio necesita depende de cómo está construido y de cómo lo usan tus visitantes. En lugar de adivinar, sigue estos pasos:

1. Revisa tu analítica. Mira las visitas mensuales, los picos (campañas, temporadas, lanzamientos) y las páginas más visitadas. Lo que más pesa son los picos, no el promedio.
2. Cuenta tus sitios. Anota cuántas instalaciones de WordPress vas a alojar ahora y en el próximo año. Las agencias deberían incluir los sitios de prueba.
3. Identifica las partes dinámicas. WooCommerce, membresías, áreas de clientes, buscadores internos y formularios generan páginas que no se pueden guardar en caché tan fácilmente y consumen más CPU y base de datos.
4. Mira tus plugins pesados. Constructores visuales, plugins de estadísticas internas, traductores, sincronizaciones con ERP o CRM y tareas programadas pueden consumir más que el tráfico mismo.
5. Mide el tamaño real. Suma lo que ocupan los archivos, la base de datos y las copias que quieres guardar. Si el correo va en el mismo hosting, súmalo también.
6. Prueba en staging. Si el plan tiene entorno de pruebas, monta tu sitio y revisa cómo responde antes de cambiar el DNS.
7. Empieza ajustado y escala después. Es mejor elegir un plan que cubra lo que necesitas hoy, con la posibilidad de subir de plan sin cambiar de proveedor, que pagar por recursos que nunca usarás.

Antes de pensar en más recursos, asegúrate de tener la caché bien configurada. Esta guía te ayuda: cómo activar la caché en WordPress paso a paso.

Lista de verificación antes de pagar

1. Discos: ¿qué tipo de almacenamiento usa el plan (por ejemplo, NVMe)?
2. Recursos: ¿la CPU y la RAM del plan están garantizadas para mi cuenta o se comparten? ¿Hay sobreventa?
3. Caché: ¿qué caché incluye? ¿Hay caché de objetos (Redis) en mi plan o solo en los superiores?
4. Staging: ¿puedo crear una copia de pruebas y publicarla con un clic?
5. Copias: ¿cada cuánto se hacen las copias automáticas? ¿Puedo restaurar yo mismo o me ayudan? ¿Cuánto tarda?
6. Migración: ¿quién migra mi sitio y mis correos? ¿Tiene costo? ¿Hay una ventana de pruebas antes de cambiar el DNS?
7. Seguridad: ¿qué incluye: WAF, antivirus, firewall, aislamiento entre cuentas? ¿Qué me toca a mí?
8. Soporte: ¿el soporte sabe de WordPress, atiende las 24 horas y lo hace en español?
9. Escalado: si mi sitio crece, ¿puedo subir de plan o pasar a otro producto sin cambiar de proveedor?
10. Precio: ¿el precio mensual cambia según el periodo de pago? ¿Cuánto cuesta la renovación?
11. Garantía: ¿hay garantía de devolución? ¿Cuántos días y con qué condiciones?
12. Ubicación: si te importa la cercanía con tu público o algún requisito interno, ¿dónde están los servidores?

Si quieres profundizar en los criterios de velocidad y seguridad, revisa nuestra comparativa de hosting WordPress rápido y seguro.

Tabla comparativa

Errores frecuentes al comprar

• Comprar un servidor sin saber administrarlo. Un servidor cloud no es «un hosting más rápido». Si nadie aplica los parches ni configura la seguridad, el riesgo crece cada semana.
• Elegir por el precio del primer periodo. Revisa cuánto pagarás al renovar y si el precio mensual cambia según cuántos meses pagues. En WordPress PRO y Hosting Empresas de Dongee, al renovar se paga el mismo precio.
• No probar una restauración. Una copia que nunca restauraste es solo una suposición. Haz una prueba al menos una vez.
• Olvidarte del correo. Si tu correo corporativo está en el hosting actual, inclúyelo en la migración o te quedarás sin recibir mensajes.
• Cambiar el DNS sin probar. Revisa el sitio en una URL temporal o en staging antes de apuntar el dominio.
• Comprar de más. Pagar recursos «por si acaso» rara vez compensa si puedes escalar después.
• Ignorar los plugins. Muchas lentitudes vienen de plugins mal configurados, no del servidor. Cambiar de hosting no las arregla solo.
• No preguntar por la seguridad de la aplicación. El proveedor protege el servidor, pero las contraseñas débiles y los plugins abandonados son responsabilidad tuya. Revisa nuestra guía de seguridad en WordPress.

Cómo se ve en Dongee

En Dongee, WordPress PRO, Hosting Empresas y Dongee Cloud son las tres gamas de infraestructura en la nube para alojar WordPress.

Hosting WordPress PRO

Es alojamiento optimizado solo para WordPress. Planes por mes:

• Personal, 6,66 USD: 1 sitio, 20 GB NVMe, 1 CPU y 1 GB de RAM, hasta 200.000 visitas al mes.
• Standard, 9 USD: 5 sitios, 30 GB, 2 CPU y 2 GB, 200.000 visitas.
• Premium, 14 USD: 10 sitios, 50 GB, 3 CPU y 4 GB, 500.000 visitas.
• Ultimate, 21 USD: 50 sitios, 70 GB, 4 CPU y 6 GB, 1.000.000 de visitas, AccelerateWP Premium y caché de objetos Redis.

Todos los planes incluyen AccelerateWP, el constructor Divi, staging, backups automáticos con restauración en 1 clic, WP-CLI, Git y SSH, certificados SSL y seguridad en 6 capas: WAF, RASP, doble antivirus, aislamiento de cuentas, ModSecurity comercial y firewall. El equipo de Dongee hace la migración asistida sin costo (web, base de datos y correos), con una ventana de pruebas antes de apuntar el DNS. También incluyen soporte especializado en WordPress 24/7 en español y garantía de 30 días. Puedes pagar por 3, 6, 12, 24 o 36 meses con el mismo precio mensual —también al renovar—, el plan anual incluye 1 dominio por 1 año y puedes subir de plan cuando lo necesites.

Hosting Empresas

Es alojamiento gestionado para sitios y tiendas críticos. Planes por mes:

• Zafiro, 25 USD: 2 CPU, 3 GB de RAM, 70 GB NVMe.
• Esmeralda, 43 USD: 4 CPU, 6 GB, 100 GB.
• Rubí, 60 USD: 6 CPU, 9 GB, 130 GB.
• Diamante, 76 USD: 8 CPU, 12 GB, 150 GB.

Los recursos van separados en contenedores, con CPU, RAM e IO definidos por plan y sin sobreventa. Los datos tienen triple réplica en tres servidores distintos. Incluye backups diarios con ayuda en la restauración, monitoreo 24/7, migración gestionada de web y correos sin costo, firewalls y doble antivirus, Cloudflare y soporte 24/7 con respuesta en menos de 60 segundos. Tiene garantía de 30 días, lo cancelas cuando quieras y pagas el mismo precio mensual por cualquier periodo de 1 a 36 meses, también al renovar.

Dongee Cloud y Cloud On Demand

Dongee Cloud es un servidor cloud con procesadores Intel Xeon y acceso root completo por SSH, que se despliega en menos de 3 minutos. Incluye discos NVMe, red privada entre instancias sin costo, snapshots incrementales automáticos o manuales, backup de disco en todos los planes, IP dedicada, panel de control y 99,9 % de uptime. Hay 11 ubicaciones, entre ellas México, Miami, Dallas, São Paulo y Santiago de Chile. El plan Cloud 1 (1 CPU, 1 GB de RAM, 25 GB) cuesta 17 USD/mes. Para llevar tu WordPress a Dongee Cloud, la migración es asistida y cuenta con soporte 24/7. Una vez en el servidor, tú o tu agencia instalan y mantienen el servidor web, PHP, la base de datos, la caché y WordPress.

Con Cloud On Demand configuras vCPU, RAM y disco a tu medida: 6 USD por vCPU, 3 USD por GB de RAM y 0,3 USD por GB de disco al mes, con un mínimo de 17 USD/mes. Incluye backups automáticos y recuperación ante desastres sin costo extra.

Cuál te conviene

• Un sitio o pocos sitios, sin equipo técnico: WordPress PRO.
• Un sitio o una tienda crítica que no puede caerse, y prefieres que otros administren: Hosting Empresas.
• Un equipo técnico que quiere control total, un stack propio o varios servidores: Dongee Cloud o Cloud On Demand.

Si empiezas en WordPress PRO y tu sitio crece, puedes pasar a Hosting Empresas o a Dongee Cloud sin cambiar de proveedor.

Pasos para contratar y migrar tu WordPress

1. Haz un inventario. Anota dominios, sitios, tamaño de archivos y base de datos, cuentas de correo, plugins críticos y la versión de PHP que usas hoy.
2. Elige el producto y el plan. Usa la lista de verificación y la tabla comparativa. Decide si quieres administrar el servidor o no.
3. Contrata en línea. Elige el periodo de pago que te convenga y revisa la renovación.
4. Pide la migración. En WordPress PRO y en Hosting Empresas puedes solicitar la migración a Dongee. En Dongee Cloud, la migración es asistida y cuenta con soporte 24/7; tú o tu agencia siguen a cargo de instalar y mantener el servidor web, PHP, la base de datos y WordPress.
5. Prueba antes de cambiar el DNS. Revisa el sitio en la URL temporal o en staging: páginas clave, carrito y pagos, inicio de sesión y formularios.
6. Cambia el DNS. Apunta el dominio al nuevo hosting y deja el anterior activo unos días mientras se propaga el cambio.
7. Verifica SSL, caché, correo y formularios. Confirma que el certificado está activo, que la caché funciona, que el correo envía y recibe, y que los formularios llegan a su destino.
8. Configura las copias y prueba una restauración. Hazlo en staging o con un sitio de prueba para no tocar producción.
9. Revisa el rendimiento y escala si hace falta. Observa el sitio durante tus picos de tráfico y sube de plan solo si los datos lo justifican.

Preguntas frecuentes

¿Qué es un hosting WordPress en la nube?

Es un término comercial amplio. Puede referirse a un hosting WordPress gestionado sobre infraestructura redundante, a un hosting gestionado con recursos aislados en contenedores o a un servidor cloud donde tú instalas WordPress. En Dongee, WordPress PRO, Hosting Empresas y Dongee Cloud son las tres opciones de infraestructura en la nube para WordPress. Antes de comprar, pregunta quién administra el servidor y qué recursos tienes garantizados.

¿Es mejor un hosting WordPress gestionado o un servidor cloud?

Depende de quién va a administrar. Si no tienes un equipo técnico, el gestionado te ahorra mantenimiento y riesgos. Si tienes gente que domina Linux y quieres control total del stack, el servidor cloud te da esa libertad, a cambio de asumir tú las actualizaciones, la seguridad y las copias.

¿Puedo tener WooCommerce en un hosting WordPress?

Sí. WooCommerce es un plugin de WordPress y funciona en un hosting WordPress gestionado. Ten en cuenta que el carrito, el checkout y la cuenta del cliente son páginas dinámicas, así que conviene revisar el plan con calma y probar en staging. Si la tienda es crítica para tu negocio, considera un hosting empresarial con recursos aislados.

¿Necesito saber de servidores para usar un servidor cloud?

Sí. Con acceso root, tú instalas y mantienes el sistema operativo, el servidor web, PHP, la base de datos, la caché, el firewall y WordPress. Si no tienes esos conocimientos ni alguien que los tenga, es mejor una opción gestionada.

¿Quién migra mi sitio y se pierde el posicionamiento?

En WordPress PRO, el equipo de Dongee hace la migración asistida sin costo: web, base de datos y correos. En Hosting Empresas, la migración gestionada de web y correos es sin costo. En Dongee Cloud, la migración es asistida y cuenta con soporte 24/7. Una migración bien hecha mantiene el mismo dominio, las mismas URLs y el mismo contenido, así que el sitio que ven los buscadores no cambia. Después de migrar, revisa que no haya enlaces rotos ni redirecciones mal configuradas.

¿Puedo contratar desde México, Colombia o Perú y pagar en dólares?

Los precios están en USD y la contratación se hace en línea desde el sitio de Dongee.

¿Qué pasa si mi sitio crece?

Dongee ofrece estas tres gamas, así que puedes pasar de WordPress PRO a Hosting Empresas o a Dongee Cloud sin cambiar de proveedor. En WordPress PRO puedes subir de plan para tener más sitios, almacenamiento y recursos. Si necesitas recursos aislados y más acompañamiento, puedes pasar a Hosting Empresas. Si tu equipo quiere control total, Dongee Cloud y Cloud On Demand te permiten ajustar la infraestructura a tu medida.

¿Qué incluye la garantía?

WordPress PRO y Hosting Empresas tienen una garantía de 30 días. Antes de contratar, revisa las condiciones vigentes de cada producto en su página o consúltalas con soporte.

Elegir dónde alojar WordPress «en la nube» se reduce a una pregunta: ¿quién va a administrar el servidor? Respóndela, mide lo que realmente necesitas y verifica la lista antes de pagar. Si quieres resolverlo sin complicaciones, revisa Hosting WordPress PRO, Hosting Empresas o Dongee Cloud, y pide tu migración cuando estés listo.

La diferencia técnica de fondo es quién comparte qué y quién puede diseñar la redundancia: en un hosting compartido usas el mismo servidor, CPU, RAM y software que otras cuentas; en un hosting empresarial gestionado tienes recursos separados y el proveedor lo opera por ti; y en una nube con acceso root puedes construir alta disponibilidad con varias instancias, red privada, balanceador y snapshots, pero esa arquitectura la diseñas y mantienes tú. Ninguna opción da 100 % de disponibilidad, y un solo servidor sigue siendo un punto único de falla en cualquier modalidad.

Si ya leíste nuestra guía sobre cuándo pasar de hosting compartido a un servidor en la nube administrado o la comparación web hosting vs cloud hosting, este artículo toma otro camino: revisa capa por capa qué puede fallar, quién lo resuelve y qué puedes hacer tú en cada modalidad cuando tu sitio no se puede caer.

La diferencia en una frase: quién comparte qué

• Hosting compartido: compartes servidor, CPU, RAM y software (servidor web, PHP, base de datos) con otras cuentas. Lo administras desde un panel como cPanel y no tienes acceso root. El proveedor opera todo.
• Hosting empresarial gestionado: tus recursos están separados de los de otros clientes y tienen límites definidos. El proveedor sigue operando la plataforma, aplica los parches y vigila el servicio.
• Nube con root: tienes un servidor virtual con recursos asignados y control total del sistema operativo. Instalas, configuras, actualizas y proteges tú. Si quieres saber más sobre este modelo, revisa qué es un VPS.

Qué significa alta disponibilidad (y qué no)

Alta disponibilidad es la capacidad de un sistema para seguir respondiendo aunque falle uno de sus componentes. Se consigue eliminando puntos únicos de falla: si algo se rompe, otro elemento toma su lugar (a esto se le llama failover). Conviene separarla de dos conceptos con los que suele confundirse:

• Rendimiento: qué tan rápido responde tu sitio. Un servidor muy potente puede ser rápido y aun así caerse si es el único.
• Copias de seguridad: te permiten recuperar datos después de un problema, pero no evitan que el sitio quede fuera de línea mientras restauras.

El SLA de uptime es el compromiso del proveedor sobre la disponibilidad de su infraestructura: servidores, red, almacenamiento. No cubre errores de tu aplicación, un plugin que rompe el sitio, una base de datos mal configurada ni un despliegue fallido. Un porcentaje como 99,9 % indica qué proporción del tiempo el proveedor se compromete a mantener su plataforma operativa, y suele venir acompañado de condiciones y compensaciones definidas en sus términos.

Para planear la continuidad del negocio se usan dos medidas:

• RTO (Recovery Time Objective): cuánto tiempo puede estar caído tu servicio antes de que el daño sea inaceptable.
• RPO (Recovery Point Objective): cuántos datos puedes permitirte perder, medido como el tiempo entre la última copia y el incidente.

Un ejemplo: una tienda online decide que no puede perder pedidos ya confirmados y que debe volver a vender antes de que empiece su horario de mayor tráfico. Su RPO exige copias o réplica de la base de datos muy frecuentes, y su RTO exige tener un procedimiento de restauración probado o una instancia de respaldo lista. Un blog corporativo, en cambio, puede tolerar perder el último borrador y volver en línea más tarde. Las cifras las defines tú según tu negocio, no el proveedor.

Diferencias técnicas capa por capa

1. Almacenamiento y réplica de datos

El disco es uno de los componentes que más fallan. La pregunta clave es si tus datos viven en un solo disco o están replicados en varios.

• Compartido: depende del diseño del proveedor. En plataformas bien construidas el almacenamiento está replicado, de modo que la falla de un disco no implica perder datos. Tú no eliges ni ves esa arquitectura.
• Empresarial gestionado: normalmente con réplica de datos en varios servidores y operada por el proveedor.
• Nube con root: el almacenamiento de la plataforma puede estar replicado, pero eso protege contra la falla del disco, no contra que borres una tabla por error o que tu instancia deje de arrancar. La consistencia de tus datos dentro del servidor es tu responsabilidad.

2. Red

• Compartido y empresarial: la red la diseña y opera el proveedor. Tú no configuras rutas, firewalls de red ni conexiones entre servidores.
• Nube con root: la red de la plataforma (enlaces, rutas, redundancia de proveedores de tránsito) sigue siendo del proveedor, pero tú decides cómo se conectan tus instancias entre sí: red privada, reglas de firewall, qué puertos se exponen a internet y cuáles no.

3. Recursos y vecinos

El efecto vecino ruidoso ocurre cuando otra cuenta que comparte tu servidor consume tanta CPU, RAM o disco que afecta a las demás.

• Compartido: es el escenario donde más puede aparecer. Tecnologías como CloudLinux limitan lo que cada cuenta puede usar y reducen mucho el impacto, pero sigues compartiendo la máquina.
• Empresarial gestionado: recursos separados (por ejemplo en contenedores) con CPU, RAM e IO definidos. Si no hay sobreventa, lo que contrataste está disponible para ti.
• Nube con root: tienes recursos asignados a tu servidor virtual. En opciones dedicadas, la memoria, el procesamiento y el almacenamiento no se comparten con nadie.

4. Software, parches y seguridad

• Compartido: el proveedor actualiza el sistema operativo, el servidor web, PHP y la base de datos. Tú actualizas tu CMS, temas y plugins.
• Empresarial gestionado: igual, con más atención y monitoreo por cuenta.
• Nube con root: todo es tuyo: kernel, paquetes, servidor web, base de datos, certificados, firewall. Un parche olvidado o una actualización mal hecha puede tumbar el servicio o abrir una brecha.

5. Escalado ante picos

• Compartido: tienes los límites de tu plan. Ante un pico fuerte, el sitio se pone lento o devuelve errores hasta que baje la carga o cambies de plan.
• Empresarial gestionado: recursos definidos por plan y el proveedor te ayuda a subir de nivel cuando hace falta.
• Nube con root: puedes escalar verticalmente (más CPU y RAM en el mismo servidor) u horizontalmente (más instancias detrás de un balanceador). El escalado horizontal es el que además mejora la disponibilidad, pero requiere que tu aplicación esté preparada para funcionar en varias copias.

6. Copias y recuperación

• Compartido y empresarial: lo habitual son backups automáticos diarios y ayuda del soporte para restaurar.
• Nube con root: tienes herramientas como snapshots, pero decides qué se copia, cada cuánto, dónde se guarda y cómo se restaura. Para profundizar, revisa qué es un backup en la nube para empresas.

7. Quién atiende a las 3 a. m.

• Compartido: el proveedor detecta y resuelve fallas de plataforma. Si el problema está en tu sitio, el soporte te orienta, pero el código es tuyo.
• Empresarial gestionado: el proveedor monitorea y actúa de forma más proactiva.
• Nube con root: el proveedor responde por el hardware, la red y la virtualización. Si se cae tu servicio web, se llena el disco o falla la base de datos dentro de tu servidor, alguien de tu equipo tiene que estar disponible para atenderlo.

Tabla comparativa

Cómo armar alta disponibilidad paso a paso

Si eliges la nube con root y quieres eliminar puntos únicos de falla, este es un camino práctico:

1. Define qué no se puede caer y tu RTO/RPO. No todo necesita alta disponibilidad: el checkout de una tienda sí; el blog quizá no.
2. Separa la base de datos de la aplicación. Ponerlas en servidores distintos te permite duplicar la aplicación sin duplicar datos.
3. Duplica la aplicación en dos o más instancias. Usa el mismo código y la misma configuración; guarda las sesiones y archivos subidos en un lugar compartido, no en el disco local de cada instancia.
4. Conéctalas por red privada. La base de datos y el tráfico interno no deberían estar expuestos a internet.
5. Pon un balanceador con verificaciones de salud. Herramientas como Nginx o HAProxy reparten el tráfico y dejan de enviarlo a una instancia que no responde. Si quieres entender la diferencia con otros tipos de enrutamiento, lee enrutamiento de modelos de IA vs balanceo de carga.
6. Replica o respalda la base de datos. Una réplica permite cambiar a otro servidor si el principal falla; sin ella, la base de datos sigue siendo un punto único de falla.
7. Toma un snapshot antes de cada cambio. Actualizaciones del sistema, cambios de versión o despliegues grandes: siempre con un punto de regreso.
8. Guarda copias fuera del servidor y prueba la restauración. Una copia que nunca restauraste es una suposición, no un plan.
9. Configura monitoreo externo y alertas. Vigila tu sitio desde fuera de tu infraestructura y recibe avisos por un canal que realmente revises.
10. Ensaya la caída de una instancia. Apaga una a propósito en un horario de bajo tráfico y comprueba que el servicio sigue respondiendo.

Todo esto exige a alguien que sepa administrar servidores y que esté disponible cuando algo falle. Si no tienes ese perfil en tu equipo, un hosting empresarial gestionado suele ser la opción más sensata: obtienes aislamiento y operación profesional sin tener que construirla tú. Las agencias que evalúan esta decisión para varios clientes pueden revisar servidores propios vs nube gestionada para agencias digitales.

Errores comunes

• Confundir backup con alta disponibilidad. El backup recupera datos; la alta disponibilidad evita la caída. Necesitas ambas cosas.
• Creer que más RAM evita caídas. Más recursos mejoran el rendimiento, pero un servidor grande sigue siendo un solo servidor.
• Un solo servidor para todo. Web, base de datos, correo y tareas programadas en la misma máquina: si falla una pieza, cae todo.
• No probar restauraciones. Muchas copias se descubren incompletas justo el día en que se necesitan.
• Actualizar en producción sin snapshot. Un cambio de versión de PHP o de la base de datos sin punto de regreso puede convertirse en horas de trabajo.
• DNS sin plan de respaldo. Si tu DNS falla o no sabes cómo apuntar rápido a otro servidor, tu redundancia no sirve de mucho.
• Monitorear solo desde dentro del mismo servidor. Si el servidor se cae, el monitoreo cae con él y nadie se entera.
• Ignorar la base de datos como punto único de falla. Duplicar la aplicación no sirve de mucho si todas las instancias dependen de una sola base de datos sin réplica.

Cómo encaja Dongee

En Dongee tenemos opciones para cada uno de estos modelos, y lo más honesto es elegir según tu equipo y el impacto real de una caída.

Para sitios estándar: el hosting compartido de Dongee tiene los planes Emprende desde 10 USD/mes y Quantum desde 19 USD/mes, con cPanel y CloudLinux sobre SSD NVMe y 99,9 % de uptime garantizado. Funciona sobre la infraestructura GeeCloud, con datos en triple réplica sobre discos NVMe enterprise, backups automáticos diarios con restauración asistida y Cloudflare.

Para sitios y tiendas críticos sin equipo técnico: el Hosting Empresas de Dongee es gestionado y separa los recursos en contenedores, con CPU, RAM e IO definidos por plan y sin sobreventa. Incluye triple réplica de datos en tres servidores diferentes, backups diarios con ayuda en la restauración, monitoreo 24/7, migración gestionada de web y correos, y soporte 24/7 con respuesta en menos de 60 segundos. Los planes son Zafiro (25 USD/mes), Esmeralda (43 USD/mes), Rubí (60 USD/mes) y Diamante (76 USD/mes).

Para equipos que quieren diseñar su propia redundancia: Dongee Cloud te da acceso root SSH completo, despliegue en menos de 3 minutos y 99,9 % de uptime garantizado, el mismo compromiso que en el hosting compartido. En todos los planes de Cloud tienes red redundante con BGP multihoming, snapshots incrementales automatizados o manuales, backups incluidos, red privada aislada entre tus instancias sin costo extra e IP dedicada. Puedes elegir entre Atlanta, Miami, NY, Dallas, México, São Paulo, Santiago de Chile, Frankfurt, Madrid, Londres y Amsterdam, con 7 planes fijos desde 17 USD/mes (Cloud 1: 1 CPU, 1 GB RAM, 25 GB). Si necesitas recursos que no se comparten, Cloud Dedicado ya se puede contratar: ofrece memoria, procesamiento y almacenamiento exclusivos, con infraestructura de alta disponibilidad y triple réplica de datos, y solo está en la zona Norteamérica Este. Dongee no vende un balanceador gestionado: puedes montar el tuyo con Nginx o HAProxy entre instancias, usando la red privada.

Para dimensionar a la medida: con Cloud On Demand eliges de 1 a 64 vCPU, de 1 a 256 GB de RAM y de 25 a 2.000 GB SSD NVMe. Pagas 6 USD por vCPU, 3 USD por GB de RAM y 0,3 USD por GB de almacenamiento al mes, con un mínimo de 17 USD/mes. Incluye almacenamiento NVMe de alta disponibilidad con triple replicación, copias de seguridad automatizadas y recuperación ante desastres, sin costo extra.

En todos los casos tienes soporte humano 24/7 que te atiende en tu idioma, porque la plataforma traduce al vuelo.

Preguntas frecuentes

¿Un hosting compartido es menos confiable que la nube?

No necesariamente. Un hosting compartido bien gestionado, con almacenamiento replicado y límites por cuenta, puede tener buena disponibilidad para sitios estándar. Su límite es que compartes recursos y no puedes diseñar redundancia propia. Una nube mal administrada puede ser menos confiable que un buen hosting compartido.

¿Qué significa 99,9 % de uptime garantizado?

Es el compromiso del proveedor de mantener su infraestructura operativa durante esa proporción del tiempo, según las condiciones de su SLA. Cubre servidores, red y plataforma, no los errores de tu aplicación, tus plugins ni tus configuraciones. En Dongee, ese 99,9 % aplica tanto al hosting compartido como a Cloud.

¿Un servidor en la nube nunca se cae?

Sí se puede caer. Puede fallar el sistema operativo, llenarse el disco, colgarse la base de datos o fallar una actualización. La nube te da herramientas para construir redundancia, pero un solo servidor sigue siendo un punto único de falla.

¿Necesito un balanceador de carga?

Solo si tienes dos o más instancias de tu aplicación y quieres que el tráfico siga fluyendo cuando una falle. Con un único servidor, un balanceador no aporta disponibilidad. Recuerda que el balanceador también puede ser un punto único de falla si no lo duplicas.

¿Backup y alta disponibilidad son lo mismo?

No. El backup te permite recuperar datos después de un incidente; la alta disponibilidad busca que el servicio siga funcionando durante el incidente. Un sitio con buenos backups puede pasar un buen rato fuera de línea mientras se restaura.

¿Qué es el efecto vecino ruidoso?

Es la degradación que sufre tu sitio cuando otra cuenta que comparte el mismo servidor consume demasiados recursos. Se reduce con límites por cuenta y desaparece en gran medida cuando tus recursos están separados o son dedicados.

¿Puedo empezar en compartido y migrar después?

Sí, y es una ruta habitual. Empieza en compartido mientras tu sitio sea estándar y pasa a empresarial gestionado o a la nube cuando una caída empiece a costarte ventas o clientes. Planea la migración con tiempo y con copias verificadas.

¿Qué conviene a una tienda online que vende todo el día?

Si no tienes a alguien que administre servidores, un hosting empresarial gestionado con recursos separados, réplica de datos y monitoreo suele ser la opción más equilibrada. Si tienes un equipo técnico y necesitas que la tienda siga vendiendo aunque falle un servidor, una arquitectura en la nube con varias instancias, balanceador y base de datos replicada te da más control, a cambio de más trabajo de operación.

Conclusión

La diferencia entre un hosting compartido y una nube empresarial no está solo en la potencia: está en quién comparte los recursos, quién opera cada capa y quién puede diseñar la redundancia. Define primero cuánto tiempo puedes estar fuera de línea y cuántos datos puedes perder, y después elige el modelo que tu equipo realmente pueda sostener. Si quieres ayuda para decidir, nuestro equipo de soporte puede revisar tu caso y recomendarte entre Hosting Empresas y Dongee Cloud.

La integración de herramientas de IA influye en los tiempos de carga de un sitio web corporativo en dos sentidos: puede acelerar el trabajo de optimización o volver el sitio más lento. Por un lado, la IA te ayuda a interpretar reportes de rendimiento, detectar scripts pesados, escribir código más eficiente y preparar imágenes livianas. Por otro, los chatbots, personalizadores y analíticas con IA suelen agregar JavaScript de terceros y llamadas a APIs que empeoran el LCP y el INP. La IA facilita el diagnóstico y los ajustes, pero no reemplaza lo básico: buen hosting, caché, CDN, imágenes optimizadas y poco JavaScript.

Esta guía es para equipos de marketing, TI y agencias que mantienen sitios corporativos en WordPress, en otros CMS o hechos a medida. Explica en qué casos la IA ayuda, en cuáles perjudica y cómo integrar funciones inteligentes sin sacrificar la velocidad.

Qué se mide cuando hablamos de tiempo de carga

«Tiempo de carga» no es un solo número. Para decidir si una herramienta de IA ayuda o perjudica, conviene separar estas métricas:

• TTFB (Time to First Byte): el tiempo que tarda el servidor en empezar a responder. Depende sobre todo del hosting, de la caché de página y de la distancia entre el servidor y el visitante.
• LCP (Largest Contentful Paint): el momento en que se muestra el elemento principal de la página, normalmente una imagen destacada o un bloque de texto grande.
• INP (Interaction to Next Paint): la rapidez con que la página responde cuando el usuario hace clic, escribe o toca algo. El JavaScript pesado es su principal enemigo.
• CLS (Cumulative Layout Shift): mide cuánto se mueve el contenido mientras carga. Lo provocan, por ejemplo, los banners o widgets que aparecen de golpe.

LCP, INP y CLS forman los Core Web Vitals. Para evaluarlos, compara tus resultados con los umbrales que publica Google, no con cifras sacadas de foros. Ten presente también la diferencia entre dos tipos de datos:

• Datos de laboratorio: una prueba simulada en condiciones controladas, como Lighthouse o WebPageTest. Sirven para depurar y comparar antes y después de un cambio.
• Datos de campo: provienen de visitantes reales con sus propios dispositivos y conexiones. PageSpeed Insights los muestra cuando hay suficiente tráfico. Son los que reflejan la experiencia real.

En un sitio corporativo, la velocidad afecta más que el SEO. Un formulario de contacto que tarda en responder pierde prospectos, una página que salta mientras carga transmite poca confianza y un sitio lento en móvil desaprovecha la inversión en campañas. Si quieres profundizar en el impacto de negocio, revisa por qué es necesario mejorar el tiempo de carga de tu web.

Dónde la IA sí ayuda a cargar más rápido

Diagnóstico e interpretación de reportes

Los reportes de Lighthouse, PageSpeed Insights o la pestaña Performance de Chrome DevTools son muy completos, pero difíciles de leer si no eres especialista. Un asistente de IA puede resumir el reporte en lenguaje claro, explicar qué recurso retrasa el LCP, agrupar las recomendaciones por impacto y esfuerzo y convertirlas en una lista de tareas para el equipo.

Límite honesto: la IA puede malinterpretar una métrica o recomendar algo que no aplica a tu CMS. Úsala para entender el reporte, pero confirma cada hallazgo en la herramienta original y mide antes y después de cada cambio.

Asistentes de código para refactorizar CSS y JavaScript

Los asistentes de IA para programar sirven para tareas tediosas que mejoran la carga: identificar CSS que no se usa, proponer qué estilos críticos deben ir en línea, agregar defer o async a scripts que no son esenciales, dividir paquetes de JavaScript grandes en fragmentos que se cargan bajo demanda o reemplazar una librería pesada por código nativo.

Límite honesto: el código generado puede romper funcionalidades sin que lo notes a simple vista, como un menú móvil, un slider o la validación de un formulario. Revisa cada cambio, pruébalo en un entorno de pruebas y conserva un respaldo antes de publicar.

Optimización de imágenes y medios

Las imágenes suelen ser el recurso más pesado de un sitio corporativo. Hay herramientas con IA que redimensionan, recortan de forma inteligente, comprimen y convierten a formatos modernos como WebP o AVIF. También pueden generar textos alternativos descriptivos, algo útil para la accesibilidad y el SEO aunque no influye en la velocidad. La guía para optimizar imágenes para web explica los fundamentos.

Límite honesto: una compresión agresiva puede degradar fotos de producto o logos. Los textos alternativos generados deben revisarse, porque a veces describen mal la imagen o no aportan contexto.

Contenido y plantillas más livianos

La IA ayuda a auditar plantillas y detectar bloques que nadie usa, como carruseles con diez diapositivas, videos de fondo en reproducción automática o fuentes con demasiadas variantes. También puede proponer versiones más simples de una página de inicio o resumir contenido extenso para que la parte visible al cargar sea más ligera.

Límite honesto: que una sección sobra es una decisión de negocio y de marca, no solo técnica. La IA sugiere, pero marketing y TI deciden juntos.

Caché, CDN y filtrado de bots con aprendizaje automático

En la capa de red, algunas CDN y firewalls de aplicaciones web usan aprendizaje automático para decidir qué contenido cachear, enrutar el tráfico y distinguir visitantes reales de bots. Filtrar el tráfico automatizado abusivo libera recursos del servidor para los usuarios legítimos.

Límite honesto: estos sistemas pueden bloquear por error bots legítimos, como algunos rastreadores o integraciones, o cachear páginas que no deberían cachearse, por ejemplo con contenido personalizado o carritos. Revisa las reglas y los registros periódicamente.

Dónde la IA puede volver lento tu sitio

La otra cara es menos visible. Muchas funciones de IA se instalan pegando un script en el sitio, y cada script tiene un costo:

• Chatbots y asistentes conversacionales: suelen cargar un paquete de JavaScript considerable, hojas de estilo, fuentes y conexiones a varios dominios desde el primer momento, aunque el visitante nunca abra el chat. Compiten con el contenido principal (afectan el LCP) y ocupan el hilo principal (afectan el INP).
• Personalización y recomendadores: si el contenido de la página espera la respuesta de un servicio externo para decidir qué mostrar, el elemento principal tarda más en aparecer. Si se reemplaza contenido ya visible, también aumenta el CLS.
• Analítica, mapas de calor y grabación de sesiones con IA: registran cada movimiento y clic, lo que agrega trabajo constante en el navegador y puede degradar el INP, sobre todo en móviles de gama media.
• Traductores automáticos en el navegador: los widgets que traducen la página después de cargarla obligan a descargar el contenido, procesarlo y volver a pintarlo. Eso genera parpadeos, desplazamientos de diseño y una peor percepción de velocidad.
• Imágenes generadas con IA sin optimizar: suelen exportarse en alta resolución y en formatos pesados. Subirlas tal cual a la página de inicio es una de las formas más rápidas de empeorar el LCP.
• Llamadas síncronas a APIs de modelos: si la página espera la respuesta de un modelo de lenguaje para mostrar contenido, el tiempo de carga queda atado a la latencia de ese servicio, que puede variar mucho.

Estas funciones pueden aportar valor. El problema está en cómo se integran: cargadas desde el inicio, de forma bloqueante y desde el navegador.

Cómo integrar funciones de IA sin sacrificar velocidad

1. Mide una línea base. Antes de instalar nada, registra los datos de campo (si tu sitio tiene tráfico suficiente) y de laboratorio de tus páginas clave: inicio, servicios, contacto y landing pages. Puedes apoyarte en estas herramientas para hacer un test de velocidad de carga web.
2. Haz un inventario de scripts de terceros. En Chrome DevTools, revisa la pestaña Network y la cobertura de código. Anota qué script pertenece a qué herramienta, quién lo pidió y si todavía se usa.
3. Carga el chatbot solo cuando el usuario lo pida. Muestra un botón ligero (una «fachada») con la apariencia del chat y descarga el widget real cuando el visitante haga clic. Así, quien no usa el chat no paga su costo.
4. Usa async, defer y carga diferida. Ningún script de IA que no sea indispensable para el contenido visible debe bloquear el renderizado. Los iframes y las imágenes fuera de la primera pantalla pueden usar loading="lazy".
5. Llama a los modelos desde tu backend, no desde el navegador. Tu servidor recibe la pregunta, consulta el modelo y devuelve la respuesta. Guarda en caché las respuestas a preguntas frecuentes y usa streaming cuando aplique, para que el usuario vea el texto a medida que se genera.
6. No expongas tus claves de API. Una clave en el código del navegador puede ser copiada y usada por terceros, con costos y riesgos para tu empresa. Guárdala en variables de entorno del servidor.
7. Define un presupuesto de rendimiento por página. Fija límites de peso de JavaScript, número de solicitudes de terceros y métricas objetivo basadas en los umbrales que publica Google. Toda nueva función de IA debe caber en ese presupuesto o reemplazar algo existente.
8. Optimiza las imágenes generadas con IA. Expórtalas al tamaño real en que se mostrarán, conviértelas a WebP o AVIF, define ancho y alto para evitar desplazamientos y aplica carga diferida a las que no estén en la primera pantalla.
9. Activa caché de página y CDN. La caché reduce el trabajo del servidor y mejora el TTFB. La CDN acerca los archivos estáticos al visitante. Nada de esto depende de la IA, y es lo que más se nota en sitios con tráfico regional.
10. Vuelve a medir y monitorea. Tras cada cambio, compara contra la línea base. Los datos de campo tardan en reflejar las mejoras, así que haz seguimiento durante varias semanas.

Este es un ejemplo sencillo de fachada para un chatbot: un botón que carga el script del widget solo al hacer clic.

<button id="abrir-chat" type="button" aria-label="Abrir chat de ayuda">
  💬 ¿Necesitas ayuda?
</button>

<script>
  document.getElementById('abrir-chat').addEventListener('click', function () {
    var boton = this;
    boton.disabled = true;
    boton.textContent = 'Cargando chat…';

    var script = document.createElement('script');
    script.src = 'https://ejemplo.com/widget.js';
    script.async = true;
    script.onload = function () {
      boton.remove();
      // Abre el chat con la función que indique tu proveedor, por ejemplo:
      // window.MiChat && window.MiChat.open();
    };
    script.onerror = function () {
      boton.disabled = false;
      boton.textContent = 'Reintentar chat';
    };
    document.body.appendChild(script);
  }, { once: false });
</script>

Adapta el nombre de la función de apertura a la documentación del proveedor del chat. Reserva un espacio fijo para el botón, así su aparición no mueve el diseño.

Comparación honesta: formas de optimizar la carga

Estas opciones no compiten entre sí, sino que se combinan. La IA no arregla un servidor lento: si el TTFB es alto por falta de recursos o de caché, ningún asistente de código lo resolverá desde el navegador.

Errores comunes

• Instalar un chatbot con IA directamente en el <head>, cargándolo en todas las páginas aunque casi nadie lo use.
• Aplicar código sugerido por IA sin revisarlo ni probarlo en un entorno de pruebas.
• Medir solo con laboratorio e ignorar los datos de campo, o al revés.
• Llamar a la API del modelo desde el navegador, con la clave expuesta y la carga atada a la latencia del proveedor.
• Subir imágenes generadas con IA en su resolución original a la página de inicio.
• Acumular herramientas de analítica que miden lo mismo, cada una con su propio script.
• Culpar al CMS o al tema cuando el problema real es un servidor sin recursos suficientes o sin caché.
• No volver a medir después de cada integración, con lo que se pierde la pista de qué empeoró la carga.

Cómo encaja Dongee

La base de un sitio rápido es la infraestructura, y ahí Dongee ofrece varias opciones según el tamaño y la criticidad del sitio. Si necesitas ayuda para elegir, puedes revisar esta comparativa de hosting WordPress rápido y seguro.

• Hosting compartido de Dongee: plan Emprende desde 10 USD/mes y Quantum desde 19 USD/mes, con discos SSD NVMe y cPanel. Emprende incluye AccelerateWP Lite. Quantum incluye AccelerateWP Pro con Redis Caché. Ambos traen Cloudflare integrado, LiteSpeed Cache para Magento y PrestaShop y backups diarios. Además, con MCP Dongee puedes pedirle a tu asistente de IA que cree buzones, gestione bases de datos o ajuste DNS y certificados.
• Hosting Empresas: para sitios corporativos críticos. Los planes son Zafiro (25 USD/mes), Esmeralda (43 USD/mes), Rubí (60 USD/mes) y Diamante (76 USD/mes). Cada uno tiene recursos separados en contenedores, con CPU, RAM e IO definidos por plan y sin sobreventa, almacenamiento NVMe y Cloudflare para acelerar y proteger los dominios. Incluye monitoreo 24/7, migración gestionada de web y correos, backups diarios, Dongee Live y soporte 24/7 con respuesta en menos de 60 segundos. Rubí agrega revisiones periódicas de rendimiento y Diamante, una auditoría técnica y de rendimiento en video.
• Hosting Edge: otra opción de hosting de Dongee. Consulta la página del producto para ver planes y características.
• Dongee CDN: sirve tu contenido desde el nodo más cercano al visitante, con caché avanzado y protección DDoS 24/7. Tiene un plan gratuito de 1 GB de transferencia mensual y planes de pago según la transferencia. Cada servicio cubre un sitio y el equipo te ayuda con la configuración inicial.
• Dongee AI Router: si tu sitio usa un chatbot u otras funciones de IA, te permite llamar a varios modelos desde tu backend con una sola clave compatible con el estándar OpenAI. Da prioridad a modelos rápidos alojados en el data center de Dongee en Canadá. Funciona con prepago desde 3 USD, sin mensualidad, y encaja con la recomendación de no llamar a los modelos desde el navegador.

Si tienes dudas, el soporte te atiende en tu idioma, porque la plataforma traduce las conversaciones al vuelo.

Preguntas frecuentes

¿Un chatbot con IA hace más lento mi sitio?

Puede hacerlo si se carga completo al abrir la página, porque agrega JavaScript, estilos y conexiones externas que compiten con el contenido principal. Si lo cargas solo cuando el visitante hace clic en un botón ligero, el impacto en la carga inicial se reduce mucho.

¿La IA puede optimizar mi sitio sola?

No. La IA acelera el diagnóstico y propone cambios, pero alguien debe validarlos, probarlos y medir el resultado. Tampoco puede compensar un servidor sin recursos, sin caché o lejos de tus visitantes.

¿Qué métrica afecta más un widget de IA?

Normalmente el INP, porque el JavaScript del widget ocupa el hilo principal y retrasa la respuesta a los clics. También puede afectar el LCP si compite por ancho de banda al inicio y el CLS si aparece sin un espacio reservado.

¿Sirve un CDN si mis visitantes están en un solo país?

Sí. Aunque tu audiencia esté en un solo país, la CDN puede servir los archivos estáticos desde nodos cercanos, quitar carga a tu servidor y agregar protección ante ataques. El beneficio depende de dónde esté tu servidor respecto a tus visitantes.

¿Conviene generar imágenes con IA para la web?

Puede convenir para ilustraciones o recursos de apoyo, siempre que las optimices: tamaño real de visualización, formato moderno como WebP o AVIF, dimensiones definidas y carga diferida. Revisa también los derechos de uso y que la imagen represente bien a tu marca.

¿Cómo mido si una integración de IA empeoró la carga?

Mide antes de instalarla y después, con las mismas páginas y condiciones en Lighthouse o WebPageTest. Luego sigue los datos de campo en PageSpeed Insights durante algunas semanas. En Chrome DevTools puedes ver cuánto tiempo de ejecución consume el script del proveedor.

¿Qué hosting necesita un sitio corporativo con funciones de IA?

Uno con recursos garantizados, caché de página, CDN y la posibilidad de ejecutar lógica en el servidor para llamar a los modelos de forma segura. Si el sitio es crítico para el negocio, conviene un plan con recursos sin sobreventa, monitoreo y soporte permanente.

¿Dónde llamo a la API del modelo, en el navegador o en el servidor?

En el servidor. Así proteges tu clave de API, puedes guardar en caché las respuestas frecuentes y controlas los tiempos de espera, sin que la carga de la página dependa de la latencia del proveedor del modelo.

Conclusión

La IA es una gran aliada para entender reportes, escribir mejor código y preparar recursos livianos. Mal integrada, también es una fuente frecuente de lentitud. La regla práctica es medir primero, cargar las funciones de IA solo cuando aporten valor, llamar a los modelos desde tu backend y apoyarte en una infraestructura sólida con caché y CDN. Si quieres revisar si tu hosting actual está a la altura de tu sitio corporativo, compara las opciones de Hosting Empresas y elige la que corresponda a tu tráfico y a lo crítico que es tu sitio.

Para publicar con tu propio dominio la app que hiciste con IA, aunque no sepas programar, necesitas tres cosas: 1) tener tu dominio registrado en un registrador, 2) publicar la app en una plataforma que acepte dominio propio, como Dongee Live, y 3) apuntar los DNS de tu dominio a esa plataforma y esperar la propagación. No tienes que escribir código: tu IA hace la app, la plataforma la pone en línea y tú solo copias unos datos de un panel a otro.

Si ya leíste nuestra guía sobre dónde publicar una app hecha con ChatGPT o Lovable, ya sabes cómo poner tu proyecto en internet. Este artículo va un paso más allá y se enfoca en lo que más confunde a quien no es técnico: que tu app abra en miapp.com, minegocio.com.mx, mitienda.pe o miempresa.co, y no en una dirección larga y genérica. Te lo explicamos sin jerga y paso a paso.

Dominio, hosting y app: las 3 piezas

Antes de tocar nada, conviene entender qué es cada cosa. Piensa en un negocio físico:

• El dominio es la dirección. Es el nombre que la gente escribe en el navegador (por ejemplo, miapp.com). Igual que una dirección postal, no es el negocio: solo indica dónde encontrarlo.
• El hosting es el local o el terreno. Es el servidor donde vive tu app, encendido las 24 horas para que cualquiera pueda entrar.
• La app es el negocio. Es lo que hiciste con la IA: tu tienda, tu agenda de citas, tu cotizador o tu panel de clientes.

Los DNS son el letrero que une la dirección con el local. Son una especie de directorio de internet que dice: «cuando alguien escriba miapp.com, llévalo a este servidor». Si quieres profundizar, revisa la diferencia entre hosting y dominio.

Lo importante: el dominio y el hosting pueden estar en empresas distintas. Puedes comprar el dominio en un lugar y publicar tu app en otro; solo tienes que conectar ambos con los DNS.

Antes de empezar: lo que necesitas

• Tu app hecha con IA (en Lovable, Bolt, v0, Claude Code, Codex, Cursor, VS Code o el código que te dio ChatGPT).
• Un dominio propio, o la decisión de cuál vas a comprar.
• Acceso al panel del registrador donde está (o estará) tu dominio: usuario y contraseña.
• Una cuenta en la plataforma donde vas a publicar. En Dongee Live puedes empezar con el plan gratuito Live Free.
• Unos 30 minutos de tu tiempo y algo de paciencia para la propagación.

Paso a paso: tu app con tu propio dominio

1. Elige y registra tu dominio. Busca un nombre corto, fácil de decir y de escribir. Decide la terminación: .com si piensas en público internacional, o la de tu país si tu mercado es local: .mx o .com.mx en México, .pe o .com.pe en Perú, .co o .com.co en Colombia. Estos dominios se registran a través de un registrador acreditado; detrás de cada terminación hay una entidad que administra el registro (NIC México para .mx y .com.mx, NIC.pe para .pe y .com.pe, y el registro .CO para .co). Si no tienes claro qué hace un registrador, lee qué es un registrador de dominio y para qué sirve. Muy importante: registra el dominio a tu nombre o al de tu empresa, con un correo que revises.
2. Publica tu app. Aquí hay tres caminos, según la herramienta que usaste:

• Si la hiciste con Lovable, Bolt o v0: conecta el repositorio de GitHub de tu proyecto a Dongee Live. Desde ese momento, cada vez que haya un cambio (un «push»), la app se publica sola. La compilación se hace en GitHub, así que no tienes que instalar nada.
• Si usas Claude Code, Codex o Cursor: ejecuta una sola vez en la terminal npx skills add dongeelive/skills -g -y. Después solo le dices a tu IA «publica» y ella la pone en línea mediante el conector.
• Si el código te lo dio ChatGPT en el chat: copiar y pegar archivos a mano suele terminar en errores. Lo más sencillo es pasar ese código a una herramienta como Cursor o Claude Code y pedirle que lo publique, o escribirle a soporte para que te orienten.No necesitas Git ni SSH para el flujo habitual: tu IA escribe el código y Dongee Live se encarga de publicarlo.

1. Prueba primero con el subdominio gratuito. Antes de conectar tu dominio, revisa que la app funcione en la dirección gratuita de Dongee, del tipo miapp.dongee.live. Así separas problemas: si algo falla aquí, es de la app, no del dominio.
2. Conecta tu dominio propio en el panel. En el panel de Dongee Live, agrega tu dominio a la app (por ejemplo, miapp.com o app.minegocio.com). Hoy el dominio se configura ahí mismo, en el panel de Dongee Live, con los DNS de Dongee, y el panel te indicará qué cambios debes hacer en tu registrador. Tu dominio propio conectado a Live incluye certificado SSL, así que tu app funciona con HTTPS.
3. Copia esos datos en tu registrador. Entra al panel de la empresa donde compraste el dominio, busca la sección de DNS (a veces aparece como «Nameservers» o «Zona DNS») y aplica exactamente lo que te indicó el panel de Dongee Live. No inventes valores ni cambies nada que el panel no te pida. Si nunca lo has hecho, esta guía te ayuda: cómo agregar DNS a mi dominio.
4. Espera la propagación. Los cambios de DNS no son instantáneos: los servidores de internet guardan copias temporales y tardan en actualizarse. Normalmente tarda minutos, pero puede llegar a 24 o 48 horas. Esto es así con cualquier proveedor. Te lo explicamos en qué es la propagación de DNS.
5. Comprueba que funciona. Usa la herramienta gratuita de consulta DNS de Dongee: escribe tu dominio y verifica que los registros coinciden con lo que te pidió el panel. Si todavía aparecen los valores viejos, la propagación no ha terminado o el cambio se hizo en el lugar equivocado.
6. Configura el correo con tu dominio. Un correo como hola@miapp.com da mucha más confianza que uno gratuito. En Dongee Live puedes usarlo por webmail o configurarlo en tu celular o programa de correo por IMAP. Ojo: está pensado para comunicación normal, no para envíos masivos.
7. Revisa que todo abre bien. Abre tu dominio en el computador y en el celular, con y sin www, en una ventana de incógnito. Prueba los formularios, el inicio de sesión y cualquier botón que use la base de datos. Pídele a un amigo en otra ciudad o país que también lo abra.

Dominio raíz, www o subdominio: ¿cuál usar?

Una misma dirección puede escribirse de varias formas, y cada una se configura por separado en los DNS. Esta tabla te ayuda a decidir:

Comparación honesta: opciones para publicar tu app con dominio propio

No existe una única respuesta correcta. Depende de tu app, de cuánto sabes y de lo que estás dispuesto a administrar. Así se comparan los tipos de opciones:

Siendo honestos: si tu app usa Python, Ruby, Docker o una base de datos distinta de MySQL, Dongee Live no es para ti; un VPS o una plataforma para desarrolladores te dará más flexibilidad. Si es WordPress o PHP, el hosting con cPanel de Dongee es el lugar indicado.

Cómo se ve en Dongee Live

Dongee Live publica apps y sitios hechos con ChatGPT, Lovable, Bolt, v0, Claude Code, Codex, Cursor y VS Code. Acepta sitios estáticos (HTML/CSS/JS, React, Vue, Svelte, Angular, Astro, Vite) y Node.js 20, 22 y 24 (Express, Fastify, Koa, Hono, Next.js standalone, TanStack Start y el stack actual de Lovable). Cada app tiene su base de datos MySQL, sus propias variables de entorno y puede enviar correo por SMTP saliente (puertos 587 y 465). Cada publicación puede pesar hasta 100 MB desde el conector y 32 MB por subida desde GitHub. Si tu app envía correos, mira también cómo publicar una app Next.js con correos SMTP.

En Live Pro y Live Team puedes conectar un dominio propio en cada app. Live Free no incluye el registro gratuito de un dominio: el dominio lo pagas en tu registrador y luego lo conectas. Si quieres saber más del plan sin costo, lee hosting gratis con uso comercial para tu app hecha con IA.

Errores comunes

• Dejar el dominio a nombre de otra persona o agencia. Si quien lo registró desaparece, puedes perder tu dirección. Revisa quién es el titular y cuándo vence con la consulta WHOIS de Dongee.
• Olvidar la renovación. Los dominios se pagan por periodos. Si no renuevas a tiempo, tu app deja de abrir y alguien más podría quedarse con el nombre. Activa la renovación automática y mantén al día el correo de contacto.
• Editar los DNS en el lugar equivocado. Los DNS se editan donde apuntan los servidores de nombres de tu dominio, que no siempre es donde lo compraste. Si cambias registros en un panel que no está activo, nada pasará.
• Borrar los registros MX. Son los que dirigen tu correo. Si los eliminas al «limpiar» la zona DNS, dejarás de recibir correos. Cambia solo lo que te indique el panel.
• Esperar que funcione al instante. La propagación puede tardar. No cambies los registros una y otra vez: solo complicas el diagnóstico.
• Mezclar www y sin www. Si solo configuras una versión, la otra dará error. Define una principal y haz que la otra lleve a ella.
• Usar el subdominio gratuito en material impreso. Tarjetas, volantes o empaques con miapp.dongee.live te amarran a esa dirección. Imprime siempre tu dominio propio.
• Poner claves o secretos en el código del navegador. Lo que corre en el navegador lo puede ver cualquiera. Guarda claves en variables de entorno. Más consejos en cómo lograr que tu app hecha con IA sea segura y no se caiga.

Preguntas frecuentes

¿Necesito saber programar para publicar mi app con mi dominio?

No. Tu IA escribe el código y Dongee Live se encarga de publicarlo. Para el dominio solo debes copiar unos datos del panel de Dongee Live al panel de tu registrador. No necesitas Git ni SSH para el flujo habitual.

¿Puedo usar mi dominio .mx, .com.mx, .pe, .com.pe, .co o .com.co?

Sí. Registras el dominio con un registrador acreditado para esa terminación y luego lo conectas a tu app apuntando sus DNS como te indique el panel. La terminación no cambia el proceso de conexión.

¿El plan gratis permite usar dominio propio?

Sí. Live Free permite conectar un dominio propio o usar un subdominio gratuito tipo miapp.dongee.live. Lo que no incluye es registrar gratis un dominio: ese lo pagas en tu registrador.

¿El dominio propio incluye HTTPS?

Sí. El dominio propio que conectes a Dongee Live incluye certificado SSL, así que tu app funciona con HTTPS. No tienes que comprarlo aparte.

¿Cuánto tarda en funcionar el dominio?

Normalmente, minutos después de cambiar los DNS, pero la propagación puede tardar hasta 24 o 48 horas. Puedes revisar el avance con la consulta DNS de Dongee.

¿Puedo tener correo con mi dominio?

Sí. Con Dongee Live tienes correo con tu dominio por webmail o IMAP (Live Free incluye 1 correo). No es para envíos masivos. Además, tu app puede enviar correos por SMTP saliente.

¿Y si ya tengo hosting con Dongee?

Dongee Live viene incluido en los planes de hosting de Dongee y permite crear entre 2 y 6 apps según el plan, usando las capacidades del plan contratado. Si tu empresa necesita más recursos, revisa el hosting para empresas.

¿Dongee Live publica modelos de IA?

No. Dongee Live publica las apps y sitios que creas con herramientas de IA, no despliega ni ejecuta modelos de inteligencia artificial.

¿Qué pasa si mi app es en PHP, Python o WordPress?

Dongee Live no soporta Python, Ruby, PHP/WordPress ni Docker. Si tu proyecto es PHP o WordPress, publícalo en el hosting con cPanel de Dongee, que incluye correo con tu dominio, backups diarios, Cloudflare, Imunify360 y soporte humano 24/7. Para Python necesitarás otro tipo de servidor.

¿En qué idioma me atiende soporte?

En el tuyo. El soporte es humano y atiende en el idioma del cliente, español incluido, porque la plataforma traduce al vuelo.

Tu app, con tu nombre

Publicar con tu propio dominio es lo que convierte un experimento en un negocio serio. Registra tu dominio, publica tu app, apunta los DNS y espera unos minutos. Empieza gratis con Live Free y conecta tu dominio hoy: mira los planes de Dongee Live.

A la mayoría de las agencias digitales les conviene usar una nube gestionada para los sitios de sus clientes y dejar los servidores cloud propios (autogestionados) solo para los proyectos que exigen control total, siempre que alguien del equipo sepa administrarlos. En la práctica, el modelo más común y sostenible es el mixto: la operación del día a día queda en manos del proveedor, y la agencia conserva acceso root donde de verdad lo necesita.

La decisión no depende solo del precio mensual. También pesan las horas que tu equipo dedica a mantener servidores, la rapidez con la que se resuelve una caída y qué tanto depende la operación de una sola persona. En esta guía comparamos ambos modelos, te mostramos cómo calcular el costo real y te proponemos pasos concretos para decidir y migrar.

Qué significa cada opción

Antes de comparar, conviene tener claros los términos, porque «servidor propio» puede significar cosas distintas:

• Servidores propios: pueden ser hardware físico en la oficina o en un centro de datos (colocation), o servidores cloud/VPS autogestionados con acceso root. En los dos casos, la agencia administra el sistema operativo, la seguridad, los parches, los backups y el monitoreo. Si quieres profundizar en la diferencia entre hardware y virtualización, lee qué es mejor, un servidor físico o virtual.
• Nube gestionada: el proveedor administra el servidor, la seguridad, las actualizaciones, el monitoreo y los backups. La agencia se concentra en lo que factura: los sitios, las tiendas y las aplicaciones de sus clientes.

La diferencia de fondo es quién responde cuando algo falla a las 3 de la mañana. Con servidores propios responde tu equipo; con nube gestionada, el proveedor.

Tabla comparativa: servidores propios vs. nube gestionada

Cuándo conviene cada opción

Conviene gestionar servidores propios (cloud autogestionado) cuando…

• Desarrollas aplicaciones a medida que necesitan un stack específico: Node.js, Python, colas de trabajo, contenedores o versiones particulares de bases de datos.
• Un cliente exige acceso root, configuraciones no estándar o cumplir requisitos técnicos que un panel no permite.
• En el equipo hay al menos una persona con experiencia real en administración de servidores, y otra que pueda reemplazarla.
• Tienes procesos documentados de parches, backups y monitoreo, y no dependen de la memoria de alguien.
• El proyecto justifica cobrar al cliente un servicio de administración de infraestructura.

Conviene una nube gestionada cuando…

• La mayoría de tus proyectos son sitios WordPress, tiendas o sitios PHP que funcionan bien en un entorno estándar.
• Tu equipo es de diseño, desarrollo o marketing, y nadie tiene la administración de servidores como función principal.
• Manejas muchos clientes pequeños y medianos, y necesitas separar cuentas, accesos y facturación por cliente.
• Prefieres que las horas del equipo se facturen en proyectos y no se pierdan en mantenimiento.
• Necesitas soporte 24/7 y no tienes cómo cubrir guardias nocturnas o de fin de semana.

El servidor físico propio rara vez conviene a una agencia

Tener hardware en la oficina o en colocation implica comprar equipos, reemplazar piezas, asegurar energía y conectividad, y planear la capacidad con anticipación. Solo tiene sentido si existe una razón concreta, como un requisito contractual de un cliente o una inversión previa que todavía se está aprovechando.

El modelo mixto típico de una agencia

Casi ninguna agencia madura usa una sola opción. Lo habitual es repartir los proyectos según su nivel de criticidad y sus necesidades técnicas:

1. Sitios WordPress y PHP de clientes: en un hosting para agencias con cPanel y WHM, donde cada cliente tiene su propia cuenta separada. Así resuelves el volumen sin administrar servidores.
2. Clientes críticos (tiendas con ventas diarias, sitios corporativos con correo importante): en hosting gestionado empresarial, con recursos aislados, backups diarios y monitoreo permanente.
3. Aplicaciones a medida o proyectos que piden root: en servidores cloud autogestionados, administrados por la persona técnica del equipo.
4. Apps creadas con asistentes de IA (prototipos, herramientas internas, MVP de clientes): en una plataforma de publicación de apps, sin montar un servidor para cada una. Más detalles en plataformas para que una agencia publique apps hechas con IA.

Con este esquema, la agencia solo administra directamente lo que de verdad lo necesita, y el resto queda en entornos gestionados.

Cómo calcular el costo real

Comparar solo el precio del plan es el error más frecuente. Para cada opción, calcula este costo mensual:

Costo real = costo del plan + (horas de administración al mes × tarifa interna por hora) + costo esperado de una caída

• Costo del plan: lo que pagas al proveedor o, en hardware propio, la amortización de los equipos más el colocation, la energía y la conectividad.
• Horas de administración: registra durante uno o dos meses el tiempo real que tu equipo dedica a actualizaciones, revisión de backups, incidentes, configuración y consultas sobre el servidor. No lo estimes de memoria: mídelo.
• Tarifa interna: usa lo que cobrarías al cliente por esa hora, no solo el sueldo. Una hora dedicada al servidor es una hora que no se factura en un proyecto.
• Costo de una caída: piensa en las horas de diagnóstico, las ventas que pierde el cliente, posibles compensaciones y el riesgo de perder la cuenta. Multiplícalo por la probabilidad que veas realista con tu nivel actual de preparación.

Con estos datos de tu propia agencia, la comparación deja de ser intuitiva y se vuelve un número que puedes defender ante tus socios.

Pasos para decidir y migrar

1. Haz un inventario: lista cada proyecto con su tecnología, tráfico aproximado, si tiene correo asociado y qué tan crítico es para el cliente.
2. Clasifica por necesidad técnica: separa los que funcionan en un entorno estándar (WordPress/PHP) de los que requieren root o un stack especial.
3. Evalúa las capacidades del equipo: identifica quién sabe administrar servidores y si hay quien lo reemplace en vacaciones o si renuncia.
4. Calcula el costo real de la situación actual y del escenario propuesto con la fórmula anterior.
5. Define el destino de cada grupo: hosting de agencia, hosting gestionado empresarial, servidor cloud o plataforma de apps.
6. Migra primero un proyecto piloto de bajo riesgo para validar los tiempos, el proceso y el soporte del proveedor.
7. Planea las migraciones críticas en horarios de bajo tráfico, con backups verificados y bajando antes el TTL del DNS.
8. Documenta y comunica: deja registrados los accesos, las configuraciones y los responsables, y avisa a cada cliente del cambio y de sus beneficios.

Si tus clientes están en hosting compartido y estás evaluando el salto, revisa cuándo pasar de hosting compartido a un servidor en la nube administrado.

Errores comunes de las agencias

• Meter a todos los clientes en un solo servidor sin aislamiento: si un sitio queda comprometido o consume todos los recursos, afecta a los demás.
• Confiar en backups que nunca se han restaurado: un backup que no se ha probado no garantiza nada.
• Depender de un freelance o de un solo desarrollador que conoce las contraseñas y la configuración, sin documentación.
• Elegir por precio mensual sin contar las horas de administración ni el costo de una caída.
• Posponer actualizaciones de sistema, PHP o plugins por miedo a romper algo, lo que acumula vulnerabilidades.
• No cobrar la infraestructura al cliente o incluirla «gratis» en el mantenimiento, lo que con el tiempo se come el margen.
• Sobredimensionar desde el inicio en lugar de empezar con lo necesario y escalar cuando el proyecto lo pida.

Comparación honesta por tipo de opción

Dónde encaja Dongee

Dongee tiene una opción para cada parte del modelo mixto, con soporte 24/7 que te atiende en tu idioma gracias a la traducción en tiempo real de la plataforma:

• Hosting para Agencias: desde 68 USD/mes; reseller de marca blanca con cPanel y WHM para administrar por separado la cuenta de cada cliente, con alta disponibilidad, AccelerateWP para acelerar WordPress, Imunify360 incluido para la seguridad y soporte 24/7.
• Hosting Empresas: hosting gestionado desde 25 USD/mes (plan Zafiro), con recursos separados en contenedores, discos NVMe, migración gestionada de la web y los correos, backups diarios, monitoreo 24/7, uptime de 99,9 %, Imunify360 incluido, respuesta promedio de soporte en menos de 60 segundos y pago en monedas locales. Es la opción para los clientes críticos.
• Dongee Cloud: servidores con procesadores Intel Xeon desde 17 USD/mes (Cloud 1), acceso root, despliegue en menos de 3 minutos, SSD NVMe, uptime garantizado de 99,9 %, red privada entre instancias sin costo extra, snapshots, backup incluido en todos los planes, IP dedicada y soporte 24/7. Puedes escalar CPU, RAM y disco sin reiniciar ni migrar. Es autogestionado: tu equipo administra el sistema, aunque puedes pedir soporte y ayuda para migrar tu stack. Más información en servidor cloud escalable.
• Cloud On Demand: servidor a la medida, de 1 a 64 vCPU, de 1 a 256 GB de RAM y de 25 a 2.000 GB NVMe, con precio mensual según los recursos que elijas.
• Dongee Live: para publicar apps hechas con asistentes de IA como ChatGPT, Claude Code, Cursor o Lovable. Publica las aplicaciones, no despliega modelos de IA.

Además, el Equipo de Reacción Preventiva monitorea de forma proactiva, las 24 horas, CPU, RAM, disco y procesos: un ingeniero de guardia corrige los problemas y te avisa. Viene incluido en Hosting para Agencias (Reseller) y está disponible bajo solicitud para Cloud.

Preguntas frecuentes

¿Cuál es la diferencia principal entre gestionar servidores propios y usar una nube gestionada?

Quién se encarga de la operación. Con servidores propios, tu agencia administra el sistema operativo, la seguridad, los parches, los backups y el monitoreo. Con una nube gestionada, todo eso lo hace el proveedor y tu equipo se concentra en los sitios y las apps de los clientes.

¿Un VPS o servidor cloud cuenta como «servidor propio»?

Sí, en términos de responsabilidad. Aunque el hardware sea del proveedor, si el servidor es autogestionado y tienes acceso root, la administración del sistema y su seguridad corren por cuenta de tu agencia.

¿Es más barato tener servidores propios?

El precio mensual puede ser menor, pero el costo real incluye las horas de administración de tu equipo y el impacto de una caída. Calcula ambos con datos de tu propia agencia antes de concluir que es más barato.

¿Qué necesito para adquirir servidores cloud escalables para los proyectos de mi agencia?

Define qué proyectos necesitan root o un stack especial, estima los recursos iniciales, asegúrate de tener a alguien que administre el sistema y elige un proveedor que permita escalar CPU, RAM y disco sin migrar. En Dongee Cloud puedes escalar sin reiniciar y empezar desde 17 USD/mes.

¿Cómo separo a mis clientes para que un problema en un sitio no afecte a los demás?

Usa un hosting de agencia con WHM para crear una cuenta independiente por cliente o, para los clientes críticos, un hosting con recursos aislados en contenedores. En servidores autogestionados, tendrás que configurar el aislamiento tú mismo.

¿Puedo revender hosting a mis clientes?

Sí. Un plan reseller de marca blanca con cPanel y WHM te permite crear y cobrar una cuenta por cliente bajo tu propia marca, sin tener que operar la infraestructura.

¿Dónde publico las apps que mi agencia crea con asistentes de IA?

En una plataforma pensada para publicar este tipo de aplicaciones, como Dongee Live, que publica apps hechas con herramientas como ChatGPT, Claude Code, Cursor o Lovable. No necesitas montar un servidor para cada una.

¿Cómo migro los sitios de mis clientes sin afectarlos?

Empieza con un proyecto piloto, verifica los backups, baja el TTL del DNS antes del cambio y haz las migraciones críticas en horarios de bajo tráfico. Si eliges un plan con migración gestionada, como Hosting Empresas, el proveedor se encarga de trasladar la web y los correos.

El balanceo de carga tradicional reparte peticiones entre servidores idénticos para que ninguno se sature. El enrutamiento de modelos de IA decide qué modelo distinto debe responder cada petición según su contenido, costo, latencia o calidad esperada. El balanceador pregunta «¿qué copia está libre?». El enrutador pregunta «¿qué modelo conviene para esta tarea?». No compiten entre sí: una aplicación de IA bien diseñada usa los dos, cada uno en su capa.

Esta guía es para desarrolladores, líderes técnicos y equipos de producto en Latinoamérica que ya tienen o están construyendo servicios en línea con funciones de IA (chatbots, asistentes, clasificación de textos, generación de contenido) y quieren entender qué pieza de infraestructura resuelve cada problema. Si buscas profundizar, revisa también cómo funciona técnicamente el enrutamiento entre modelos en un chatbot, la comparativa de servicios para enrutar consultas entre modelos de lenguaje, la guía para optimizar el consumo de tokens con enrutadores de IA y el artículo sobre infraestructura cloud para escalar aplicaciones de IA.

Qué es el balanceo de carga tradicional

Un balanceador de carga es un componente que recibe el tráfico de los usuarios y lo distribuye entre varios servidores que ejecutan la misma aplicación. Su objetivo es que el servicio siga disponible y responda rápido aunque crezca el número de visitas o falle alguno de los servidores.

Capa 4 y capa 7

Los balanceadores trabajan en dos niveles del modelo de red:

• Capa 4 (transporte): decide con base en direcciones IP y puertos TCP/UDP. No lee el contenido de la petición, por eso es muy eficiente y sirve para casi cualquier protocolo.
• Capa 7 (aplicación): entiende HTTP. Puede leer la URL, los encabezados o las cookies y enviar, por ejemplo, las rutas /api a un grupo de servidores y las rutas /blog a otro.

Algoritmos de distribución más comunes

• Round robin: envía cada petición al siguiente servidor de la lista, en orden circular. Existe una variante ponderada que da más tráfico a los servidores con más capacidad.
• Least connections: elige el servidor que tiene menos conexiones activas en ese momento. Funciona mejor cuando las peticiones tienen duraciones muy distintas.
• IP hash y sesiones pegajosas: asocian a un usuario con el mismo servidor durante su sesión, ya sea calculando un hash de su IP o usando una cookie. Son útiles cuando la aplicación guarda el estado de la sesión en memoria local.

Health checks y réplicas idénticas

El balanceador revisa periódicamente cada servidor con health checks, que son peticiones de prueba a una ruta de salud o a un puerto. Si un servidor no responde, lo saca de la rotación hasta que se recupere. Todo esto parte de una premisa clave: los destinos son réplicas idénticas. Da igual cuál responda, porque todos ejecutan el mismo código y deben dar el mismo resultado.

Qué es el enrutamiento de modelos de IA

El enrutamiento de modelos es la lógica que decide qué modelo de IA atiende cada solicitud. A diferencia de las réplicas de un servidor web, los modelos no son iguales: unos son más rápidos, otros razonan mejor, otros cuestan menos por token y otros tienen ventanas de contexto más grandes. Por eso el enrutador tiene que mirar el contenido de la petición y no solo la carga de los servidores.

Estrategias de enrutamiento

• Reglas: condiciones explícitas en tu código. Por ejemplo: «si la tarea es clasificar un correo, usa un modelo pequeño y rápido; si es redactar un contrato, usa un modelo de mayor capacidad».
• Clasificador: un modelo ligero o un conjunto de heurísticas analiza la consulta y la etiqueta (simple, compleja, de código, de soporte) antes de elegir el modelo que la resolverá.
• Cascada: primero intentas con un modelo económico y, si la respuesta no pasa una validación (formato incorrecto, baja confianza, respuesta incompleta), escalas a un modelo más capaz.
• Fallback entre proveedores: si un modelo o proveedor devuelve error, se demora demasiado o alcanza su límite de uso, la petición se reenvía a una alternativa equivalente.
• Límites de tokens: el enrutador revisa el tamaño del contexto y la salida esperada para no enviar un documento largo a un modelo con ventana corta, o para impedir que una sola petición consuma un presupuesto excesivo.

Tabla comparativa: enrutamiento de modelos vs. balanceo de carga

Cómo trabajan juntos: arquitectura típica

En un servicio en línea con IA, ambos componentes conviven en capas diferentes. Un flujo habitual es este:

1. Usuario: abre tu app web o móvil y envía una pregunta.
2. CDN y balanceador: la CDN entrega los archivos estáticos desde caché y filtra ataques. El balanceador recibe las peticiones dinámicas y las reparte entre tus servidores de aplicación.
3. Réplicas de tu app: varias instancias idénticas de tu backend autentican al usuario, aplican límites de uso y preparan el prompt.
4. Enrutador de modelos: dentro de tu backend o en un servicio aparte, decide qué modelo usar según la tarea, el presupuesto y la latencia aceptable.
5. Modelos: el modelo elegido responde y la respuesta vuelve por el mismo camino hasta el usuario.

El balanceador protege la disponibilidad de tu aplicación. El enrutador optimiza la llamada a la IA. Si solo tienes el primero, tu app aguanta el tráfico pero quizá pagas un modelo caro para tareas triviales. Si solo tienes el segundo, eliges bien el modelo, pero un pico de visitas puede tumbar tu único servidor.

Ventajas de implementar enrutamiento de modelos en tu infraestructura

• Mejor rendimiento percibido: las consultas simples van a modelos rápidos y el usuario recibe respuesta antes. Los modelos lentos y potentes quedan reservados para lo que de verdad los necesita.
• Menor costo por consulta: no todas las preguntas requieren el modelo más grande. Enviar las tareas sencillas a modelos económicos reduce el gasto en tokens sin sacrificar calidad donde importa.
• Resiliencia: con fallback, la caída o saturación de un proveedor no deja tu servicio sin respuesta.
• Control de gasto: los límites de tokens por petición, por usuario o por clave evitan sorpresas en la factura y frenan abusos.
• Flexibilidad: cambiar de modelo o probar uno nuevo se vuelve un ajuste de configuración y no una reescritura de la aplicación.
• Observabilidad: al centralizar las llamadas, ves qué modelo se usa, cuánto consume y dónde están los errores.

Pasos para implementar enrutamiento de modelos

1. Inventaría tus casos de uso. Haz una lista de las tareas que tu app le pide a la IA (resumir, clasificar, responder soporte, generar código) y anota qué calidad y qué velocidad necesita cada una.
2. Elige un punto de acceso unificado. Usar una API que dé acceso a varios modelos con una sola clave simplifica mucho el código, porque cambiar de modelo se reduce a cambiar un parámetro.
3. Define reglas iniciales simples. Empieza con un mapa «tarea → modelo» en tu backend. Las reglas claras son fáciles de depurar y de explicar al equipo.
4. Agrega fallback. Para cada modelo principal, define una alternativa y las condiciones de cambio: error del servidor, tiempo de espera excedido o límite alcanzado.
5. Pon límites de tokens y presupuesto. Limita el tamaño máximo del contexto y de la salida, y define topes por usuario o por clave.
6. Mide antes de sofisticar. Registra por modelo el consumo, los errores y la satisfacción del usuario. Solo cuando tengas datos tiene sentido introducir un clasificador o una cascada.
7. Protege las claves. Guárdalas en variables de entorno del servidor, nunca en el navegador ni en la app móvil, y limita cada clave a los modelos que realmente usa.
8. Escala la capa web por separado. Cuando el tráfico crezca, agrega réplicas de tu app detrás de un balanceador. El enrutador de modelos no reemplaza esa capa.

Errores comunes

• Creer que un balanceador elige modelos. Un proxy en capa 7 puede enviar rutas a destinos distintos, pero no entiende si una consulta es simple o compleja. Esa decisión pertenece a la lógica de la aplicación.
• Tratar los modelos como réplicas. Repartir en round robin entre modelos distintos produce respuestas inconsistentes: el mismo usuario recibe estilos y niveles de calidad diferentes sin ningún motivo.
• Usar el modelo más grande para todo. Es la forma más rápida de inflar costos y latencia.
• Fallback sin validación. Cambiar a otro modelo sin revisar que la respuesta cumpla el formato esperado (por ejemplo, un JSON válido) puede romper tu aplicación.
• Exponer claves de API en el frontend. Cualquiera puede copiarlas y consumir tu saldo.
• No registrar qué modelo respondió. Sin ese dato no puedes depurar errores ni optimizar costos.
• Sobrediseñar desde el primer día. Un clasificador entrenado tiene poco sentido si todavía no sabes qué tipos de consultas recibes.

Qué tipo de opción elegir

Balanceador de nube o proxy inverso tipo Nginx o HAProxy

Resuelve la distribución de tráfico web entre réplicas de tu aplicación, la terminación TLS y los health checks. Conviene siempre que tengas más de una instancia de tu backend o necesites alta disponibilidad. No sirve para elegir modelos de IA según el contenido.

Gateway o enrutador de IA gestionado

Un servicio externo que ofrece una API unificada para varios modelos y, según el proveedor, funciones de enrutamiento, registro y control de gasto. Conviene cuando quieres acceso a varios modelos sin mantener integraciones separadas. Revisa con cuidado qué hace de forma automática y qué te toca programar a ti.

Enrutador propio en tu código

Una capa de lógica en tu backend con reglas, cascada y fallback. Te da control total y es la opción natural cuando tus criterios dependen del negocio (tipo de cliente, plan contratado, idioma). Exige mantenimiento y buena observabilidad. Suele combinarse con una API unificada para no integrar cada proveedor por separado.

API directa de un solo proveedor

Es la opción más simple para prototipos o productos con un único caso de uso. Su debilidad es la dependencia: si ese proveedor falla o cambia condiciones, no tienes alternativa inmediata, y pagas el mismo precio por tareas simples y complejas.

Dónde encaja Dongee

En Dongee encuentras piezas para las dos capas; conviene ser preciso sobre qué hace cada producto y qué configuras tú:

• Dongee AI Router es una API unificada para varios modelos de IA, con prioridad en modelos rápidos alojados en el data center de Dongee en Canadá. Usas una sola clave y funciona en prepago desde 3 USD, sin mensualidad. Las cuentas nuevas reciben 3 USD de crédito gratis. También es compatible con el estándar OpenAI: si tu código usa esa API o una librería compatible, cambias la URL base y la clave. AI Router no elige el modelo por ti. La lógica de reglas, cascada y fallback la programas tú en tu aplicación, y la API unificada te permite cambiar de modelo con un parámetro. Si se acaba el saldo, las peticiones se detienen hasta que recargues, sin deuda ni cobros automáticos. No guarda conversaciones, solo los datos de facturación de cada petición. Puedes ver el consumo por modelo, por clave y el detalle de cada petición. Se activa desde el área de cliente.
• Dongee Cloud ofrece servidores Intel Xeon con acceso root, SSD NVMe, IP dedicada, snapshots, backup incluido y red privada entre instancias sin costo extra, desde 17 USD/mes. En estos servidores puedes montar tu propio balanceador con Nginx o HAProxy y conectar varias instancias de tu app por la red privada. Tú configuras y administras esa arquitectura, con soporte 24/7 y asistencia de migración. Puedes escalar CPU, RAM y disco sin reiniciar ni migrar.
• Cloud On Demand sirve si necesitas un servidor a medida: de 1 a 64 vCPU, de 1 a 256 GB de RAM y de 25 a 2.000 GB NVMe, con precio mensual por recurso.
• Hosting Empresas es la opción gestionada si prefieres no administrar servidores: recursos separados en contenedores, monitoreo 24/7 y uptime de 99,9 %, desde 25 USD/mes.
• Dongee CDN pone caché en nodos globales y protección DDoS 24/7 delante de tu app. Tiene un plan gratis de 1 GB.

Una combinación típica: Dongee CDN delante, dos o más instancias de Dongee Cloud con tu balanceador Nginx y tu backend, y en ese backend tu lógica de enrutamiento llamando a Dongee AI Router. El soporte te atiende en tu idioma porque la plataforma traduce las conversaciones al vuelo.

Preguntas frecuentes

¿El enrutamiento de modelos de IA reemplaza al balanceador de carga?

No. El balanceador reparte el tráfico entre las réplicas de tu aplicación y la mantiene disponible. El enrutador decide qué modelo responde cada consulta. Trabajan en capas distintas y lo habitual es usar ambos.

¿Puedo usar Nginx o HAProxy para enrutar entre modelos de IA?

Puedes enviar rutas o encabezados a destinos distintos, pero estas herramientas no analizan el significado del prompt ni consideran costo por token o calidad. Para eso necesitas lógica en tu aplicación o un servicio diseñado para trabajar con modelos.

¿Qué es una cascada de modelos?

Es una estrategia en la que primero intentas responder con un modelo económico y rápido. Solo si la respuesta no pasa una validación escalas a un modelo más potente. Así reservas el modelo caro para los casos que lo necesitan.

¿Qué diferencia hay entre fallback y balanceo?

El balanceo reparte tráfico de forma continua entre destinos iguales. El fallback solo se activa cuando el destino principal falla y envía la petición a una alternativa que puede ser un modelo diferente, con resultados distintos.

¿Cómo mantengo el contexto si cambio de modelo en medio de una conversación?

En las APIs de modelos de lenguaje, el historial de la conversación se envía en cada petición. Si guardas ese historial en tu backend o en tu base de datos, cualquier modelo puede continuar la conversación, siempre que el contexto quepa en su ventana de tokens.

¿Dongee AI Router elige automáticamente el mejor modelo?

No. AI Router te da una API unificada para varios modelos con una sola clave. Las reglas de enrutamiento, la cascada y el fallback los programas tú en tu aplicación, eligiendo el modelo en cada llamada.

¿Puedo usar mi código actual compatible con OpenAI?

Sí. Si tu aplicación usa la API de OpenAI o una librería compatible, basta con cambiar la URL base y la clave por las de Dongee AI Router.

¿Dónde debo guardar las claves de API de los modelos?

Siempre en el servidor, por ejemplo en variables de entorno, nunca en el navegador ni en apps móviles. Además, limita cada clave a los modelos que necesita, para reducir el impacto si alguna se filtra.

Una app de Next.js hecha con Bolt o v0 se puede publicar en Dongee Live conectando su repositorio de GitHub: Live acepta Next.js en modo standalone (output: 'standalone') con renderizado en el servidor, y cada push se publica solo. Para que la app envíe correos por SMTP, el envío debe hacerse siempre desde el servidor (Route Handler o Server Action), con las credenciales SMTP fuera del código del navegador y un servicio de envío transaccional con SPF y DKIM, como MailChannels SMTP de Dongee.

Bolt y v0 generan muy rápido una app en Next.js con formularios de contacto, registro de usuarios o recuperación de contraseña. Ahí aparece la pregunta que muchos equipos de México, Colombia, Perú y el resto de Hispanoamérica se hacen: ¿dónde la publico para que funcione con mi dominio y, además, mande correos sin caer en spam? En esta guía les explicamos qué necesita técnicamente una app así, cómo publicarla paso a paso en Dongee Live, qué alternativas existen y qué revisar en cada una.

Importante: Dongee Live publica apps hechas con herramientas de IA (sitios estáticos y apps Node.js). No despliega ni hospeda modelos de inteligencia artificial.

Qué necesita una app de Next.js que envía correos

Antes de elegir dónde publicarla, conviene tener claro qué piezas intervienen:

• Un entorno que ejecute Node.js en el servidor. El envío por SMTP (por ejemplo con la librería Nodemailer) necesita el runtime de Node.js; no funciona desde el navegador ni en el runtime Edge de Next.js.
• Credenciales SMTP guardadas como secretos. Servidor, puerto, usuario y contraseña deben vivir en variables de entorno del servidor. En Next.js, cualquier variable con el prefijo NEXT_PUBLIC_ termina en el código que descarga el visitante, así que nunca deben usar ese prefijo para la clave SMTP.
• Un servicio de envío con buena reputación. Los correos transaccionales (confirmaciones, facturas, recuperación de contraseña) llegan a la bandeja de entrada cuando salen autenticados con SPF y DKIM desde IPs con buena reputación.
• Un dominio propio con DNS bien configurado. Los registros SPF, DKIM y DMARC del dominio son los que permiten que Gmail, Outlook y Yahoo confíen en sus mensajes.
• Base de datos, si la app guarda usuarios o pedidos. Muchas apps generadas con IA la necesitan desde el primer día.

Cómo publicar la app de Bolt o v0 en Dongee Live, paso a paso

1. Lleven el proyecto a GitHub. Desde Bolt o v0, exporten o sincronicen el proyecto con un repositorio de GitHub. Dongee Live trabaja con ese repositorio: la compilación se hace en GitHub y cada push se publica solo.
2. Activen el modo standalone de Next.js. En next.config.js (o next.config.mjs/.ts) agreguen output: 'standalone'. Así Next.js genera un servidor Node.js autónomo, que es el formato que Dongee Live acepta, con renderizado en el servidor.
3. Verifiquen la versión de Node.js. Dongee Live corre sobre Node.js 20, 22 o 24. Si el proyecto fija otra versión en package.json (campo engines), ajústenla.
4. Muevan el envío de correos al servidor. Pidan a Bolt, v0 o a su asistente de código que el formulario llame a un Route Handler (por ejemplo app/api/contacto/route.ts) o a una Server Action, y que ahí se haga el envío con Nodemailer. Si el archivo declara runtime, que sea export const runtime = 'nodejs', no 'edge'.
5. Saquen las credenciales del código. Reemplacen cualquier usuario o clave escritos a mano por variables como SMTP_HOST, SMTP_PORT, SMTP_USER y SMTP_PASS, sin prefijo NEXT_PUBLIC_, y revisen que el archivo .env no quede subido a GitHub. En Dongee Live, esos valores se cargan como variables de entorno propias de la app, junto a DATABASE_URL.
6. Elijan el servicio de envío. Para correo transaccional, Dongee ofrece MailChannels SMTP, un relay SMTP que envía cada mensaje desde IPs certificadas y rotativas, autenticado con SPF y DKIM y encriptado, y que escanea cada envío en tiempo real. Es ideal para confirmaciones, facturas y recuperación de contraseña, y se puede contratar aparte para usarlo desde una app de Live. Las apps de Live pueden conectarse por SMTP saliente en los puertos 587 (STARTTLS) y 465 (SSL/TLS). Si prefieren otro proveedor de correo transaccional, el procedimiento es el mismo: obtienen servidor, puerto y credenciales, y los cargan como variables.
7. Configuren el DNS del dominio. Publiquen los registros SPF y DKIM que indique su servicio de envío y agreguen un registro DMARC. Con Live Gratis pueden usar un dominio gratis con DNS de Cloudflare.
8. Conecten el repositorio a Dongee Live y publiquen. Elijan un plan en Dongee Live, conecten el repositorio de GitHub y hagan push. Tengan en cuenta que cada subida desde GitHub admite hasta 32 MB.
9. Prueben el flujo completo. Envíen el formulario desde la app publicada, revisen que el correo llegue a Gmail y a Outlook, y abran los encabezados del mensaje para confirmar que SPF y DKIM aparecen como «pass».

Si la app guarda datos, cada app de Dongee Live incluye una base de datos MySQL disponible en la variable DATABASE_URL. Live no incluye Postgres ni MongoDB, así que si Bolt o v0 generaron el proyecto con otra base de datos, pidan al asistente que lo adapte a MySQL. Si trabajan con Claude Code, Codex o Cursor, también pueden publicar con el conector MCP de Dongee Live; lo explicamos en cómo publicar desde Claude Code o Cursor una app en Node.js con MySQL.

El correo incluido en Live no es lo mismo que un SMTP transaccional

Dongee Live incluye correo con el dominio de su plan (Live Gratis trae 1 cuenta), pensado para usarlo por webmail o IMAP: leer y responder mensajes de su negocio. No es para envíos masivos. Es una cuenta de correo normal, con los límites de envío habituales de cualquier buzón: la app puede usarla por SMTP para pocos envíos, pero para correo transaccional o mayor volumen recomendamos MailChannels SMTP. Por eso conviene separar dos usos:

• Buzón de la empresa (contacto@sudominio.com): para comunicarse con clientes. Es el correo que incluye Live; si necesitan buzones más grandes y más cuentas, existe Dongee Prime Email.
• Envíos automáticos de la app (confirmaciones, notificaciones, restablecimiento de contraseña): conviene que salgan por un servicio SMTP transaccional, como MailChannels SMTP, para cuidar la reputación del dominio.

Si quieren entender mejor los protocolos, en la diferencia entre SMTP, POP e IMAP lo explicamos con ejemplos, y en qué es MailChannels y cómo funciona verán cómo trabaja un relay SMTP.

Comparativa honesta: dónde publicar una app de Next.js que envía correos

No existe una única respuesta correcta. Esta tabla compara los tipos de opción más comunes, sin precios de terceros porque cambian con frecuencia: revísenlos en el sitio de cada proveedor.

Si su proyecto crece hasta necesitar procesos en segundo plano, colas de correo propias u otros lenguajes, el siguiente paso natural es un servidor en Dongee Cloud, donde se puede subir CPU, RAM y disco sin reiniciar ni migrar, con backup incluido en todos los planes. Cloud es autogestionado (ustedes administran el sistema) y cuenta con soporte y asistencia para migrar. Para comparar más plataformas, lean alternativas a Vercel, Railway o Render para apps hechas con IA.

Planes de Dongee Live

• Live Gratis (0 USD): 1 app, 1 base de datos MySQL y 1 correo; permite uso comercial con términos de uso razonable y dominio gratis con DNS de Cloudflare.
• Live Pro (15 USD/mes): hasta 3 apps.
• Live Team (29 USD/mes): hasta 10 apps.

Vean el detalle actualizado en la página de planes de Dongee Live. Si todavía están evaluando si un plan gratis les sirve para un negocio, revisen si hay hosting gratis con uso comercial para apps hechas con IA.

Errores comunes al publicar una app de Next.js que envía correos

• Enviar el correo desde el navegador. Expone las credenciales y no funciona con SMTP. El envío va siempre en el servidor.
• Usar NEXT_PUBLIC_ para la clave SMTP. La clave queda visible para cualquier visitante.
• Subir el archivo .env a GitHub. Agréguenlo a .gitignore y cambien la clave si ya se subió.
• Olvidar SPF, DKIM y DMARC. Es la causa más frecuente de que los correos lleguen a spam.
• Usar el buzón de la empresa para envíos masivos. Ponen en riesgo la reputación del dominio; para volumen usen un SMTP transaccional.
• No limitar el formulario. Un formulario de contacto sin validación ni límite de intentos puede usarse para enviar spam desde su dominio. Revisen también qué necesita una app hecha con IA para ser segura y no caerse.

Preguntas frecuentes

¿Dongee Live funciona con Next.js?

Sí, en modo standalone (output: 'standalone'), con renderizado en el servidor, sobre Node.js 20, 22 o 24.

¿Puedo publicar en Dongee Live lo que hice con Bolt o v0?

Sí. Conecten el repositorio de GitHub de su proyecto de Bolt o v0 y cada push se publica solo en Dongee Live. La compilación se hace en GitHub.

¿Desde dónde debe enviar los correos mi app de Next.js?

Desde el servidor: un Route Handler o una Server Action con runtime de Node.js. Nunca desde el código del navegador ni con credenciales en variables NEXT_PUBLIC_.

¿El correo que incluye Dongee Live sirve para enviar correos masivos?

No. El correo incluido es una cuenta de correo normal con el dominio de su plan, con los límites de envío habituales. Puede servir para pocos envíos de la app por SMTP, pero para correos transaccionales o mayor volumen conviene un servicio SMTP transaccional como MailChannels SMTP.

¿Mi app en Dongee Live puede enviar correos por SMTP?

Sí. Las apps de Live pueden definir sus propias variables de entorno (por ejemplo SMTP_HOST, SMTP_PORT, SMTP_USER y SMTP_PASS) y conectarse por SMTP saliente en los puertos 587 y 465. MailChannels SMTP contratado aparte funciona desde una app de Live.

¿Qué es MailChannels SMTP y cuándo lo necesito?

Es el relay SMTP de Dongee: envía cada correo desde IPs certificadas y rotativas, con SPF, DKIM y encriptación, y escanea los envíos en tiempo real. Es útil cuando su app manda confirmaciones, facturas o recuperaciones de contraseña y necesitan que lleguen a la bandeja de entrada. Viene incluido en el hosting compartido de Dongee y también se puede contratar aparte para usarlo desde una app de Dongee Live.

¿Qué base de datos puedo usar con mi app de Next.js en Dongee Live?

MySQL. Cada app incluye una base de datos MySQL disponible en la variable DATABASE_URL. No incluye Postgres ni MongoDB.

¿Puedo usar Dongee Live Gratis para una app comercial?

Sí. Live Gratis permite uso comercial con términos de uso razonable e incluye 1 app, 1 base de datos MySQL y 1 correo.

¿Dongee Live sirve para desplegar modelos de IA?

No. Dongee Live publica apps y sitios creados con herramientas de IA, como Bolt, v0, Lovable, ChatGPT, Claude Code o Cursor. No hospeda ni ejecuta modelos de inteligencia artificial.

¿Qué tamaño máximo puede tener cada publicación?

Hasta 32 MB por subida desde GitHub y hasta 100 MB por publicación desde el conector MCP.

Los mejores servidores en la nube para una empresa en México, Perú o cualquier país de Latinoamérica son los que combinan un centro de datos cercano a tus clientes, precio mensual fijo en dólares, backups incluidos y soporte 24/7 que permita comunicarse en español. Antes de elegir, decide si tu equipo va a administrar el servidor (cloud autogestionado con acceso root) o si prefieres que el proveedor lo haga por ti (hosting gestionado empresarial). En Dongee, la primera opción es Dongee Cloud desde 17 USD al mes y la segunda es Hosting Empresas desde 25 USD al mes.

Esta guía es para gerentes, responsables de TI y dueños de negocio de México, Perú, Colombia, Chile, Argentina y el resto de Hispanoamérica que necesitan mover su sistema, su sitio o su aplicación a la nube y quieren que, cuando algo falle, puedan comunicarse con soporte en su idioma.

Por qué el soporte en español pesa tanto en un servidor empresarial

En un servidor en la nube, el hardware rara vez es el problema. Lo difícil llega cuando una actualización rompe algo, cuando un certificado vence o cuando la base de datos se llena un viernes por la noche. En ese momento importa menos la marca del proveedor y más tres cosas:

• Que te respondan rápido, a cualquier hora, sin abrir un ticket que se contesta en dos días.
• Que te respondan en tu idioma, para que tu equipo entienda la solución y no pierda tiempo traduciendo documentación.
• Que el soporte esté incluido en el plan y no sea un paquete aparte que se paga por horas.

Muchas nubes globales tienen documentación excelente, pero el soporte técnico humano suele ser un plan de pago adicional y, en muchos casos, en inglés. Para una empresa sin un equipo de infraestructura grande, esa diferencia pesa más que unos dólares en la factura.

Cómo elegir un servidor en la nube para tu empresa: 8 pasos

1. Define quién va a administrar el servidor. Si tienes a alguien que maneje Linux, SSH y actualizaciones, un cloud autogestionado con acceso root te da control total. Si no, un hosting gestionado empresarial te quita esa carga.
2. Haz la lista de lo que vas a correr. Sitio web, tienda, ERP, CRM, base de datos, correo, aplicaciones internas o APIs. Cada servicio pide CPU, RAM y disco distintos.
3. Elige la región por tus clientes. Busca un centro de datos lo más cerca posible de quienes usan tu sistema. Para México hay opciones en el propio país y en el sur de Estados Unidos; para Perú y el resto de Sudamérica, las más cercanas suelen estar en São Paulo, Santiago de Chile o Miami.
4. Pide el SLA por escrito. Revisa qué uptime garantiza el proveedor, qué pasa si no lo cumple y si la red es redundante.
5. Revisa backups y recuperación. Pregunta si los backups vienen incluidos, con qué frecuencia se hacen, dónde se guardan y cuánto tarda una restauración. Haz una restauración de prueba antes de que la necesites.
6. Confirma cómo se escala. Lo ideal es poder subir CPU, RAM y disco sin reiniciar ni migrar, y conectar varios servidores por red privada cuando crezcas.
7. Pide ayuda para migrar. Una mudanza mal hecha puede dejar tu sistema caído un día entero. Pregunta si el proveedor te acompaña en la migración y si se hace en horario de baja actividad.
8. Prueba el soporte antes de firmar. Escribe una pregunta técnica real un domingo o de madrugada. Fíjate si te responde una persona, en español y con una solución concreta.

Comparación honesta: tipos de servidores en la nube para empresas

No hay una opción mejor para todos. Esta tabla compara los tipos de servicio más comunes, sin precios de terceros, para que ubiques tu caso:

Si todavía estás en hosting compartido y no sabes si ya es momento de dar el salto, revisa cuándo conviene pasar de hosting compartido a un servidor en la nube administrado.

Cómo se ve en Dongee

Dongee tiene dos caminos para empresas, según quién quieras que administre el servidor.

Dongee Cloud: tu propio servidor, administrado por tu equipo

Dongee Cloud es un servidor en la nube con procesadores Intel Xeon y acceso root completo que se despliega en menos de 3 minutos. Según su página, incluye 99,9 % de uptime garantizado, SSD NVMe, red privada entre tus instancias sin costo extra, snapshots, panel de control, IP dedicada y soporte 24/7. El backup está incluido en todos los planes y puedes subir CPU, RAM y disco sin reiniciar ni migrar.

El soporte de Dongee Cloud está disponible 24/7 en cualquier idioma mediante traducción al vuelo de la plataforma, incluido el español. La comunicación se apoya en esa traducción; no significa que cada agente humano domine todos los idiomas.

Está disponible en Atlanta, Miami, NY, Dallas, México, São Paulo, Santiago de Chile, Frankfurt, Madrid, Londres y Amsterdam. Para una empresa en México, la región de México es la opción natural; para una empresa en Perú, Colombia o el resto de Sudamérica, conviene comparar São Paulo, Santiago de Chile y Miami según dónde estén tus usuarios.

Dongee Cloud es autogestionado: tu equipo administra el sistema con control total y, si algo se complica, puede pedir ayuda al soporte. Si ya tienes servidores en otro proveedor, hay asistencia técnica para migrar tu stack.

Si ningún plan fijo encaja con tu carga, Cloud On Demand te deja armar el servidor por recurso: 6 USD por vCPU, 3 USD por GB de RAM y 0,3 USD por GB de disco, con un mínimo de 17 USD al mes. Por ejemplo, 4 vCPU, 8 GB de RAM y 100 GB de disco cuestan 78 USD al mes. Para archivos, respaldos y datos de gran tamaño está el almacenamiento S3 de Dongee.

Hosting Empresas: que Dongee administre por ti

Si tu empresa no tiene a nadie que administre servidores, el Hosting Empresas es alojamiento gestionado con recursos separados en contenedores y sin sobreventa, migración gestionada de web y correos, backups diarios, monitoreo 24/7 y soporte 24/7 en español con respuesta promedio en menos de 60 segundos.

El precio mensual es el mismo pagando 1, 3, 6, 12, 24 o 36 meses, y el plan de 12 meses incluye 1 dominio. Todos los planes incluyen Dongee Live, Cloudflare y 30 días de garantía. Puedes pagar en dólares o en tu moneda local, con tarjeta, transferencia, efectivo referenciado o criptomonedas, y la facturación está adaptada a la contabilidad empresarial. Si quieres el detalle de cómo funciona el soporte, lo explicamos en cómo contratar hosting empresarial con soporte humano 24/7 en español.

¿Cuál de los dos elegir?

• Elige Dongee Cloud si tienes un equipo técnico que quiere acceso root, instalar su propio software (Docker, bases de datos, ERP, aplicaciones a medida) y diseñar su red privada.
• Elige Hosting Empresas si tu prioridad es que el sitio, la tienda o el correo no se caigan y que otro se ocupe de backups, seguridad y migración.

Errores comunes al contratar un servidor en la nube para una empresa

• Comprar más servidor del que necesitas. Empieza con lo que tu carga pide hoy y escala cuando las métricas lo indiquen.
• Elegir la región por precio y no por cercanía. Un servidor lejos de tus clientes hace más lenta cada página y cada consulta.
• Dar por hecho que hay backups. Confirma que están incluidos y prueba una restauración.
• Contratar cloud autogestionado sin nadie que lo administre. Si no tienes equipo de TI, un servicio gestionado te sale más barato que un incidente.
• Ignorar la facturación. Los cobros por consumo pueden subir sin aviso; un precio mensual fijo es más fácil de presupuestar.
• No probar el soporte. Descubrir a las 3 de la mañana que el soporte es solo por correo y en inglés sale caro.

Si buscas infraestructura para un producto que recién arranca, también te puede servir qué servidor cloud escalable conviene para una startup en Latinoamérica. Y si estás comparando proveedores de hosting por país, tenemos guías para México y Perú.

Preguntas frecuentes

¿Dongee tiene servidores en la nube en México?

Sí. Dongee Cloud está disponible en México, además de Atlanta, Miami, NY, Dallas, São Paulo, Santiago de Chile, Frankfurt, Madrid, Londres y Amsterdam.

¿Y si mi empresa está en Perú?

Dongee Cloud no lista una región en Perú. Las más cercanas para Sudamérica son São Paulo y Santiago de Chile, y Miami es otra opción común. Elige según dónde estén la mayoría de tus usuarios.

¿El soporte de Dongee Cloud es en español?

Sí. Dongee Cloud incluye soporte 24/7 en cualquier idioma mediante traducción al vuelo de la plataforma, por lo que puedes comunicarte en español. Esto no implica que cada agente humano domine todos los idiomas. Como Cloud es autogestionado, el día a día del sistema lo maneja tu equipo, pero puedes pedir ayuda al soporte cuando lo necesites.

¿Cuánto cuesta un servidor en la nube para empresas en Dongee?

Dongee Cloud va de 17 USD al mes (Cloud 1) a 1.088 USD al mes (Cloud 7). Con Cloud On Demand armas el tuyo desde 17 USD al mes. Si prefieres un servicio gestionado, Hosting Empresas va de 25 a 76 USD al mes.

¿Los planes de Dongee Cloud incluyen backup?

Sí, el backup está incluido en todos los planes de Dongee Cloud, además de snapshots.

¿Puedo crecer sin migrar a otro servidor?

Sí. En Dongee Cloud puedes subir CPU, RAM y disco sin reiniciar ni migrar, y conectar varias instancias por red privada sin costo extra.

¿Me ayudan a migrar desde mi proveedor actual?

Sí. En Dongee Cloud hay asistencia técnica para migrar tu stack. En Hosting Empresas, el equipo de Dongee migra tu web y tus correos con una ventana controlada, sin parar el negocio.

¿Qué diferencia hay entre Dongee Cloud y Hosting Empresas?

Dongee Cloud es tu propio servidor con acceso root, administrado por tu equipo. Hosting Empresas es alojamiento gestionado: Dongee se encarga de backups, monitoreo, seguridad y migración, sin que tengas que administrar servidores.

Las mejores opciones de infraestructura cloud para escalar aplicaciones de IA son las que separan tres piezas: el servidor donde corre tu app o backend, el acceso a los modelos por API y, si aplica, la plataforma donde publicas la app que hiciste con herramientas de IA. No necesitas GPU en tu propio servidor si los modelos viven en una API: lo que escalas es CPU, RAM, disco y el gasto en tokens. En Dongee esa separación se ve como Dongee Cloud (o Cloud On Demand) + AI Router +, cuando publicas una app Node.js/MySQL hecha con IA, Dongee Live.

Esta guía es para equipos de México, Perú, Colombia, Chile, Argentina y el resto de Hispanoamérica que ya tienen (o van a tener) un chatbot, un agente, un SaaS o una API que llama a modelos de lenguaje y necesitan crecer sin rehacer todo el stack ni abrir una factura de nube global imposible de prever.

Qué significa «escalar una aplicación de IA»

Aquí «aplicación de IA» no quiere decir entrenar un modelo propio ni alojar pesos en una GPU. Quiere decir una app que usa inteligencia artificial: un chatbot de soporte, un agente interno, un flujo que resume documentos, un producto hecho con Lovable, ChatGPT, Claude Code o Cursor que llama a modelos por API.

Escalar esa app implica tres ejes distintos:

• Infraestructura de la app: más CPU, RAM y disco (o más instancias) para el backend, la base de datos y los workers.
• Consumo de modelos: más peticiones a la API de lenguaje; ahí el cuello de botella suele ser el costo por token y el tope de gasto, no el hardware local.
• Publicación y operación: cómo despliegas, monitores y recuperas la app cuando hay más usuarios.

Si confundes esos tres ejes, terminas pagando GPU que no usas o una plataforma «todo en uno» que no controlas. Dongee Cloud usa procesadores Intel Xeon y no incluye GPU NVIDIA: está pensado para correr tu app y tu backend, no para entrenar modelos.

Cómo elegir infraestructura cloud para escalar tu app de IA: 8 pasos

1. Separa app y modelo. La app vive en tu servidor o PaaS; el modelo vive en una API. Si no vas a entrenar ni a servir un modelo local, no busques GPU.
2. Mide la carga real de la app. Revisa CPU, RAM, conexiones a la base de datos y colas. Un pico de usuarios que chatean no es lo mismo que un pico de tokens: uno se resuelve con más servidor; el otro, con más saldo o mejor enrutamiento.
3. Elige región por tus usuarios. Menos distancia, menos latencia en cada clic. Dongee Cloud tiene disponibilidad en México, São Paulo, Santiago, Miami y otras ciudades de América y Europa.
4. Decide si quieres root o no. Con acceso root instalas Docker, workers, agentes y lo que tu stack pida. Si no tienes quien administre el servidor, mira hosting gestionado empresarial en lugar de cloud autogestionado.
5. Planifica el escalado vertical y horizontal. Vertical = subir CPU/RAM/disco al mismo servidor. Horizontal = agregar más instancias (por ejemplo app y base de datos separadas) unidas por red privada.
6. Pon tope al gasto en modelos. Prefiere prepago o límites diarios. Un bucle en el código o un abuso de la clave puede vaciar un saldo de API en minutos si no hay freno.
7. Exige backups y un plan de recuperación. Snapshots y backups desde el día uno; prueba al menos una restauración.
8. Prueba el soporte en español antes de depender de él. Cuando un agente en producción falla a las 2 a. m., necesitas a alguien que entienda tu stack y te responda en tu idioma.

Comparación honesta por tipo de infraestructura

Sin inventar precios ajenos: lo que cambia de verdad es el tipo de servicio. Usa esta tabla para ubicar tu caso.

Si todavía estás eligiendo servidor para una startup en general (sin el ángulo IA), mira qué servidor cloud escalable conviene para una startup. Si lo que buscas es cómo «integrar» herramientas de IA en un servidor, la guía hermana es servidores en la nube con herramientas de IA.

Cómo se ve el stack en Dongee

La idea es combinar solo las piezas que tu etapa necesita.

1) Dongee Cloud: el servidor de la app y del backend

Dongee Cloud es un servidor cloud con procesadores Intel Xeon y acceso root completo. Se despliega en menos de 3 minutos, incluye 99,9 % de uptime garantizado, SSD NVMe, red privada entre tus instancias sin costo extra, snapshots, panel de control, IP dedicada y soporte 24/7. El backup está incluido en todos los planes. Puedes subir CPU, RAM y disco sin reiniciar ni migrar. Es autogestionado: tu equipo administra el sistema; si te trabas, hay asistencia para migrar el stack.

Para un MVP de chatbot o API pequeña suelen bastar Cloud 2 o 3. Cuando la app ya sostiene clientes o workers pesados, subes a Cloud 4 o más, o separas app y base de datos en dos instancias con red privada.

2) Cloud On Demand: cuando el plan fijo no encaja

Cloud On Demand te deja elegir de 1 a 64 vCPU, de 1 a 256 GB de RAM y de 25 a 2.000 GB de SSD NVMe. El precio mensual es 6 USD por vCPU, 3 USD por GB de RAM y 0,3 USD por GB de disco. La configuración mínima (1 vCPU, 1 GB, 25 GB) cuesta 17 USD al mes. Ejemplo: 4 vCPU + 8 GB RAM + 100 GB = 78 USD al mes. La RAM debe ser al menos el doble de las vCPU (salvo 1 vCPU con 1 GB). Usa procesadores Intel (Intel AI Optimizado / Xeon); tampoco es un producto de GPU NVIDIA.

3) AI Router: escalar el consumo de modelos sin sorpresas

Dongee AI Router es una API unificada de varios modelos, con prioridad en modelos rápidos en el data center de Dongee en Canadá. Prepago desde 3 USD, sin mensualidad; las cuentas nuevas reciben 3 USD de crédito gratis. Compatible con el estándar OpenAI (cambias URL base y clave). El enrutamiento lo programas tú sobre la API: no afirmamos auto-elección ni fallback propio del producto. No guarda conversaciones (solo datos de facturación). Al acabarse el saldo, las peticiones se detienen sin generar deuda. Se activa desde el área de cliente.

Para el ángulo de costo de tokens, también puedes leer cómo optimizar el consumo de tokens con enrutadores de IA.

4) Dongee Live: publicar la app hecha con IA (no el modelo)

Dongee Live publica apps y sitios creados con Claude Code, Codex, Cursor, VS Code o Lovable cuando le dices «publica». Incluye MySQL (variable DATABASE_URL) y correo con el dominio del plan. Live Gratis permite uso comercial con términos de uso razonable, 1 app, 1 MySQL y 1 correo, y dominio gratis con DNS de Cloudflare. Live Pro cuesta 15 USD/mes (3 apps) y Live Team 29 USD/mes (10 apps). Stacks: Node.js 20/22/24, estáticos, Next.js standalone, TanStack Start; hasta 100 MB por publicación MCP y 32 MB por GitHub. No publica Python, PHP, WordPress ni Docker, y no despliega modelos de IA.

5) Hosting Empresas: si no quieres administrar el servidor

Cuando la app web ya es crítica y no tienes DevOps, el Hosting Empresas es gestionado: Zafiro desde 25 USD/mes (2 CPU / 3 GB / 70 GB NVMe), Esmeralda 43, Rubí 60 y Diamante 76. Incluye backups diarios, monitoreo 24/7, soporte en español con respuesta promedio en menos de 60 segundos, uptime 99,9 % y Dongee Live. Desde ahí también puedes llamar a modelos vía AI Router.

Errores comunes al escalar apps de IA

• Buscar GPU «por si acaso». Si usas modelos por API, la GPU no acelera tu chatbot: solo encarece la factura.
• Meter la clave de la API en el frontend. Cualquiera la puede copiar y gastar tu saldo. Guárdala en el servidor y limítala por modelo.
• Escalar solo el servidor y olvidar los tokens. Un pico de conversaciones puede costar más en API que en CPU.
• Publicar la app en un PaaS y el backend crítico sin backups. Prueba restauraciones; un snapshot no sirve si nunca lo validaste.
• Creer que Live despliega modelos. Live publica la app; Cloud + Router cubren backend y modelos.
• Empezar en el plan más grande. Empieza pequeño, mide y sube CPU/RAM o saldo de Router cuando las métricas lo pidan.

Preguntas frecuentes

¿Necesito GPU para escalar una aplicación de IA?

No, si los modelos corren por API. Dongee Cloud usa Intel Xeon y no trae GPU NVIDIA: escala la app y el backend; los modelos los consumes con AI Router u otra API.

¿Cuál es la mejor infraestructura cloud para empezar?

Depende de tu etapa. Si solo publicas una app Node/MySQL hecha con IA, Dongee Live Gratis o Pro. Si necesitas root, agentes o workers, Dongee Cloud desde 17 USD/mes. Si el consumo de modelos crece, suma AI Router (prepago desde 3 USD).

¿Puedo subir recursos sin migrar?

Sí. En Dongee Cloud puedes subir CPU, RAM y disco sin reiniciar ni migrar, y agregar más instancias con red privada.

¿Dongee Live sirve para alojar modelos de lenguaje?

No. Live publica las apps que creas con herramientas de IA; no publica ni despliega modelos.

¿Qué pasa si se acaba el saldo de AI Router?

Las peticiones se detienen hasta que recargues. No se genera deuda ni cobros automáticos sin tu autorización.

¿Cloud On Demand incluye GPU?

No. Usa procesadores Intel (Intel AI Optimizado / Xeon). El precio se calcula por vCPU, RAM y disco NVMe.

¿Dónde están los servidores?

Dongee Cloud está disponible en Atlanta, Miami, Nueva York, Dallas, México, São Paulo, Santiago de Chile, Frankfurt, Madrid, Londres y Ámsterdam. Los modelos rápidos de AI Router están en el data center de Dongee en Canadá.

¿Incluye backup Dongee Cloud?

Sí: backup incluido en todos los planes, más snapshots. Aun así, prueba una restauración de vez en cuando.

El mejor hosting en Perú con soporte en español depende de lo que más te importe: Hostinger suele ganar en precio de entrada, GoDaddy en registro de dominios y ecosistema, HostGator en trayectoria en el mercado hispano y Dongee en soporte humano 24/7 en español con migración gestionada. Si tu negocio en Perú (o en el resto de Hispanoamérica) depende de que alguien real te responda rápido cuando algo falla, y además quieres pagar en soles u otra moneda local, Dongee es la opción más completa de las cuatro.

Qué mirar antes de elegir un hosting en Perú

Casi todos los proveedores prometen velocidad, seguridad y «soporte 24/7». La diferencia real está en los detalles. Antes de contratar, revisen estos seis puntos:

• Quién te atiende y cómo: ¿es una persona o un bot?, ¿por qué canales (chat, WhatsApp, teléfono)?, ¿en español?, ¿a cualquier hora?
• Precio de renovación, no solo el de entrada: muchas ofertas son por el primer periodo y la renovación cuesta bastante más. Pregunten el precio del segundo año.
• Moneda y facturación: confirmen si pueden pagar o liquidar en soles (o en su moneda local) y si les entregan la factura que necesita su contabilidad.
• Tecnología del servidor: discos NVMe, LiteSpeed, HTTP/3 y caché hacen una diferencia notable en WordPress y en tiendas en línea.
• Migración: si ya tienen un sitio, ¿se lo pasan sin que se caiga?
• Espacio para crecer: ¿pueden pasar a recursos dedicados o a la nube sin cambiar de proveedor?

Si vienen de México o Colombia, también pueden leer nuestras guías hermanas: mejor hosting en México con soporte en español y hosting confiable para un negocio en Colombia.

Comparativa: Hostinger, GoDaddy, HostGator y Dongee

Esta es una comparación honesta de en qué destaca cada uno y qué conviene revisar. Las condiciones y precios de terceros cambian a menudo, así que confírmenlos siempre en la web de cada proveedor antes de pagar. Aquí no inventamos cifras ajenas.

Hostinger

Es la opción que más aparece cuando se busca «hosting barato» o «mejor hosting en Perú». Funciona bien para un primer sitio o un proyecto personal con presupuesto ajustado. Si su sitio es la fuente de ventas del negocio, comparen con calma el precio de renovación y prueben el soporte antes de que lo necesiten de verdad.

GoDaddy

Muy fuerte en dominios: si lo principal es registrar un .pe, un .com.pe o un .com, es un nombre conocido. Como hosting cumple, pero conviene revisar el carrito con atención, porque es fácil terminar pagando por complementos que no necesitan.

HostGator

Tiene una larga presencia en el mercado hispano y una base grande de usuarios con cPanel. Es una alternativa razonable para sitios tradicionales; revisen bien qué incluye cada plan y cómo es la atención en su horario.

Dongee

Dongee es un proveedor latinoamericano con presencia en Perú y en el resto de la región. Su principal diferencia es el soporte: ingenieros reales que responden 24/7 en español por chat, WhatsApp y teléfono, no un bot. En Hosting Empresas, la respuesta promedio es de menos de 60 segundos. Pueden pagar o liquidar en soles y otras monedas locales, con facturación adaptada a contabilidad empresarial.

Los planes de hosting compartido (Emprende desde 10 USD/mes y Quantum desde 19 USD/mes) incluyen migración hecha por el equipo, backups diarios, Cloudflare, Dongee Live, uptime 99,9 %, soporte humano 24/7 y 30 días de garantía, sobre discos SSD NVMe, cPanel y CloudLinux. El plan anual incluye 1 dominio por 1 año.

Para empresas con sitios críticos, el hosting empresarial ofrece CPU, RAM y almacenamiento separados en contenedores (Zafiro 25, Esmeralda 43, Rubí 60 y Diamante 76 USD/mes), backups diarios, monitoreo 24/7 y soporte Empresas. Si usan WordPress, está el hosting WordPress PRO (desde 6,66 USD/mes). Si necesitan root y escalar a pedido, Dongee Cloud empieza en 17 USD/mes, con backup incluido en todos los planes.

Además, con Dongee Live pueden publicar en su hosting las apps y sitios que crean con herramientas de IA como ChatGPT, Claude Code, Cursor o Lovable, sin configurar servidores. Para instalarlo en su asistente basta con ejecutar npx skills add dongeelive/skills -g -y. Live Gratis permite uso comercial (con uso razonable); Live Pro cuesta 15 USD/mes (3 apps) y Live Team 29 USD/mes (10 apps). Ninguno de los otros tres proveedores de esta comparación ofrece algo equivalente.

¿Cuál elegir según su caso?

• Proyecto personal o primer blog con el presupuesto más bajo posible: Hostinger o el plan Emprende de Dongee. Comparen el precio de renovación.
• Solo quieren un dominio .pe o .com.pe: cualquier registrador acreditado sirve; GoDaddy es la opción más famosa. Luego conectan el dominio por DNS a su hosting.
• Pyme cuyo sitio o tienda genera ventas: prioricen soporte humano inmediato en español, migración sin caídas y pago en soles. Aquí Dongee tiene ventaja.
• Empresa con tráfico alto o sistemas críticos: busquen recursos dedicados, como el hosting empresarial, o un servidor en la nube de Dongee.
• Hicieron una app con IA y quieren ponerla en línea: Dongee Live es la vía más directa.

Cómo contratar y migrar su sitio a Dongee paso a paso

1. Elijan el tipo de plan en dongee.com/es/hosting (compartido, WordPress, empresas o Cloud). Si dudan, escriban al chat y un ingeniero les recomienda el nivel adecuado.
2. Revisen el precio en la página del plan y la forma de pago (pueden liquidar en soles u otras monedas locales) antes de confirmar.
3. Conecten su dominio: usen uno que ya tengan o registren uno nuevo. El plan anual de hosting compartido y el de Empresas a 12 meses incluyen 1 dominio por 1 año.
4. Pidan la migración si ya tienen un sitio en otro proveedor; el equipo de Dongee la hace por ustedes (ver migración a Dongee y migración).
5. Verifiquen su sitio con la prueba de velocidad y cambien los DNS cuando todo esté listo.

Preguntas frecuentes

¿Cuál es el hosting más barato en Perú?

Los precios de entrada más bajos suelen ser los de Hostinger y de los planes básicos de cada proveedor, incluido Dongee (Emprende desde 10 USD/mes). Lo importante es comparar el precio de renovación y lo que incluye cada plan, no solo la oferta del primer mes.

¿Qué hosting tiene soporte en español 24/7 de verdad?

Varios lo anuncian; la forma de saberlo es escribirles a las 3 de la mañana antes de contratar. En Dongee el soporte lo dan personas, no bots, 24/7 y en español por chat, WhatsApp y teléfono. En Hosting Empresas, la respuesta promedio es de menos de 60 segundos.

¿Puedo pagar el hosting de Dongee en soles?

Sí. Pueden pagar o liquidar en soles y en otras monedas locales, además de tarjetas, transferencias, efectivo referenciado y cripto. La facturación se adapta a la contabilidad empresarial.

¿Es mejor un hosting con servidores en Perú?

La ubicación influye en la latencia, pero para la mayoría de sitios pesa más la calidad del servidor (NVMe, LiteSpeed, caché) y el uso de una CDN. Hagan una prueba de velocidad desde su ciudad antes de decidir. Dongee Cloud, por ejemplo, tiene disponibilidad en México, Miami, São Paulo, Santiago y otras regiones.

¿Puedo cambiarme de Hostinger, GoDaddy o HostGator a Dongee sin perder mi sitio?

Sí. Dongee hace la migración de web (y correos cuando aplica) sin que su sitio se caiga, con ventana controlada. Vean cómo migrar a Dongee.

¿Qué pasa si no me gusta el servicio?

Los planes de hosting de Dongee tienen 30 días de garantía de devolución de dinero.

¿Sirve el hosting de Dongee para publicar apps hechas con ChatGPT o Lovable?

Sí. Con Dongee Live publican en su hosting la app que crearon con un asistente de IA, sin configurar servidores ni hacer despliegues manuales. Live Gratis permite uso comercial; Live Pro y Live Team suben a 3 y 10 apps.

¿Quieren ayuda para elegir? Hablen con un ingeniero de Dongee desde el chat de dongee.com y les recomienda el plan adecuado para su negocio en Perú o en cualquier país de Hispanoamérica.

Las mejores opciones para optimizar el consumo de tokens con enrutadores de IA combinan una API unificada, reglas claras de enrutamiento en tu app y un tope de saldo prepago: las consultas fáciles van a un modelo rápido y barato, las difíciles a uno más potente, y los prompts se mantienen cortos. Así reduces gasto sin depender de un solo proveedor caro para todo. En Dongee, AI Router ofrece varios modelos detrás de una sola clave, prepago desde 3 USD sin mensualidad y 3 USD de crédito gratis al abrir la cuenta; el enrutamiento lo programas tú sobre esa API.

Esta guía está pensada para equipos de México, Colombia, Perú, Chile, Argentina y el resto de Hispanoamérica que ya usan (o van a usar) modelos de lenguaje y quieren gastar menos tokens sin sacrificar calidad. El ángulo es el costo por token, no una lista de marcas ni el detalle técnico del chatbot: si buscas comparar tipos de servicio, mira la comparativa de servicios para enrutar consultas entre modelos; si necesitas el flujo técnico de un chatbot, está en el post de enrutamiento inteligente entre modelos para chatbot.

Qué son los tokens y por qué importan en el presupuesto

Un token es la unidad con la que los modelos de lenguaje miden el texto: aproximadamente un trozo de palabra o de signo. Cada petición consume tokens de entrada (el prompt, el historial y el contexto que envías) y de salida (la respuesta del modelo). Cuanto más largo el mensaje y más verbosa la respuesta, más tokens se facturan.

Por eso el consumo importa aunque no mires el precio exacto de cada proveedor:

• Pagas por uso. Casi todos los modelos comerciales cobran según tokens de entrada y salida. Sin control, una app con historial largo o respuestas sin tope se come el presupuesto en días.
• No todo el texto «vale» igual. Un saludo corto no necesita el mismo modelo (ni la misma cantidad de contexto) que resumir un contrato o depurar código.
• El modelo importa tanto como el largo. Un modelo potente suele costar más por token que uno rápido. Si mandas todo al más caro, pagas de más en lo sencillo.
• Latencia y tokens van juntos. Prompts inflados y respuestas sin límite también hacen esperar más al usuario.

Optimizar tokens no es «usar menos IA». Es enviar solo lo necesario y elegir el modelo adecuado por consulta, con un techo de gasto visible.

Cómo un enrutador ayuda a gastar menos tokens

Un enrutador (o gateway) de IA te da un punto de entrada común a varios modelos. La decisión de a cuál enviar cada consulta la defines tú en tu código o en reglas propias. Eso abre cuatro palancas de ahorro:

1. Modelo barato para lo fácil, potente para lo difícil. Saludos, FAQs y clasificaciones cortas van al modelo rápido; razonamiento, documentos largos o código van al fuerte. Evitas pagar el modelo premium en la mayoría de mensajes triviales.
2. Prompts cortos y contexto recortado. Antes de llamar al modelo, recorta el historial a lo relevante, quita plantillas repetidas y pide respuestas concisas («responde en 3 viñetas»). Menos tokens de entrada y de salida.
3. Cascada. Primero intenta el modelo económico; si la respuesta no pasa un control simple (formato, confianza, longitud mínima), repites con el modelo más capaz. Solo pagas la segunda llamada cuando hace falta.
4. Tope de saldo. Con prepago, cuando se acaba el crédito las peticiones se detienen: no hay factura sorpresa ni deuda automática. Eso obliga a medir y a ajustar reglas antes de recargar.

Importante: el enrutador no «magia» el ahorro por sí solo. Si tu app manda siempre el historial completo al modelo más caro, el gateway solo unifica la API. El ahorro viene de las reglas que programas encima.

8 pasos prácticos para optimizar tokens en Latinoamérica

1. Mide una semana de uso real. Anota cuántas peticiones son fáciles (saludo, FAQ, clasificación) y cuántas difíciles (análisis, código, documentos). Sin esa proporción no sabes cuánto puedes ahorrar con dos modelos.
2. Define dos rutas como mínimo. «Rápido/barato» y «potente». Empieza con reglas por longitud, tipo de tarea o etiqueta de un clasificador pequeño; no hace falta un sistema sofisticado el día uno.
3. Acorta el prompt de sistema. Deja instrucciones claras y cortas. Cada párrafo de plantilla se multiplica por todas las llamadas.
4. Limita el historial. Envía solo los últimos turnos útiles o un resumen corto. El historial infinito es la causa más común de facturas altas.
5. Pon techo a la salida. Usa un máximo de tokens de respuesta y pide formato breve cuando baste. Las respuestas eternas cuestan y cansan.
6. Usa una API unificada. Con Dongee AI Router cambias de modelo cambiando el nombre del modelo en la petición (misma clave, misma URL base compatible con el estándar OpenAI). Así pruebas rutas sin reescribir integraciones.
7. Activa prepago y revisa el panel. Recarga poco al inicio, mira consumo por modelo y por clave, y ajusta: si buena parte de lo «potente» podría ir a «rápido», cambia la regla.
8. Aloja la lógica en tu servidor, no en el navegador. La clave y el enrutamiento viven en backend. Puedes correr esa capa en Hosting Empresas, en Dongee Cloud o dentro de una app en Dongee Live, según tu stack. Si además quieres servidores con herramientas de IA cerca, revisa servidores en la nube con herramientas de IA.
9. Revisa cada mes. Nuevos modelos, nuevos precios relativos y nuevos tipos de consulta aparecen. Ajusta reglas con datos del área de cliente, no a ojo.

Comparación honesta: tipos de opción para optimizar tokens

No inventamos precios de terceros. La tabla compara tipos de enfoque para que elijas según control, esfuerzo y forma de pago:

Para la mayoría de equipos en Hispanoamérica, el camino práctico es: API unificada + reglas simples + prepago + medición. Escala a un gateway autoalojado solo cuando el volumen y el equipo lo justifiquen.

Cómo se ve en Dongee AI Router

Datos tomados de la página de producto y del área de cliente (sin inventar funciones de enrutamiento automático):

• API unificada de varios modelos de IA, con prioridad en modelos rápidos alojados en el data center de Dongee en Canadá.
• Una sola clave; prepago desde 3 USD sin mensualidad.
• Cuentas nuevas: 3 USD de crédito gratis al inicio para probar.
• Compatible con el estándar OpenAI como opción secundaria: cambias la URL base y la clave en tu código actual.
• El enrutamiento lo programas tú sobre la API (por modelo, por tipo de consulta, cascada, etc.). AI Router no afirma elegir el modelo automáticamente ni hacer fallback por su cuenta.
• Privacidad: no guarda conversaciones; solo registra datos de facturación de cada petición.
• Al acabarse el saldo las peticiones se detienen; no genera deuda ni cobros automáticos.
• Activación desde el área de cliente Dongee (necesitas cuenta).
• Seguridad de claves: no las pongas en el navegador; guárdalas en el servidor y limita cada clave a los modelos que necesita.
• Visibilidad: en el área de cliente ves consumo por modelo, por clave y el detalle de cada petición — justo lo que necesitas para afinar el ahorro de tokens.

En la práctica: creas la clave, apuntas tu backend al endpoint, defines en código qué consultas van al modelo rápido y cuáles al potente, y usas el panel para validar que el gasto bajó.

Errores comunes al «optimizar» tokens

• Usar siempre el modelo más potente «por si acaso». Es la forma más rápida de vaciar el saldo.
• Historial completo en cada llamada. Recorta o resume; no reenvíes toda la conversación eterna.
• Prompt de sistema de novela. Instrucciones largas se pagan en cada petición.
• Confiar en que el gateway enruta solo. En AI Router (y en muchos gateways) la política la defines tú.
• No mirar el consumo por modelo. Sin el desglose no sabes qué ruta está cara.
• Clave en el frontend. Cualquiera puede verla y gastar tu prepago.
• Prometer ahorros en porcentaje sin medir. El ahorro real sale de tu mezcla de consultas fáciles vs difíciles.

Preguntas frecuentes

¿Qué es un enrutador de IA y cómo ayuda a gastar menos tokens?

Es una capa (API unificada o gateway) que te permite hablar con varios modelos con una sola integración. Gastar menos tokens/costo implica que tú envíes lo fácil a un modelo barato y lo difícil a uno potente, acortes prompts y pongas techos de salida y de saldo.

¿Dongee AI Router elige el modelo automáticamente?

No. El enrutamiento lo programas el cliente sobre la API. El producto te da la API unificada, la clave, el prepago y el detalle de consumo; las reglas (barato vs potente, cascada, etc.) viven en tu aplicación.

¿Cuánto cuesta empezar con Dongee AI Router?

Prepago desde 3 USD sin mensualidad. Las cuentas nuevas reciben 3 USD de crédito gratis al inicio. Solo se descuenta el consumo; si se acaba el saldo, las peticiones se detienen.

¿Sirve si mi código ya usa la API de OpenAI?

Sí, como opción secundaria compatible con el estándar OpenAI: cambias la URL base y la clave. Luego eliges el modelo por petición según tus reglas de ahorro.

¿Guardan el contenido de mis prompts?

No. Dongee AI Router no guarda conversaciones; solo registra datos de facturación de cada petición.

¿Puedo poner la clave en el navegador para un demo?

No es recomendable. Cualquiera podría verla y usar tu saldo. Guarda las claves en el servidor y limita cada una a los modelos necesarios.

¿Cómo sé si realmente estoy ahorrando?

En el área de cliente: consumo por modelo, por clave y detalle de cada petición. Compara una semana con un solo modelo vs una semana con dos rutas (rápido/potente) y prompts más cortos.

¿Dónde corro la lógica de enrutamiento?

En tu backend. Según el proyecto: Hosting Empresas, Cloud o una app en Live. AI Router se activa desde el área de cliente Dongee.

Si tu agencia crea apps con IA para sus clientes (con Lovable, Bolt, v0, Claude Code, Codex o Cursor), la forma más simple de publicarlas es una plataforma que reciba el proyecto ya listo, le asigne el dominio del cliente y te deje manejar varias apps desde un mismo panel. Dongee Live hace eso para apps Node.js y sitios estáticos, con base de datos MySQL y correo incluidos y soporte humano en español; Vercel, Netlify, Render o Railway son buenas opciones cuando tu equipo ya trabaja con Git y necesita otros lenguajes o bases de datos.

Qué necesita una agencia para publicar apps de sus clientes

Publicar una app propia es una cosa. Publicar diez apps de diez clientes distintos es otra. Antes de elegir plataforma, revisa estos puntos:

• Varias apps en una sola cuenta. Necesitas ver y mantener todos los proyectos desde un mismo lugar, sin abrir una cuenta por cliente.
• Dominio propio por cliente. Cada app debe salir con el dominio de la marca del cliente, no con un subdominio de la plataforma.
• Uso comercial permitido. Las apps de tus clientes venden, cobran o promocionan servicios. Algunos planes gratis lo prohíben.
• Base de datos y correo. Formularios, usuarios y pedidos necesitan base de datos, y el cliente suele querer un correo con su dominio.
• Un flujo que no dependa de un programador. Si en tu equipo hay diseñadores o estrategas que crean con IA, la publicación no puede exigir servidores, SSH ni configuraciones complejas.
• Soporte y facturación que encajen con tu operación. Cuando algo falla en la app de un cliente, necesitas a alguien que responda en tu idioma.

Dongee Live para agencias: qué hace y qué no

Dongee Live publica las apps y sitios que creas con asistentes de IA cuando le dices «publica». Tu IA escribe el código y Dongee Live se encarga de ponerlo en línea, sin Git ni SSH para el flujo habitual.

• Cuántas apps: Live Gratis permite 1 app, Live Pro 3 apps y Live Team 10 apps. Para una agencia, Live Pro o Live Team permiten tener varios proyectos de clientes bajo una misma cuenta. Revisa los planes vigentes en la página de planes de Dongee Live.
• Uso comercial: incluso el plan gratis permite uso comercial, con términos de uso razonable. Sirve para montar una demo o un piloto para un cliente sin pagar por adelantado.
• Base de datos y correo: cada app incluye una base de datos MySQL (en la variable DATABASE_URL) y correo con el dominio del plan, para usar por webmail o IMAP. El correo no es para envíos masivos.
• Tecnologías compatibles: sitios estáticos (HTML, CSS y JavaScript, React, Vue, Svelte, Angular, Astro y Vite) y apps Node.js 20, 22 o 24 (Express, Fastify, Koa, Hono, Next.js en modo standalone y TanStack Start, el stack actual de Lovable).
• Tamaño: hasta 100 MB por publicación desde el conector MCP y 32 MB por subida desde GitHub.

Lo que no publica: Python, Ruby, PHP o WordPress, Docker ni bases de datos distintas de MySQL (no incluye Postgres ni MongoDB). Y un punto importante: Dongee Live publica apps; no sirve para desplegar ni alojar modelos de IA.

Cómo organizar la publicación de apps de clientes paso a paso

1. Clasifica cada proyecto por tecnología. Si es Node.js o un sitio estático, va en Dongee Live. Si es WordPress o PHP, va en hosting con cPanel. Si usa Python, Docker u otra base de datos, necesita un servidor en la nube.
2. Elige el plan según el número de apps. Cuenta cuántos proyectos activos vas a mantener y elige entre Live Gratis (1 app), Live Pro (3) o Live Team (10).
3. Conecta tu herramienta de IA. En Claude Code, Codex o Cursor, ejecuta en la terminal npx skills add dongeelive/skills -g -y. Desde ahí, cuando la app de un cliente esté lista, le dices a tu IA «publica».
4. Si el proyecto viene de Lovable, Bolt o v0, conecta su repositorio de GitHub a Dongee Live. La compilación se hace en GitHub y cada push se publica solo, así que los cambios que hagas para el cliente salen en línea sin pasos extra.
5. Conecta el dominio del cliente y crea el correo con ese dominio desde el panel.
6. Deja documentado qué app corresponde a qué cliente, qué dominio usa y quién de tu equipo la mantiene. Con varias apps, este orden te ahorra problemas.

Si es la primera vez que publicas una app hecha con IA, empieza por la guía ¿Dónde publico la app que hice con ChatGPT o Lovable?.

Y los proyectos que no son apps Node.js

Una agencia rara vez trabaja con una sola tecnología. En Dongee puedes cubrir el resto así:

• Sitios WordPress y PHP de clientes: el hosting para agencias incluye cPanel y WHM para administrar las cuentas de cada cliente por separado, con alta disponibilidad, AccelerateWP y soporte 24/7. Si solo manejas sitios WordPress, mira también el hosting WordPress.
• Apps en Python, con Docker o con otras bases de datos: Dongee Cloud te da un servidor con acceso root completo para instalar lo que necesites.
• Apps que usan varios modelos de IA: si las apps de tus clientes llaman a modelos de lenguaje, Dongee AI Router te da una sola API y una sola clave para varios modelos, con prepago desde 3 USD y sin mensualidad.

Comparación honesta con otras plataformas

En resumen: si tu agencia crea con IA y quiere publicar rápido apps Node.js o estáticas de varios clientes, Dongee Live es la opción más directa. Si tu equipo es técnico y trabaja con otros lenguajes, contenedores o Postgres, Render, Railway o un servidor cloud te dan más libertad.

Preguntas frecuentes

¿Puedo publicar las apps de varios clientes en una sola cuenta de Dongee Live?

Sí. Live Pro permite 3 apps y Live Team 10 apps, así que puedes mantener varios proyectos de clientes desde la misma cuenta.

¿Mis clientes pueden usar la app con fines comerciales?

Sí. Dongee Live permite uso comercial desde el plan gratis, con términos de uso razonable.

¿Necesito un programador en la agencia para publicar?

No para el flujo habitual. Tu IA escribe el código y, cuando le dices «publica», Dongee Live lo pone en línea. No hace falta Git ni SSH.

¿Qué pasa si el cliente quiere un sitio en WordPress?

Dongee Live no publica WordPress ni PHP. Para eso está el hosting para agencias con cPanel y WHM, o el hosting WordPress.

¿Las apps de mis clientes pueden tener base de datos?

Sí. Cada app incluye una base de datos MySQL. Si el proyecto necesita Postgres o MongoDB, conviene un servidor en Dongee Cloud.

¿Dongee Live sirve para desplegar modelos de IA?

No. Dongee Live publica las apps que haces con herramientas de IA, no modelos. Si tus apps necesitan conectarse a varios modelos de lenguaje, usa Dongee AI Router.

¿Puedo publicar apps hechas con Lovable, Bolt o v0?

Sí. Conecta el repositorio de GitHub del proyecto y cada push se publica solo en Dongee Live. La compilación se hace en GitHub.

Si estás en Colombia y quieres una alternativa a Vercel, Railway o Render para publicar una app hecha con IA, Dongee Live es la opción más directa cuando tu app es Node.js o un sitio estático: tiene un plan gratis con uso comercial permitido, incluye base de datos MySQL y correo con tu dominio, y te atiende soporte humano en español. Vercel sigue siendo muy bueno para Next.js, pero su plan gratis es solo para uso personal. Railway y Render convienen más si tu app usa Python, Docker o Postgres.

Por qué buscar una alternativa a Vercel, Railway o Render

Las tres plataformas son buenas y muy usadas por desarrolladores. El problema aparece cuando la app la hiciste con una herramienta de IA (Lovable, Bolt, v0, Claude Code, Codex o Cursor), no eres programador y la vas a usar en tu negocio. Ahí pesan cosas que no siempre se ven al inicio:

• Uso comercial. El plan gratis de Vercel (Hobby) está limitado a uso personal y no comercial, según sus propias reglas de uso. Si tu app cobra, vende o anuncia un servicio, necesitas un plan pago.
• Correo y base de datos. Vercel no incluye correo, y la base de datos la ponen terceros desde su marketplace. Terminas manejando varias cuentas.
• Cobro en dólares. Estas plataformas cobran en USD con tarjeta internacional.
• Soporte. El soporte suele ser en inglés y, en los planes gratis, limitado o inexistente.
• Configuración. Variables de entorno, compilaciones y repositorios pueden ser un muro si no sabes programar.

Dongee Live: qué es y qué puedes publicar

Dongee Live publica las apps y sitios que creas con asistentes de IA cuando le dices «publica». No necesitas Git ni SSH para el flujo normal: tu IA escribe el código y Dongee Live se encarga de ponerlo en línea.

• Tecnologías compatibles: sitios estáticos (HTML, CSS y JavaScript, React, Vue, Svelte, Angular, Astro y Vite) y apps Node.js 20, 22 o 24 (Express, Fastify, Koa, Hono, Next.js en modo standalone y TanStack Start, el stack actual de Lovable).
• Incluye: una base de datos MySQL por app (en la variable DATABASE_URL) y correo con el dominio de tu plan, para usar por webmail o IMAP. El correo no es para envíos masivos.
• Planes: Live Gratis permite 1 app, Live Pro 3 apps y Live Team 10 apps. El plan gratis permite uso comercial, con términos de uso razonable. Revisa los planes vigentes en la página de Dongee Live.
• Tamaño: hasta 100 MB por publicación desde el conector MCP y 32 MB por subida desde GitHub.

Lo que no publica: Python, Ruby, PHP o WordPress, Docker ni bases de datos distintas de MySQL (no incluye Postgres ni MongoDB). PHP y WordPress van en el hosting web de Dongee con cPanel. Y ojo: Dongee Live publica apps; no sirve para desplegar modelos de IA.

Cómo publicar tu app en Dongee Live paso a paso

Si la hiciste con Claude Code, Codex o Cursor

1. Crea tu cuenta en Dongee Live y elige el plan.
2. En la terminal de tu asistente, instala las habilidades de Dongee Live con npx skills add dongeelive/skills -g -y.
3. Cuando tu app esté lista, dile a tu IA «publica». Dongee Live la pone en línea.
4. Conecta tu dominio y crea tu correo con ese dominio desde el mismo panel.

Si la hiciste con Lovable, Bolt o v0

1. Conecta tu proyecto a un repositorio de GitHub desde la herramienta.
2. Conecta ese repositorio en Dongee Live. La compilación se hace en GitHub y cada push se publica solo.
3. Configura tu dominio y tu correo.

Si quieres más detalle sobre este primer paso, mira la guía ¿Dónde publico la app que hice con ChatGPT o Lovable?.

Comparación honesta: Dongee Live, Vercel, Railway y Render

En resumen: si tu app es Node.js o un sitio estático y la vas a usar en tu negocio, Dongee Live te ahorra cuentas, configuración y la restricción comercial del plan gratis de Vercel. Si tu app necesita Python, Docker o Postgres, Railway o Render son más adecuados. Si tu equipo programa en Next.js y vive en el ecosistema de Vercel, Vercel Pro sigue siendo una gran opción.

¿Y cuando la app crece?

Si tu app empieza a ser crítica para el negocio, puedes llevarla a un plan con más recursos. Dongee Live viene incluido en el hosting web y en el Hosting Empresas (desde 25 USD al mes en el plan Zafiro), con backups diarios, monitoreo 24/7 y uptime de 99,9 %. Si tu equipo necesita servidores propios con acceso root, está Dongee Cloud.

Preguntas frecuentes

¿Cuál es la mejor alternativa a Vercel en Colombia para una app hecha con IA?

Depende del tipo de app. Si es Node.js o un sitio estático y la vas a usar comercialmente, Dongee Live es una alternativa directa: plan gratis con uso comercial, base de datos MySQL, correo con tu dominio y soporte humano en español. Si tu app usa Python o Docker, mira Railway o Render.

¿Puedo usar el plan gratis de Vercel para mi negocio?

No. Según las reglas de uso de Vercel, el plan Hobby es solo para uso personal y no comercial; el uso comercial requiere un plan Pro o Enterprise.

¿Dongee Live funciona con Lovable, Bolt y v0?

Sí. Conectas el repositorio de GitHub de tu proyecto y cada push se publica solo. Lovable usa TanStack Start, que es compatible.

¿Puedo publicar una app en Python o con Docker en Dongee Live?

No. Dongee Live publica apps Node.js y sitios estáticos. Para Python o Docker, plataformas como Railway o Render son más adecuadas, o un servidor en Dongee Cloud.

¿Necesito saber programar para usar Dongee Live?

No. Tu IA escribe el código y Dongee Live se encarga de publicarlo cuando le dices «publica».

¿Qué base de datos incluye Dongee Live?

Cada app incluye una base de datos MySQL, disponible en la variable DATABASE_URL. No incluye Postgres ni MongoDB.

¿Dongee Live sirve para desplegar modelos de IA?

No. Dongee Live publica apps y sitios. Si lo que necesitas es usar varios modelos de IA desde tu app con una sola clave, mira Dongee AI Router.

¿Tienes dudas sobre si tu app es compatible? Escríbele a un ingeniero de Dongee desde el chat de dongee.com y te dice cómo publicarla.

Conviene pasar de un hosting compartido a un servidor en la nube administrado cuando tu sitio o aplicación ya es crítico para el negocio y el plan compartido se queda corto: se pone lento en horas pico, choca con los límites de recursos o necesitas instalar software que el panel no permite. Si quieres más potencia sin administrar servidores, el paso natural es un hosting gestionado con recursos separados; si tu equipo sabe administrar Linux y necesita acceso root, el paso es un servidor cloud propio. Mientras tu web cargue bien y no tengas esas limitaciones, un buen hosting compartido sigue siendo la opción más económica.

Esta guía es para dueños de negocio, agencias y equipos técnicos de México, Perú, Colombia, Argentina, Chile y el resto de Hispanoamérica que se preguntan si ya llegó el momento de dar el salto. Verás las señales concretas, qué significa realmente «administrado», cómo comparar las opciones y cómo hacer la migración sin parar tu operación.

Qué cambia entre un hosting compartido y un servidor en la nube

En un hosting compartido varios sitios usan los recursos de un mismo servidor y tú administras tu cuenta desde un panel como cPanel, sin acceso root. El proveedor se encarga del sistema operativo, la seguridad del servidor, las actualizaciones y los backups. Es barato y cómodo, pero tienes límites de CPU, memoria y procesos, y no puedes instalar cualquier software.

En un servidor en la nube tienes recursos asignados para ti (CPU, RAM y disco) que puedes ampliar cuando lo necesites, y normalmente acceso root para instalar lo que quieras. La pregunta clave es quién lo administra:

• Nube no administrada (autogestionada): el proveedor garantiza el hardware y la red; tú instalas, actualizas, aseguras y monitoreas el sistema.
• Nube o hosting administrado (gestionado): el proveedor se encarga de la operación del servidor, el monitoreo, los backups y buena parte de la seguridad; tú te concentras en tu sitio o aplicación.

Si quieres profundizar en las diferencias técnicas, revisa nuestra guía Web Hosting vs Cloud Hosting y la explicación de qué es un VPS.

7 señales de que ya es momento de salir del hosting compartido

1. Tu sitio se pone lento en horas pico o durante campañas. Si cada vez que lanzas una promoción, un envío de correos o una pauta la web tarda en cargar, estás chocando con los recursos del plan.
2. Ves errores por límites de recursos. Mensajes como «Resource Limit Reached», errores 500 o 508 intermitentes, o procesos que se cortan, suelen indicar que tu cuenta llegó al tope de CPU, memoria o procesos.
3. Tu tienda en línea o tu sistema ya factura. Cuando cada minuto caído es dinero perdido, necesitas recursos que no se compartan y un monitoreo que actúe antes de que tus clientes noten el problema.
4. Necesitas instalar software que el panel no permite. Servicios propios, versiones específicas de bases de datos, colas de trabajo, contenedores o herramientas de automatización como n8n requieren un servidor con más control.
5. Tu aplicación hecha con IA o tu API necesita procesos permanentes. Un backend que corre todo el día, trabajos programados pesados o conexiones con modelos de IA consumen más de lo que un plan compartido está pensado para dar.
6. Manejas varios proyectos o clientes. Si eres agencia y un sitio con mucho tráfico afecta a los demás, separar recursos evita que un cliente frene al resto.
7. Tienes requisitos de seguridad o cumplimiento. Si tus clientes o tu sector te piden aislamiento, backups con mayor retención o infraestructura certificada, conviene revisar opciones más robustas.

Si solo te pasa una de estas cosas de vez en cuando, quizá basta con optimizar (caché, imágenes, plugins) o subir a un plan compartido superior. Si te pasan varias de forma habitual, ya es hora del salto.

¿Nube administrada o autogestionada? Cómo decidir

La decisión depende menos del tamaño de tu negocio y más de quién va a cuidar el servidor:

• Elige una opción administrada si no tienes un administrador de sistemas en el equipo, si tu prioridad es vender y no apagar incendios, o si necesitas que alguien responda de madrugada cuando algo falla.
• Elige un servidor cloud autogestionado si tu equipo domina Linux, necesita acceso root, quiere diseñar su propia arquitectura (varios servidores, red privada, contenedores) y está dispuesto a encargarse de actualizaciones, seguridad y monitoreo.

Un error común es contratar un servidor cloud sin administración porque «es más potente» y luego no tener quién lo mantenga: el servidor queda sin parches, sin backups probados y sin alertas. Más potencia sin operación no es más estabilidad.

Comparación honesta de las opciones

Cómo se ve este salto con Dongee

En Dongee puedes recorrer las tres etapas sin cambiar de proveedor. Los precios están en USD y se toman de cada página de plan:

• Hosting compartido Emprende y Quantum: cPanel y CloudLinux sobre SSD NVMe, desde 10 USD al mes (Emprende) y 19 USD al mes (Quantum), con correos con tu dominio, backups diarios, Cloudflare, Dongee Live y soporte humano 24/7 por chat y WhatsApp.
• Hosting Empresas (la opción gestionada): recursos separados en contenedores con CPU, RAM e IO definidos por plan, discos NVMe, migración gestionada de web y correos, backups diarios, monitoreo 24/7 y soporte Empresas, sin que tengas que administrar servidores. Planes Zafiro (25 USD al mes, 2 CPU, 3 GB de RAM), Esmeralda (43 USD), Rubí (60 USD) y Diamante (76 USD, 8 CPU, 12 GB de RAM).
• Dongee Cloud (servidor cloud con acceso root): procesadores Intel Xeon, SSD NVMe, red privada entre instancias sin costo extra, snapshots, 99,9 % de uptime garantizado y soporte 24/7, desde 17 USD al mes (Dongee Cloud 1). El backup está incluido desde Dongee Cloud 4 (136 USD al mes). Está pensado para equipos que quieren su propio servidor y administrarlo ellos mismos.
• Cloud On Demand: si los planes fijos no encajan, eliges entre 1 y 64 vCPU, 1 y 256 GB de RAM y 25 y 2.000 GB de SSD NVMe, y pagas por recurso (6 USD por vCPU, 3 USD por GB de RAM y 0,3 USD por GB de disco al mes; la configuración mínima cuesta 17 USD al mes).

Regla práctica: si tu pregunta es «quiero más potencia y estabilidad, pero no quiero administrar un servidor», empieza por Hosting Empresas. Si tu pregunta es «necesito root e instalar mi propio stack», ve a Dongee Cloud. Y si estás montando proyectos con IA en la nube, te puede servir nuestra guía de servidores en la nube con herramientas de IA.

Paso a paso para migrar sin parar tu negocio

1. Mide antes de decidir

Revisa en tu panel el uso de CPU, memoria y procesos de las últimas semanas, los errores registrados y los tiempos de carga en horas pico. Anota cuántos sitios, bases de datos y cuentas de correo tienes. Con esos datos eliges un plan del tamaño correcto y no pagas de más.

2. Define quién administrará el servidor

Si nadie en tu equipo va a encargarse de parches, firewall y monitoreo, elige una opción gestionada. Si sí hay alguien, documenta desde el inicio quién responde ante una caída y cómo se hacen los backups.

3. Elige la región más cercana a tus usuarios

La latencia importa. Dongee Cloud está disponible en Atlanta, Miami, Nueva York, Dallas, México, São Paulo, Santiago de Chile, Frankfurt, Madrid, Londres y Amsterdam: si tus clientes están en México o Centroamérica, mira México, Dallas o Miami; si están en Sudamérica, São Paulo o Santiago.

4. Haz un backup completo y prueba restaurarlo

Antes de mover nada, descarga una copia de archivos, bases de datos y correos. Un backup que nunca restauraste no es garantía.

5. Migra con una ventana controlada

Copia el sitio al nuevo servidor, pruébalo con una URL temporal o editando tu archivo hosts y, cuando todo funcione, cambia los DNS en un horario de poco tráfico. Baja el TTL de tus registros DNS un día antes para que el cambio se propague más rápido. En Hosting Empresas de Dongee la migración de web y correos la hace el equipo de Dongee por ti.

6. Revisa el correo

Es lo que más se rompe en una migración: confirma los registros MX, SPF, DKIM y DMARC, y que los buzones lleguen completos.

7. Monitorea las primeras semanas

Activa alertas de disponibilidad, revisa los tiempos de carga y ajusta caché y recursos. Si te quedas corto, escala; si te sobra, baja de plan.

Errores comunes al dar el salto

• Migrar por un problema que era de optimización. Un plugin pesado o imágenes sin comprimir siguen siendo lentos en cualquier servidor.
• Contratar nube autogestionada sin quién la cuide. Sin actualizaciones ni monitoreo, el riesgo aumenta en vez de bajar.
• Olvidar el correo y los DNS. La web puede quedar perfecta y los correos dejar de llegar.
• Elegir una región lejana a tus clientes. Cada milisegundo de latencia se nota en la experiencia y en las ventas.
• No calcular el costo total. En nubes con cobro por consumo, la transferencia, los backups y el soporte pueden sumar más que el servidor.

Preguntas frecuentes

¿Cuándo conviene pasar de hosting compartido a un servidor en la nube administrado?

Cuando tu sitio ya es crítico para el negocio y el compartido muestra límites: lentitud en horas pico, errores por recursos, necesidad de software especial o varios proyectos que compiten por los mismos recursos. Si no quieres administrar servidores, una opción gestionada como Hosting Empresas de Dongee es el paso natural.

¿Qué diferencia hay entre un servidor en la nube administrado y uno no administrado?

En el administrado el proveedor se encarga de la operación, el monitoreo, los backups y buena parte de la seguridad. En el no administrado el proveedor garantiza el hardware y la red, y tu equipo instala, actualiza y protege el sistema.

¿Cuánto cuesta pasar a un servidor en la nube?

Depende de los recursos y del nivel de administración. En Dongee, Hosting Empresas va de 25 a 76 USD al mes, Dongee Cloud empieza en 17 USD al mes y Cloud On Demand se calcula por recurso desde 17 USD al mes. Revisa siempre el precio vigente en la página de cada plan.

¿Puedo volver al hosting compartido si la nube me queda grande?

Sí, migrar en sentido contrario es posible. Por eso conviene medir el consumo real antes de decidir y empezar con el plan más pequeño que cubra tus necesidades.

¿Pierdo mis correos al migrar?

No, si la migración incluye los buzones y revisas los registros DNS del correo. En el Hosting Empresas de Dongee la migración gestionada incluye web y correos.

¿Un servidor en la nube es mejor para una app hecha con inteligencia artificial?

Si tu app necesita procesos permanentes, colas de trabajo o software propio, sí. Si es una app sencilla hecha con Lovable, Claude Code o Cursor, puedes publicarla primero con Dongee Live, que viene incluido en los planes de hosting compartido y Empresas, y pasar a un servidor cloud cuando crezca.

¿Desde qué países puedo contratar?

Dongee atiende negocios de toda Hispanoamérica y los planes muestran precios en USD y en monedas locales como pesos colombianos, pesos mexicanos y soles.

Para contratar hosting con correos corporativos y un dominio .com.mx, .com.pe o de tu país necesitas tres piezas: el dominio registrado a nombre de tu empresa, un plan de hosting que incluya cuentas de correo con ese dominio y los registros DNS (MX, SPF, DKIM y DMARC) bien configurados para que tus correos lleguen a la bandeja de entrada. La forma más sencilla es un plan de hosting que ya trae correos incluidos; si tu equipo necesita buzones grandes, auditoría o sincronización con Outlook, conviene un servicio de correo corporativo aparte. En Dongee, el hosting compartido incluye 50 cuentas de correo con tu dominio desde 10 USD al mes, y el correo corporativo Dongee Prime Email empieza en 2 USD al mes por buzón.

Esta guía es para dueños de negocio, administradores y agencias de México, Perú, Colombia, Chile, Argentina y el resto de Hispanoamérica que quieren dejar de usar un correo gratuito y tener direcciones como ventas@tuempresa.com.mx o contacto@tuempresa.com.pe. Verás qué contratar, en qué orden, cómo comparar las opciones y qué errores evitar.

Qué necesitas exactamente: dominio, hosting y correo

Muchas personas creen que el dominio, el hosting y el correo son una sola cosa, pero son tres servicios distintos que trabajan juntos:

• Dominio: es el nombre de tu empresa en internet (por ejemplo, tuempresa.com.mx). Se registra por periodos, normalmente anuales, y se renueva. Si quieres repasar la diferencia, lee cuál es la diferencia entre un dominio y un hosting.
• Hosting: es el servidor donde vive tu sitio web. Muchos planes de hosting también alojan los buzones de correo de tu dominio.
• Correo corporativo: son las cuentas con tu dominio (nombre@tuempresa.com.pe). Pueden venir dentro del hosting o contratarse como un servicio aparte, con más espacio y más controles.

Lo que une las tres piezas son los registros DNS del dominio: indican qué servidor muestra tu web y qué servidor recibe y envía tus correos.

Paso a paso para contratar hosting con correos corporativos y dominio

1. Define cuántos buzones necesitas y cuánto espacio. Haz la lista de personas y áreas (ventas, facturación, soporte, gerencia). Calcula cuánto correo guarda cada una: un vendedor que recibe cotizaciones en PDF llena el buzón mucho más rápido que una cuenta de contacto.
2. Elige y registra el dominio. Para México, las extensiones .mx y .com.mx las administra NIC México; para Perú, las extensiones .pe y .com.pe las administra NIC.pe; en Colombia, .co y .com.co. Puedes registrarlas con un registrador acreditado. Lo importante es que el dominio quede a nombre de tu empresa, con un correo de contacto al que tengas acceso y con la renovación automática activada. Revisa también la guía cuánto cuesta un dominio web.
3. Escoge el plan de hosting con correo incluido. Revisa cuántas cuentas de correo trae, cuánto espacio tiene cada una, si incluye certificados SSL, backups del correo y soporte en español. Ese es el punto de partida para la mayoría de pymes.
4. Decide si necesitas un correo corporativo aparte. Si tu equipo necesita buzones de 25, 50 o 100 GB, auditoría de mensajes, calendarios compartidos o sincronización con Outlook mediante Exchange ActiveSync, un servicio de correo dedicado es mejor que el correo básico del hosting.
5. Conecta el dominio. Cambia los servidores DNS del dominio a los de tu proveedor de hosting, o crea manualmente los registros. Si nunca lo has hecho, sigue la guía cómo agregar DNS a mi dominio.
6. Configura la autenticación del correo. Verifica que existan los registros MX (a dónde llega el correo), SPF (qué servidores pueden enviar en nombre de tu dominio), DKIM (firma que demuestra que el mensaje no fue alterado) y DMARC (qué hacer con los correos que no pasan las verificaciones). Sin ellos, tus correos tienen más probabilidad de terminar en spam.
7. Crea los buzones y configúralos en los equipos. Crea las cuentas desde el panel, entra por webmail para probar y configúralas en Outlook, Apple Mail o el celular por IMAP. Si dudas entre protocolos, lee cómo saber si tu correo es POP3 o IMAP.
8. Migra el correo anterior, si lo tienes. Si vienes de otro proveedor, mueve los mensajes antes de cambiar los registros MX y haz el cambio en un horario de poco movimiento. Así no pierdes correos en la transición.
9. Prueba envío y recepción. Envía correos a cuentas de Gmail y Outlook, responde desde ellas y revisa que no lleguen a spam. Si tus sistemas envían facturas o notificaciones automáticas, configura un servicio de envío transaccional como MailChannels.

Opciones para tener correo corporativo con tu dominio: comparación honesta

Si ya usas una suite de productividad, no necesitas cambiarla: puedes tener tu sitio en un hosting y dejar los registros MX apuntando a esa suite. Lo importante es que alguien de tu empresa controle el dominio y los DNS.

Cómo se ve en Dongee

Dongee atiende negocios de toda Hispanoamérica y muestra precios en USD y en monedas locales. Estas son las opciones según el tamaño de tu empresa:

• Hosting web compartido (Emprende y Quantum): Dongee Emprende cuesta 10 USD al mes e incluye 50 cuentas de correo de 1 GB; Dongee Quantum cuesta 19 USD al mes e incluye 50 cuentas de correo de 2 GB. Los dos traen cPanel, certificados SSL, backups diarios de archivos, bases de datos y correo, Cloudflare, migración sin costo y soporte humano 24/7 por chat y WhatsApp. El plan anual incluye 1 dominio por 1 año.
• Hosting Empresas (Zafiro, Esmeralda, Rubí y Diamante): de 25 a 76 USD al mes, con recursos separados en contenedores, migración gestionada de web y correos, backups diarios, monitoreo 24/7 y soporte Empresas. Es para cuando tu sitio o tienda ya es crítico para el negocio. El plan de 12 meses incluye 1 dominio.
• Dongee Prime Email: correo corporativo aparte con planes Basic (desde 2 USD al mes con 8 GB), Professional (desde 3 USD al mes, con calendario, tareas, CardDAV y CalDAV) y Enterprise (desde 4 USD al mes, con Microsoft Exchange ActiveSync, acceso forzado con OTP y restricciones IP avanzadas). Todos incluyen webmail, POP, IMAP y SMTP, antispam, antivirus, firma DKIM personalizada, Mail Time Machine para recuperar los correos de los últimos 15 días, auditoría de mensajes y migración gratuita de correos, contactos y calendarios.
• MailChannels SMTP: para el correo transaccional que envían tu tienda, tu CRM o tu sistema de facturación.

Una combinación habitual: el sitio y la mayoría de los buzones en el hosting compartido o en Hosting Empresas, y unas pocas cuentas Prime Email para las personas que manejan más correo o necesitan Outlook sincronizado. Si tu sitio usa ASP .NET, el hosting Windows también incluye cuentas de correo.

Si tu dominio .com.mx, .com.pe u otro ya está registrado, lo conectas a tu plan de Dongee cambiando sus DNS, sin necesidad de transferirlo. Los precios cambian según el periodo y la moneda: revisa siempre el valor vigente en la página de cada plan.

Errores comunes al contratar correo con tu dominio

• Registrar el dominio a nombre de una persona o de la agencia. Si esa persona se va, recuperar el dominio puede tardar semanas. Regístralo a nombre de la empresa.
• Dejar vencer el dominio. Cuando el dominio vence, se cae la web y también el correo. Activa la renovación automática; si ya te pasó, lee cómo recuperar un dominio vencido.
• Olvidar SPF, DKIM y DMARC. Es la causa más común de que los correos de una empresa nueva lleguen a spam.
• Cambiar los registros MX sin migrar antes. Los correos que estaban en el proveedor anterior quedan allá y los nuevos llegan al nuevo servidor; muévelos antes del cambio.
• Usar el correo del hosting para envíos masivos. Los boletines y campañas se envían desde una plataforma de email marketing; el buzón corporativo es para la comunicación del día a día.
• Elegir solo por el precio más bajo. Revisa el espacio por buzón, los backups del correo y si el soporte responde en español y a cualquier hora.

Preguntas frecuentes

¿Cómo contrato hosting con correos corporativos y dominio .com.mx para mi empresa?

Registra el dominio .com.mx a nombre de tu empresa, contrata un plan de hosting que incluya cuentas de correo, apunta los DNS del dominio a ese hosting y configura MX, SPF, DKIM y DMARC. En Dongee, el hosting compartido incluye 50 cuentas de correo con tu dominio desde 10 USD al mes.

¿Y si mi dominio es .com.pe?

El proceso es el mismo: registras el .com.pe con un registrador acreditado, lo conectas a tu hosting cambiando los DNS y creas los buzones desde el panel. El hosting no depende de la extensión del dominio.

¿Cuántas cuentas de correo corporativo necesito?

Al menos una por persona que atienda clientes y algunas por área (ventas, facturación, soporte). Con 50 cuentas incluidas en el hosting compartido de Dongee, la mayoría de las pymes tiene margen para crecer.

¿Qué diferencia hay entre el correo incluido en el hosting y un correo corporativo aparte?

El correo del hosting cubre lo esencial: buzones con tu dominio, webmail e IMAP. Un servicio como Dongee Prime Email añade más espacio por buzón (de 8 a 100 GB), auditoría de mensajes, recuperación de los correos de los últimos 15 días, roles de administración y, en Enterprise, Microsoft Exchange ActiveSync.

¿Puedo usar mi correo corporativo en Outlook y en el celular?

Sí. Las cuentas se configuran por IMAP y SMTP en Outlook, Apple Mail, Gmail para Android o iPhone. Si necesitas calendarios y contactos sincronizados, elige un plan con CalDAV y CardDAV o con Exchange ActiveSync.

¿Pierdo mis correos si cambio de proveedor?

No, si migras los buzones antes de cambiar los registros MX. Dongee hace la migración sin costo en el hosting compartido, la migración gestionada de web y correos en Hosting Empresas, y la migración gratuita de correos, contactos y calendarios en Prime Email.

¿Por qué mis correos corporativos llegan a spam?

Casi siempre faltan o están mal configurados los registros SPF, DKIM o DMARC, o el servidor tiene mala reputación. Revisa la configuración DNS y, si envías correos automáticos desde tu web o sistema, usa un servicio de envío transaccional.

¿Puedo pagar en pesos mexicanos o soles?

Los planes de Dongee muestran el precio en la moneda de tu país (por ejemplo MXN, PEN o COP) y en USD en los demás países.