FRENES

Guía · Avanzado · 12 min

Alojar un agente de IA en un VPS: servidor, instalación, seguridad, copias de seguridad y costos

Aloje un agente de IA en un VPS: elija el servidor, configure un acceso privado, proteja las claves y prepare copias de seguridad, restauración y presupuesto.

Por ·

Un servidor alquilado dibujado como una cabaña sobre pilotes, con la puerta cerrada con candado y una copia de seguridad debajo

Para alojar un agente de IA en un VPS, instale su entorno de ejecución en un servidor con mantenimiento al día, mantenga privada la interfaz de administración y prepare un procedimiento de restauración antes de asignarle tareas reales. Puede seguir accediendo al modelo mediante una API: alojar el agente no implica alojar el modelo. El presupuesto debe incluir el servidor, las llamadas al modelo, los servicios adicionales y el tiempo de mantenimiento.

Requisitos previos y arquitectura propuesta

Esta guía utiliza OpenClaw como ejemplo práctico. Los criterios para elegir el servidor, separar permisos y recuperar el servicio también se aplican a las soluciones de nuestro directorio de agentes de IA, aunque sus comandos de instalación sean distintos.

Antes de empezar, prepare lo siguiente:

  • un VPS nuevo con una distribución Linux que siga recibiendo mantenimiento;
  • una cuenta de administración accesible mediante una clave SSH;
  • acceso a la consola de recuperación del proveedor de alojamiento;
  • una cuenta del sistema dedicada al agente;
  • una clave API exclusiva para este despliegue;
  • un destino para las copias de seguridad fuera del VPS;
  • una persona responsable que pueda detener el servicio y revocar sus accesos.

La arquitectura propuesta es sencilla: su computadora se conecta al VPS por SSH; la interfaz del agente solo escucha en la dirección de bucle local; el agente llama al modelo y utiliza las herramientas autorizadas. No necesita publicar su panel de control en Internet.

Un VPS mantiene el servicio disponible cuando su computadora está apagada. A cambio, añade una máquina que debe administrar: actualizaciones de seguridad, espacio en disco, supervisión, renovación y recuperación tras una avería. Si nadie puede asumir estas tareas, compare primero las opciones de alojamiento administrado antes de trasladar datos.

Por último, defina una primera tarea de alcance limitado, como analizar documentos guardados en una carpeta específica y generar un borrador. Los envíos, las eliminaciones y los cambios en cuentas deberán esperar hasta que haya validado este funcionamiento básico.

Elegir el servidor según las tareas que ejecutará

Distinga los recursos que consume el agente de los que necesitan sus herramientas. Un bucle que espera la respuesta de una API, un navegador automatizado y una compilación no utilizan el servidor de la misma forma. La documentación de alojamiento Linux de OpenClaw es el punto de partida para los requisitos específicos del producto.

CriterioAgente con modelo remotoAgente con navegador o cálculoAgente con modelo local
ProcesadorCoordinación y procesamiento de respuestasPáginas, scripts y procesos simultáneosInferencia y herramientas en paralelo
MemoriaEstado y servicios de la aplicaciónNavegador y procesos secundariosPesos del modelo y contexto
AlmacenamientoConversaciones, archivos y registrosCachés y archivos generados adicionalesModelos y datos de la aplicación
RedDependencia de la APIAPI y sitios consultadosDescargas y servicios externos
DimensionamientoMedir una tarea representativaMedir los picos de ejecución simultáneaEvaluar el modelo antes de contratar

No considere que una determinada capacidad de VPS sea un mínimo válido para todos los casos. Mida el consumo con las herramientas que vaya a utilizar y deje margen para los picos de actividad y el mantenimiento. Un promedio de memoria aceptable puede ocultar que el servicio se detenga durante una tarea más exigente.

