Dónde alojar una aplicación web: la opción adecuada según su situación

Seis familias de hosting

Una aplicación web es código que responde a las peticiones, una base de datos que guarda el estado y, a menudo, tareas en segundo plano. Cada familia de hosting se encarga de una parte.

• Las herramientas de creación con IA publican por sí mismas: Lovable en una dirección lovable.app, con un backend integrado (base de datos, inicio de sesión de los usuarios, archivos), Bolt en una dirección bolt.host, Replit con cuatro tipos de despliegue.
• Las plataformas de despliegue (Vercel, Netlify) construyen la aplicación en cada envío de código, la distribuyen desde su red y ejecutan el código de servidor en forma de funciones.
• Los PaaS (Render, Railway, Fly.io) ejecutan en sus contenedores los servicios que usted declara: servidor web, worker, tarea programada, base de datos.
• El cloud (AWS, Google Cloud, DigitalOcean) ofrece un catálogo de piezas que usted ensambla: máquinas, bases de datos gestionadas, almacenamiento, colas de mensajes.
• El VPS no administrado le da un servidor, con acceso root: todo lo que ocurre en él le corresponde a usted.
• El VPS administrado es el mismo servidor, explotado por el proveedor, que lo mantiene al día, lo vigila e interviene.

La comparativa, criterio por criterio

La primera tabla muestra lo que queda a su cargo; la segunda, lo que paga y dónde viven sus datos (tarifas y documentación publicadas en octubre de 2026).

Lo que usted gestiona, la base de datos, las tareas en segundo plano

Familia	Lo que usted gestiona	Base de datos	Tareas en segundo plano, procesos permanentes
Herramientas de creación con IA	La aplicación, dentro del marco de la herramienta	Integrada (Lovable) o conectada, como Supabase	Según la herramienta (máquina reservada y despliegues programados en Replit)
Plataformas de despliegue	El código y su configuración	En un proveedor externo (Neon, Supabase, Upstash a través del marketplace de Vercel)	Funciones de duración limitada: en Vercel, 300 s por defecto, 800 s en Pro (1.800 s en beta); procesos permanentes en beta
PaaS	El código, los servicios, su tamaño	Ofrecida por la plataforma, facturada aparte	Workers y tareas programadas, declarados como servicios
Cloud	La arquitectura completa: red, máquinas, accesos	Servicio gestionado o base de datos en una máquina	Todo, ensamblando los servicios
VPS no administrado	El servidor: sistema, seguridad, copias de seguridad, supervisión	En el servidor, ajustada y respaldada por usted	Tantos como permita la memoria
VPS administrado	Su código; el proveedor explota el servidor	En el servidor, respaldada por el proveedor	Tantos como permita la memoria, vigilados por el proveedor

La factura, los datos, la salida

Familia	Factura	Ubicación de los datos	Portabilidad
Herramientas de creación con IA	Suscripción; en Lovable, el backend integrado consume créditos	En la plataforma y sus proveedores	Código sincronizado con GitHub (Lovable); el backend integrado se migra aparte
Plataformas de despliegue	Suscripción y después uso: en Vercel Pro, 20 USD al mes por miembro que despliega, con 20 USD de uso incluidos	Funciones en una región (iad1 por defecto en Vercel), base de datos en su proveedor	Código estándar; los servicios propios de la plataforma se sustituyen
PaaS	Por recurso: en Railway, 20 USD por vCPU y 10 USD por GB de memoria, al mes	Una región a elegir (cinco en Render)	Sencilla con un Dockerfile
Cloud	Servicio por servicio; en AWS, transferencia saliente facturada más allá de 100 GB gratuitos al mes	La región que usted elija	Según los servicios empleados
VPS no administrado	Un precio por tamaño; transferencia a veces facturada más allá de un volumen incluido (0,01 USD por GiB en DigitalOcean)	El centro de datos del servidor	Total: software estándar, acceso root
VPS administrado	Un precio mensual por tamaño, explotación incluida	El centro de datos del servidor; copias de seguridad fuera de la máquina	Total: su código y sus datos siguen siendo suyos

Tres criterios que conviene mirar de cerca

La factura que sigue al tráfico

