Dónde alojar una API: Projects o VPS según tu backend

Si tu app necesita guardar datos, iniciar sesiones o ejecutar lógica propia, probablemente necesita una API accesible desde Internet. La decisión de alojamiento no depende de si el frontend está hecho con Flutter, React Native, React o una herramienta de IA: depende de qué proceso ejecuta el backend y de quién quieres que lo opere.

En Hostbrid hay dos recorridos habituales para una API: Projects, que construye desde un repositorio y ejecuta un servicio compatible, y un VPS, donde administras el sistema y la pila. Esta guía te ayuda a descartar opciones antes de contratar. Para apps móviles, consulta también la guía de alojamiento de API para iOS y Android.

Elige Projects si tu API encaja con el servicio

Projects puede ser el camino más directo si tienes un repositorio Git, el backend arranca como servicio Node.js o contenedor compatible, y prefieres delegar la construcción y publicación. Conectas GitHub, GitLab o Bitbucket y puedes revisar el estado y los registros del despliegue. Los servicios que permanecen activos requieren el plan y los recursos correspondientes; confirma las condiciones actuales en la página de Projects.

Antes de elegirlo, identifica el comando de inicio, el puerto que debe escuchar el proceso, las variables de entorno y los servicios externos que espera. Confirma también dónde se guardan los datos persistentes y si el proceso necesita tareas programadas, acceso al sistema o volúmenes que el plan no incluya. No subas secretos al repositorio.

Elige un VPS si necesitas administrar el sistema

Un VPS te da acceso root para instalar runtimes, Docker Compose, un proxy, workers o herramientas del sistema. Es adecuado cuando el despliegue depende de configuración que debes controlar o cuando quieres decidir cómo se conectan varios procesos.

Ese control incluye trabajo: actualizaciones, firewall, usuarios y permisos, certificados, monitorización, copias externas y pruebas de restauración. Un VPS no administra automáticamente la API ni convierte una configuración insegura en segura. Si no quieres asumir esa operación, considera Projects para un backend compatible o pide ayuda antes de contratar.

Compara lo que necesita tu aplicación

Lo que tienes que ejecutar	Primera opción que conviene revisar	Qué confirmar antes de pagar
Frontend estático, sin proceso de servidor propio	Projects	Comando de build, carpeta de salida, rutas y llamadas a servicios externos
API Node conectada a Git	Projects	Runtime, comando de inicio, puerto, variables, persistencia y recursos del plan
Backend con Dockerfile	Projects o VPS	Compatibilidad del contenedor y almacenamiento; VPS si necesitas controlar el host
Docker Compose con varios servicios	VPS o Projects según el soporte del proyecto	Red, datos persistentes, consumo, copias y límites del plan
Python, PHP u otro runtime con dependencias del sistema	VPS, salvo que la oferta de Projects confirme ese runtime	Versión, bibliotecas del sistema, proceso de arranque y mantenimiento
Base de datos de producción	Servicio gestionado compatible o instalación operada por ti	Copias, restauración, acceso privado, almacenamiento y política de actualizaciones

La tabla es una orientación, no una garantía de compatibilidad universal. Revisa la documentación y las condiciones vigentes del producto para tu runtime y plan exactos. Si una app necesita una base de datos, no supongas que publicar su API también publica, migra o respalda los datos.

Haz este inventario antes de elegir

Abre el repositorio y anota:

Cómo arranca: busca package.json, Dockerfile, compose.yaml, pyproject.toml u otros ficheros de runtime; identifica el comando de producción, no solo el servidor de desarrollo.
Qué escucha: la API debe aceptar el puerto asignado por el entorno y responder por una URL HTTPS pública. localhost dentro del móvil apunta al propio teléfono, no al servidor.
Qué datos conserva: separa base de datos, ficheros de usuario, caché, colas y logs. Decide quién hace copias y cómo restaurar una muestra.
Qué credenciales usa: guarda claves privadas en variables del servidor. Una variable incluida en el bundle de iOS o Android puede extraerse y no es un secreto.
Qué permisos aplica: cada endpoint debe comprobar identidad, permisos y datos recibidos en el servidor. Ocultar un botón en la app no protege la operación.
Qué carga esperas: mide memoria, CPU, disco y peticiones simultáneas con una prueba representativa antes de escoger recursos.

Comprueba la API antes de conectar la app

Publicar una página de estado 200 no demuestra que el flujo de usuario funcione. Desde una conexión externa, prueba al menos una ruta pública, una ruta autenticada y respuestas esperadas para sesión caducada, datos inválidos y límite de peticiones. Comprueba HTTPS, DNS, logs y que una caída de la base de datos no exponga información sensible.

En la app móvil, cambia la dirección de desarrollo por el dominio de producción y prueba un build de release en iOS y Android. No publiques claves privadas; conserva en el servidor las credenciales de bases de datos, pagos y servicios externos. Si además hay una web frontend, configura CORS para los orígenes necesarios: CORS no autentica la API ni protege las peticiones de apps nativas.

Para una guía completa del backend de FastAPI autogestionado, sigue Uvicorn y Nginx en un VPS. Para una API Node, revisa cómo publicar una aplicación Node.js. Si no sabes todavía si tu código es estático o necesita un servidor, empieza por diagnosticar una API que funciona en localhost pero falla en producción.

El siguiente paso

Si el backend es compatible y quieres desplegarlo desde Git, revisa Projects. Si necesitas acceso root o control de Docker y del sistema, compara VPS disponibles y administra tú las actualizaciones y copias. Si aún no sabes qué runtime tiene tu proyecto, comparte el comando de inicio y los servicios que requiere con soporte antes de comprar. No envíes tokens, contraseñas ni datos personales de usuarios.