Compare también las posibilidades de ampliar el disco, los límites de tráfico, la disponibilidad de una red privada y las opciones para recuperar los datos. Compruebe que las dependencias sean compatibles con la arquitectura del procesador, especialmente las extensiones nativas y los navegadores.

La ubicación del servidor no describe todo el recorrido de la información. Identifique por separado los destinos del modelo, las herramientas, las copias de seguridad y la supervisión. Que el servidor esté en el país elegido no obliga automáticamente a los demás servicios a procesar allí los datos.

1. Preparar Linux y conservar el acceso de recuperación

Actualice el sistema antes de instalar la aplicación. Después, cree un usuario exclusivo para el servicio, sin concederle permisos de administración de forma permanente. La cuenta que mantiene el servidor y la que ejecuta las tareas deben tener responsabilidades distintas.

Pruebe la conexión mediante clave en una segunda sesión antes de modificar la autenticación SSH. Mantenga abierta la primera sesión y compruebe que la consola de recuperación funciona. Desactivar demasiado pronto una vía de acceso puede convertir una operación rutinaria en un trabajo de recuperación del servidor.

En Ubuntu, los siguientes comandos proceden de la documentación oficial del cortafuegos, consultada el 24 de octubre de 2026:

sudo ufw allow 22
sudo ufw enable
sudo ufw status verbose

Estos comandos presuponen que SSH utiliza el puerto indicado. Si su configuración es distinta, adapte la regla antes de activar el cortafuegos. Revise también las reglas de red del proveedor de alojamiento: constituyen una capa independiente.

Habilite únicamente los accesos necesarios. El hecho de que un agente consulte una API o recoja trabajos de una cola no significa que deba aceptar conexiones públicas a la aplicación. Compruebe también la exposición a través de IPv6.

Por último, documente la preparación en una ficha de despliegue: distribución, usuarios, accesos autorizados, ubicación de los datos y procedimiento de recuperación. Esa ficha debe permitir reconstruir el servidor sin depender del historial del terminal.

2. Instalar el agente con el procedimiento oficial

Para este recorrido, utilice la instalación nativa desde la cuenta dedicada al agente. La documentación de instalación de OpenClaw, comprobada el 24 de octubre de 2026, proporciona este comando:

curl -fsSL https://openclaw.ai/install.sh | bash

El comando descarga y ejecuta un script remoto. Revíselo antes de utilizarlo en un servidor que ya contenga datos sensibles. Evite añadir permisos de administrador por costumbre: cada solicitud de privilegios debe responder a una operación concreta del sistema.

El asistente configura el acceso al proveedor. Utilice una clave exclusiva para este servidor y aplique las restricciones que ofrezca el proveedor. No copie todo su entorno personal: sus conexiones y archivos de autenticación probablemente conceden más acceso del que necesita el agente.

La guía oficial de primeros pasos explica después cómo instalar el servicio y comprobar su estado. Si la pasarela está ejecutándose en primer plano, detenga esa instancia con Ctrl+C antes de instalar el servicio:

openclaw gateway install
openclaw gateway status

En Linux, este procedimiento instala un servicio de usuario. Compruebe que siga funcionando después de cerrar la sesión y después de reiniciar el VPS. Obtener una respuesta durante la sesión de instalación no demuestra que el servicio vaya a mantenerse activo en esas situaciones.

Anote la versión instalada y las opciones de configuración elegidas. El instalador puede cambiar: para reconstruir el entorno más adelante, deberá recuperar una configuración compatible, en lugar de suponer que ejecutar el mismo comando producirá un resultado idéntico. La guía de referencia de OpenClaw amplía los ajustes de la aplicación.

3. Acceder a la interfaz sin publicarla en Internet

Mantenga la pasarela en la dirección de bucle local y abra un túnel desde su computadora. La documentación de acceso remoto proporciona este comando:

ssh -N -L 18789:127.0.0.1:18789 user@gateway-host

Sustituya user@gateway-host por su usuario y su servidor. Los puertos corresponden al ejemplo oficial consultado el 24 de octubre de 2026; ajústelos si ha cambiado la configuración.