En una plataforma facturada por uso, el precio de un mes depende de lo que la aplicación hizo ese mes. En Vercel, una vez consumido el crédito incluido, el tiempo de procesador de las funciones, su memoria, las regeneraciones de páginas y las transformaciones de imágenes se facturan por unidad; en Fly.io, las máquinas se pagan por segundo. Ideal para empezar en pequeño, este modelo pide vigilar el panel de control cuando la aplicación crece. En un VPS, un pico de tráfico consume los recursos del servidor y la factura no cambia: la cuestión pasa a ser la de un tamaño que aguante sus picos, con margen.

Las tareas en segundo plano y los procesos permanentes

Workers de colas de tareas, robots de sincronización, conexiones en tiempo real, tareas programadas: muchas aplicaciones tienen esta segunda vida. Las plataformas de despliegue se construyen en torno a funciones de duración limitada, y Vercel ofrece los procesos permanentes en beta (Vercel Daemons). Los PaaS los declaran como servicios aparte, un background worker o un cron job en Render. En un servidor, son procesos como los demás, que el sistema lanza y vuelve a lanzar.

La ubicación de los datos

En Vercel, las funciones se ejecutan por defecto en la región iad1 (Washington), y la documentación recomienda situar la base de datos en la misma región: cada ida y vuelta hacia una base de datos lejana se paga en latencia. En un VPS, la aplicación y su base de datos comparten la misma máquina, en un centro de datos identificado, algo que suelen exigir los clientes profesionales y los contratos que regulan los datos personales.

Según su situación

Su situación	El hosting que le corresponde
Un prototipo, una demo, una idea que probar	El hosting de la herramienta de creación, o la oferta gratuita de una plataforma (en Vercel, la oferta Hobby está reservada a un uso personal y no comercial)
Una aplicación que tiene sus primeros usuarios	Un VPS administrado; un PaaS si su equipo desarrolla y despliega por sí mismo
Una aplicación de negocio: datos de clientes, un equipo que depende de ella	Un VPS administrado: datos en un lugar identificado, copias de seguridad, supervisión con intervención
El desarrollador se ha ido, o la aplicación se creó con IA	Un VPS administrado, con la toma de control y la migración de lo existente
Un equipo técnico que quiere conservar el control	Un VPS, con una asistencia para las preguntas que se salen del día a día
Un sitio sobre todo estático, con un tráfico mundial muy variable	Una plataforma de despliegue y su red de distribución

Mientras la aplicación sirve para mostrar una idea, la herramienta que la creó la publica con un clic. La elección de un hosting llega con los primeros usuarios: datos que proteger, una factura que prever.

En cuanto la aplicación tiene usuarios y nadie en el equipo está llamado a administrar un servidor, la respuesta es el VPS administrado: la aplicación funciona en un servidor reservado para ella, con su base de datos, sus tareas en segundo plano y sus recursos, y el proveedor lo explota por usted. Una administración proactiva sigue también la propia aplicación (errores, lentitud, consultas costosas, espacio en disco) y le recomienda la corrección, que aplica usted o su asistente de IA. ¿El desarrollador se ha ido? Retoma lo existente tal como está, migración incluida.

Un equipo que administra por sí mismo saca el máximo partido de un servidor del que conserva el control: el VPS Pro de Simafri incluye la Asistencia integral, un diagnóstico que va desde el sistema hasta el código de la aplicación.

Cambiar de hosting sin empezar de cero

La elección de hoy se revisa mañana, siempre que la aplicación siga siendo portable:

• El código en un repositorio git suyo. Lovable lo sincroniza con GitHub, desde donde se despliega en otro lugar.
• La configuración en variables de entorno, inventariadas: claves de API, dirección de la base de datos, secretos.
• Una base de datos estándar (PostgreSQL, MySQL), que se exporta y se vuelve a importar con sus herramientas habituales.
• Los servicios propios de una plataforma, identificados de antemano (almacenamiento de archivos, tareas programadas declaradas en su configuración): son ellos los que se sustituyen.

Next.js es un buen ejemplo: su documentación indica que un servidor Node.js lanzado con next build y después next start admite todas sus funcionalidades, en cualquier proveedor que ejecute Node.js.