En apenas un mes, un servidor que nació para reunir servicios dispersos se ha convertido en mi laboratorio personal: un lugar donde aprendo infraestructura, recupero control sobre mis proyectos y exploro una nueva forma de trabajar con agentes de IA.
Hace aproximadamente un mes contraté un VPS. No lo hice porque tuviera una arquitectura perfectamente diseñada ni porque necesitara presumir de infraestructura propia. La motivación era bastante más sencilla: tenía servicios y proyectos repartidos entre distintas herramientas y plataformas, y quería reunirlos en un espacio sobre el que pudiera decidir yo.
Buscaba centralización, pero también control. Quería entender mejor dónde vivían mis proyectos, cómo se desplegaban, qué dependencias tenían y qué ocurría cuando algo fallaba. Había además motivos prácticos: experimentar, aprender, reducir costes donde tuviera sentido y mejorar la seguridad sin delegar todas las decisiones en terceros.
La idea sonaba clara. La realidad, como suele pasar, venía con muchas más capas.
Yo ya tenía algo de experiencia con Docker y redes, pero administrar un sistema completo era un reto nuevo. Saber levantar un contenedor no equivale a operar un servidor: de pronto hay que pensar en actualizaciones, accesos, copias de seguridad, monitorización, exposición de servicios y recuperación ante errores. Cada decisión abre otras tres.
Por eso el VPS no se ha convertido en un producto terminado. Es un proyecto reciente, todavía en evolución, y precisamente ahí está gran parte de su valor.
Quería un lugar propio, no otra colección de herramientas
Antes del VPS, mis proyectos estaban dispersos entre servicios y plataformas diferentes. Esa distribución puede resultar cómoda al principio: cada herramienta resuelve una parte del problema y evita ocuparse de la infraestructura. Sin embargo, con el tiempo también crea fragmentación. Hay que recordar dónde está cada cosa, cómo se conecta con las demás y qué límites impone cada proveedor.
Centralizar no significa alojarlo absolutamente todo en una sola máquina ni rechazar cualquier servicio externo. De hecho, n8n continúa por ahora en Railway y su migración es una tarea futura. Para mí, centralizar significa reducir la dispersión con criterio y disponer de un núcleo operativo propio.
Ese matiz es importante. No quiero que el VPS acabe siendo una colección de servicios instalados porque sí. Cada pieza debería tener un propósito: resolver una necesidad, permitirme aprender algo concreto o dar soporte a una comunidad o proyecto real.
Hoy ese espacio reúne mi web, herramientas personales, automatizaciones y un servidor de juego. También alberga OpenClaw, que ha cambiado la forma en la que organizo y desarrollo parte de este ecosistema.
Qué hay hoy en el VPS
- sermix.dev, mi espacio profesional y el lugar donde publico este artículo.
- Workout Tracker, una herramienta de uso personal.
- Project Zomboid, un servidor para una comunidad de unas 100 personas, con entre 20 y 30 jugadores activos.
- OpenClaw, como entorno de colaboración con agentes de IA.
- Automatizaciones, monitorización y copias de seguridad, que sostienen y vigilan el conjunto.
- n8n todavía no está aquí: sigue en Railway y tengo previsto abordar su migración más adelante.
La mayoría de estos servicios son personales. La excepción más visible es Project Zomboid, porque da servicio a una comunidad. Eso cambia la responsabilidad: cuando una herramienta deja de ser solo para uno mismo, la disponibilidad y los cambios ya no son cuestiones abstractas. Hay personas al otro lado.
Aprender infraestructura fuera del tutorial
Uno de los motivos principales para contratar el VPS era aprender, y en ese sentido ha cumplido desde el primer día.
Un tutorial suele presentar un recorrido limpio: se instala una herramienta, se configura y funciona. En un sistema real, en cambio, las piezas conviven. Una actualización puede afectar a un servicio; una regla de red puede bloquear otro; una copia de seguridad solo sirve si se sabe qué contiene y cómo restaurarla.
La lección más clara ha sido que Docker es una parte del sistema, no el sistema entero. Los contenedores ayudan a empaquetar y aislar servicios, pero no deciden por mí qué debo exponer, cómo vigilar el servidor o cómo recuperarme de un fallo.
También he entendido mejor la importancia de trabajar con cambios reversibles. Antes de tocar algo sensible, conviene saber cómo volver atrás. Del mismo modo, separar desarrollo y producción evita que una prueba inocente se convierta en una interrupción real. La observabilidad, las copias de seguridad y el cuidado con los secretos no son adornos que se añaden al final: forman parte del funcionamiento cotidiano.
No considero que haya resuelto definitivamente estas cuestiones. Estoy construyendo hábitos y mejorando el sistema poco a poco. El aprendizaje no consiste solo en hacer que un servicio arranque, sino en poder mantenerlo con responsabilidad.
La llegada de OpenClaw
Descubrí OpenClaw siguiendo las novedades de inteligencia artificial. Me llamó la atención y quise probarlo. Lo que empezó como una exploración ha terminado ocupando un lugar central en mi forma de trabajar con el VPS y con mis proyectos.
Defino a Froddybot como “mi fiel compañero de pair programming y mi asistente digital personal”. La frase tiene un componente afectivo, pero también describe bastante bien su función: no es un piloto automático al que entrego el control sin supervisión, sino un colaborador que puede mantener contexto, ayudarme a investigar un problema, ejecutar tareas dentro de unos permisos definidos y coordinar trabajo especializado.
El flujo suele comenzar con un objetivo expresado en lenguaje natural. Froddybot revisa el contexto disponible, plantea o ejecuta los pasos que entran dentro de su alcance, comprueba el resultado y resume lo ocurrido. Yo sigo validando las decisiones sensibles y cualquier publicación.
Esa combinación me resulta más útil que una conversación aislada con un chatbot. OpenClaw aporta continuidad, memoria y capacidad de actuar en el contexto real de los proyectos. También puedo acceder mediante Telegram, lo que acerca el entorno a mi día a día sin convertir esa comodidad en permiso ilimitado.
Un equipo de agentes, con responsabilidades distintas
A medida que el sistema ha crecido, la colaboración se ha organizado en varios agentes especializados:
- Froddybot coordina el trabajo y es mi interlocutor principal.
- Nexobot se ocupa del área web y de arquitectura.
- Lumenbot trabaja en contenidos e investigación editorial.
- Bastiónbot se centra en el VPS y la seguridad.
Esta división no pretende simular una empresa ni borrar mi responsabilidad. Sirve para separar contextos y aplicar criterios diferentes según la tarea. Revisar un texto, modificar una aplicación y analizar la seguridad de un servidor requieren capacidades y permisos distintos.
La especialización también evita que todo dependa de una única conversación interminable. Froddybot puede coordinar a los demás agentes, reunir sus resultados y presentarme una visión común. Yo conservo la decisión final allí donde importa.
La memoria aporta otra diferencia. Permite mantener convenciones, decisiones y contexto entre sesiones, siempre dentro de límites definidos. Esto reduce el tiempo dedicado a reconstruir desde cero por qué se tomó una decisión o cómo está organizado un proyecto.
Colaborar no significa ceder el control
La parte más interesante de trabajar con agentes capaces de ejecutar tareas es también la que exige más criterio: los permisos.
Mi intención no es construir una autonomía ciega. Las tareas rutinarias y claramente delimitadas pueden avanzar sin que yo tenga que aprobar cada paso mínimo. Leer contexto, revisar archivos, realizar comprobaciones o preparar una propuesta son ejemplos razonables.
En cambio, producción, DNS, firewall, secretos, borrados y otros cambios sensibles requieren autorización. No todas las acciones tienen el mismo riesgo, y tratarlas como si fueran equivalentes sería un error.
Esta forma de trabajar crea un equilibrio útil. Si todo requiere confirmación, la colaboración pierde fluidez. Si nada la requiere, se pierde control. El objetivo es que la autonomía sea proporcional al impacto y que siempre exista trazabilidad sobre qué se hizo, por qué y con qué resultado.
En la práctica, esa disciplina también mejora mi propia manera de trabajar. Obliga a definir mejor los objetivos, separar una propuesta de una aprobación y pensar en los límites antes de ejecutar.
Centralizar proyectos y también contexto
OpenClaw ha ayudado a reunir proyectos que antes estaban repartidos entre plataformas, pero su aportación no es únicamente técnica. También centraliza contexto: documentación, decisiones, tareas pendientes y formas de colaboración.
Esto no elimina las herramientas externas ni resuelve mágicamente la complejidad. Lo que hace es ofrecer un punto de coordinación desde el que puedo avanzar con más continuidad. En lugar de saltar entre conversaciones desconectadas, el trabajo puede conservar una historia y unas reglas.
Para alguien que utiliza el VPS como laboratorio, esa continuidad tiene mucho valor. Un experimento puede convertirse en una automatización útil; una incidencia puede transformarse en una lección documentada; una idea para la web puede pasar por investigación, desarrollo y revisión sin perder por el camino el propósito original.
También hay una dimensión de entretenimiento. Me interesa explorar hasta dónde puede llegar este modelo de colaboración, no solo para ser más productivo, sino porque aprender construyendo resulta divertido.
Lo siguiente
A corto y medio plazo quiero seguir desarrollando automatizaciones con IA que aporten valor real, entretenimiento y aprendizaje. También está pendiente la futura migración de n8n desde Railway, cuando tenga sentido abordarla con calma.
Quiero continuar mejorando la monitorización y las copias de seguridad. Son áreas poco visibles cuando todo funciona, pero decisivas cuando deja de hacerlo. Y quiero evolucionar los servicios existentes sin llenar el servidor de piezas que después no pueda mantener.
Un mes es poco tiempo. Sería exagerado presentar este VPS como una arquitectura madura o un caso de éxito definitivo. Hoy es algo más interesante para mí: un espacio propio en el que cada problema me obliga a aprender, cada servicio responde a una necesidad concreta y la inteligencia artificial empieza a convertirse en una colaboradora integrada en el trabajo cotidiano.
Contraté un servidor para centralizar herramientas. He acabado construyendo un laboratorio donde centralizo también aprendizaje, decisiones y colaboración. Apenas está empezando, pero ya ha cambiado mi forma de relacionarme con mis proyectos.