Deje abierto el túnel y acceda desde el navegador a esta dirección local:

http://127.0.0.1:18789/

Complete la autenticación que solicite la pasarela. El túnel transporta la conexión, pero no justifica eliminar los controles de acceso de la aplicación.

A continuación, compruebe el resultado desde fuera: la dirección pública del VPS no debe permitir acceder al panel de control. Revise la configuración de escucha y las reglas de red, en lugar de dar por hecho que todo está protegido porque el túnel funciona.

Si más adelante utiliza un contenedor, repita esta comprobación. La documentación de Docker para Ubuntu advierte que los puertos publicados pueden eludir las reglas de UFW. Por tanto, un contenedor no convierte automáticamente su interfaz en privada.

Compartir el acceso mediante HTTPS requiere una configuración adicional: autenticación, ajustes del proxy inverso y control de usuarios. No publique el panel de control solo para facilitar la primera conexión.

4. Limitar herramientas, credenciales y usuarios

La cuenta del sistema dedicada al agente limita los posibles daños, pero no basta por sí sola. Un agente capaz de leer todos los documentos de esa cuenta y conectarse a Internet sigue teniendo la posibilidad de filtrar información. Aplique el principio de mínimo privilegio tanto a los archivos como a las cuentas externas.

Prepare una lista de las acciones necesarias. Para cada una, indique a qué datos podrá acceder, qué destino estará autorizado y si necesitará aprobación. Una tarea de clasificación de documentos no exige acceso general al terminal, al correo y a las copias de seguridad.

El entorno aislado o sandbox se aplica a la ejecución de las herramientas. Instalar la pasarela en un contenedor no demuestra que cada comando que ejecute disponga del aislamiento adecuado. Revise los directorios montados, los permisos de escritura y los accesos de red.

Mantenga las credenciales fuera de las instrucciones y los documentos que reciba el modelo. Separe las claves por entorno, proteja los archivos de autenticación y prepare su revocación. Considere también que los registros y las exportaciones de diagnóstico pueden contener información sensible.

La documentación de seguridad de OpenClaw ofrece una auditoría:

openclaw security audit

Revise los resultados antes de añadir integraciones. Esta auditoría no sustituye el análisis de los permisos que exige su actividad. La guía para proteger un agente de IA ayuda a documentar estas decisiones.

Por último, trate las páginas, los mensajes y los documentos consultados como datos no confiables. Una inyección de instrucciones puede intentar desviar el uso de una herramienta aunque esté correctamente instalada. Las restricciones técnicas deben seguir aplicándose cuando el modelo reciba una instrucción engañosa.

5. Guardar copias fuera del VPS y probar la restauración

Defina primero qué necesita recuperar: configuración, estado de las tareas, archivos de trabajo, conexiones y dependencias externas. Una imagen del sistema y una exportación de la aplicación cubren necesidades distintas; prepare ambas si su procedimiento de recuperación lo requiere.

La documentación de copias de seguridad de OpenClaw propone:

openclaw backup create --verify

El archivo local puede contener credenciales y no está cifrado por el mero hecho de estar comprimido. Protéjalo y transfiera una copia cifrada fuera del VPS. Compruebe las condiciones necesarias para mantener la coherencia de los datos almacenados; la documentación exige, por ejemplo, detener la pasarela para ciertas copias que utilizan PostgreSQL.

Para restaurar un archivo local, el procedimiento oficial utiliza un directorio de preparación:

openclaw backup restore <archive.tar.gz> --target <fresh-directory>

Sustituya los parámetros indicados entre signos angulares. El directorio de destino debe estar vacío o no existir. La extracción no reactiva el servicio automáticamente: la activación es una operación independiente.

La prueba de recuperación debe ir más allá de extraer el archivo. En un entorno aislado, compruebe los documentos, las rutas, los permisos y una tarea que no produzca efectos externos. Mantenga desactivadas las conexiones de producción para evitar que la copia restaurada procese las mismas solicitudes que el servidor activo.

Elija la frecuencia de las copias según la cantidad de trabajo que pueda permitirse perder y mida el tiempo necesario para restablecer el servicio. Conserve los medios de descifrado fuera del VPS. Una copia a la que solo pueda acceder con las credenciales perdidas durante la avería no sirve como recurso de recuperación.

6. Supervisar y actualizar sin perder el control

Que el proceso esté disponible no demuestra que el agente esté cumpliendo su tarea. Supervise por separado la máquina, la pasarela y los resultados. Un servicio puede seguir activo aunque solo reciba errores de autenticación o genere respuestas inutilizables.

Seleccione señales que permitan actuar:

  • saturación de la memoria y espacio libre en disco;
  • errores del proveedor y tiempos de espera agotados;
  • tareas bloqueadas, repetidas o abandonadas;
  • consumo de API por tarea;
  • fecha de la última transferencia correcta de una copia de seguridad.

Asocie cada alerta con una acción y una persona destinataria. Priorice los mensajes que permitan decidir si hay que detener, diagnosticar o recuperar el servicio, en lugar de acumular notificaciones sin orden de prioridad.

Antes de actualizar, lea los cambios, haga una copia de seguridad y prepare la vuelta al estado anterior. Preste especial atención a las migraciones de datos: volver a la versión anterior del programa puede no ser suficiente si ha cambiado el almacenamiento. Después, pruebe una tarea representativa y compruebe las restricciones de acceso.

Prepare también un procedimiento de incidentes que pueda consultar sin recurrir al agente. Debe explicar cómo suspender los desencadenantes, detener el servicio, conservar la información de diagnóstico y revocar las credenciales desde un dispositivo seguro.

Cuando retire el servicio de forma definitiva, exporte los datos útiles, revoque las claves y elimine los accesos adicionales. Cancelar el VPS no cierra necesariamente las cuentas de API, el almacenamiento externo ni las integraciones asociadas.

Presupuestar el servidor y el uso real

Compare las ofertas de alojamiento con un presupuesto fechado que incluya renovación, impuestos aplicables, almacenamiento, tráfico y copias de seguridad. Una tarifa promocional no refleja el costo a largo plazo. Añada el tiempo dedicado a las actualizaciones, los incidentes y las restauraciones.

ConceptoQué genera el costoControl previsto
VPSTiempo y capacidad contratadaRevisión del dimensionamiento
Modelo remotoEntradas, salidas y opciones facturadasMedición por tarea y límites
Herramientas externasBúsquedas, navegación o procesamientoCuotas por integración
Copias de seguridadVolumen, conservación y restauraciónPolítica de conservación
OperaciónMantenimiento e incidentesResponsable y procedimiento

Como ejemplo de cálculo, Claude Sonnet 5.5 figura a 2 dólares por millón de tokens de entrada y 10 dólares por millón de tokens de salida, según los precios recogidos por el sitio en octubre de 2026. Si se supone un consumo de un millón de tokens de entrada y un millón de salida, el resultado es de 12 dólares, antes de añadir los demás conceptos.

Esta hipótesis no representa un consumo medio. Un agente puede realizar muchas llamadas, volver a introducir los resultados de las herramientas en el contexto y repetir una acción después de un fallo. Por eso, mida el costo de una tarea terminada, incluidos sus intentos fallidos.

La calculadora de precios de LLM ayuda a comparar distintos supuestos. Establezca también una duración máxima, un límite de ejecución simultánea y condiciones de parada: una alerta de gasto no siempre interrumpe un bucle.

El artículo ¿Cuánto cuesta realmente un agente de IA al mes? amplía este análisis del presupuesto. Para decidir la capacidad del servidor, relacione siempre el gasto con los resultados aceptables, en lugar de fijarse solo en el número de tareas iniciadas.

Problemas frecuentes

La interfaz no se abre. Compruebe primero el estado de la pasarela y después el túnel y su puerto local. Busque un posible conflicto con un servicio que ya esté ejecutándose en su computadora. Abrir el puerto público del VPS no permite diagnosticar el problema.

El servicio se detiene al cerrar la sesión. Revise el servicio de usuario instalado y las reglas del gestor de servicios que determinan si permanece activo. Reproduzca el problema cerrando una sesión y, después, mediante un reinicio programado.

El modelo responde, pero las herramientas fallan. Examine los permisos de la cuenta del servicio, las rutas y las credenciales disponibles en su entorno. Una sesión SSH interactiva puede disponer de autorizaciones que el servicio no tiene.

El servidor se vuelve lento. Identifique el recurso saturado antes de contratar más capacidad. Una espera de red, demasiadas tareas simultáneas en el navegador y un disco lleno requieren soluciones distintas.

La factura sube sin obtener más resultados. Busque reintentos automáticos, solicitudes duplicadas y llamadas repetidas. Antes de volver a ejecutar una acción interrumpida, compruebe si ya produjo algún efecto externo.

La restauración parece completa, pero nada funciona. Revise las rutas, las dependencias y la activación del estado restaurado. Tener el archivo de copia no garantiza que los servicios externos y sus permisos sigan disponibles.

Lista de comprobación antes de las primeras tareas reales

  • El servidor y sus dependencias reciben actualizaciones de seguridad.
  • Se han comprobado el acceso SSH y la consola de recuperación.
  • El agente utiliza una cuenta dedicada y claves que pueden revocarse.
  • El panel de control es inaccesible desde Internet.
  • Los archivos y las herramientas autorizados corresponden a la tarea.
  • Las acciones sensibles requieren aprobación.
  • El servicio sigue funcionando después de cerrar la sesión y reiniciar.
  • Existe una copia de seguridad cifrada fuera del VPS.
  • Se ha ejecutado una tarea después de una restauración en un entorno aislado.
  • Se han definido límites de gasto y de ejecución simultánea.
  • Las alertas llegan a una persona capaz de intervenir.
  • Está disponible el procedimiento para detener y reconstruir el servicio.

Páginas relacionadas

Preguntas frecuentes

¿Se puede alojar un agente de IA sin GPU?

Sí, si se accede al modelo mediante una API remota: en ese caso, el servidor ejecuta el agente y sus herramientas. La GPU se necesita principalmente para la inferencia local, cuyos requisitos deben evaluarse por separado.

¿Un VPS garantiza la confidencialidad de las conversaciones?

El VPS le permite controlar el entorno de ejecución, pero el proveedor del modelo recibe el contenido enviado a su API. También debe revisar los accesos del proveedor de alojamiento, las copias de seguridad y los servicios conectados.

¿Hace falta un nombre de dominio para acceder al agente?

Un túnel SSH permite acceder a una interfaz privada sin necesidad de un dominio. Un dominio resulta útil para organizar un acceso HTTPS compartido o recibir determinados eventos externos.

¿Se pueden instalar varios agentes en el mismo VPS?

Sí, siempre que se separen sus cuentas, credenciales y datos. Si los usuarios no confían entre sí, conviene utilizar entornos independientes en lugar de limitarse a separar las conversaciones.

¿Se puede trasladar un agente a otro proveedor de alojamiento?

Prepare una exportación del estado de la aplicación y conserve el procedimiento de instalación. La migración también debe contemplar las credenciales externas, las rutas de archivos y las conexiones con servicios de terceros; copiar el disco no siempre basta.

Otras guías

Neutralidad. Ningún enlace de afiliación. Ningún editor paga por ser evaluado, puntuado o clasificado. Las evaluaciones las dirige François Chollet, neutrales y factuales, y cada dato está fechado y con su fuente. Cómo puntuamos