No es una frase para abrir con gancho. Es lo que de verdad pensé hasta muy cerca de la fecha límite. El 13 de julio de 2026 Google Cloud me emitió la certificación Associate Cloud Engineer (se abre en una pestaña nueva). Vale tres años. Algunas personas verán aquí una tontería: un examen más, un badge más. Para mí no lo fue. Esta es esa historia, contada sin disfrazarla de caso de éxito.

Un rol técnico sin red

Entré como manager de ingeniería de datos sin una trayectoria previa en el apartado técnico de Google Cloud. No partía de cero en datos ni en tecnología, pero GCP no formaba parte de mi zona de confort. Respeto mucho a todos mis compañeros que han trabajado en el pasado para construir lo que es hoy nuestra nube de integraciones, pipelines y cantidad ingente de datos estructurados. Pero eso era parte de lo bonito del reto de aceptar esta posición.

Salió la oportunidad de presentarme al examen. Había una fecha límite. La empresa, Barceló (se abre en una pestaña nueva), ofreció pagar la prueba y la formación asociada. Eso cambia el peso de la decisión: ya no era solo un objetivo personal. Alguien estaba invirtiendo tiempo y dinero en que yo lo intentara.

El síndrome del impostor hizo el resto

Prácticamente cuando llegaba el final del plazo para presentarme al examen, decidí no presentarme a esa convocatoria y esperar unos meses más. No me veía preparado. El síndrome del impostor funciona así: convierte lagunas normales de aprendizaje en una sentencia. Si no lo sé todo, no debería sentarme delante del examen. Si un compañero responde con naturalidad, yo no debería estar en esa conversación.

Llegué a un punto de bajón en el que la opción más cómoda era no ir. No suspender. Directamente no presentarme. Solo tenía que pasar el mal trago de intentar justificar de alguna forma con la empresa mi no convocatoria.

Pau

En ese camino no estuve solo. Un compañero de trabajo al que considero prácticamente un amigo, Pau, también se presentó al examen y lo aprobó. Él sí tiene experiencia como ingeniero de datos, entró a nuestro equipo al terminar la carrera sin ningún acercamiento al mundo laboral y a los pocos meses se quedó sin mentor y como único ingeniero en el equipo interno. Lo que Pau nos demostró a todos es que, con pasión, constancia y actitud, se puede con todo.

Me apoyó desde el principio. Preguntas que yo sentía ridículas, las trató como lo que eran: el sitio por el que se empieza. Hicimos sesiones en línea de muchas horas, los dos en los laboratorios de Google, fuera de horario laboral y muchas de esas, en fin de semana. De hecho, como anécdota, guardo un recuerdo muy bonito y gracioso gracias a un programa que tengo (y desconocía que tenía esa funcionalidad) que graba un clip de unos segundos cuando detecta una risa exagerada. Perdonadme la expresión, pero aún estando jodidos, siempre sacamos un hueco para el humor y el buen rollo. Me guió paso a paso. Me enseñó lo que podía enseñarme. Y cuando yo quería no presentarme, me insistió y animó a hacerlo.

Ese empujón final también fue suyo. Si esta historia se cuenta solo como “yo decidí presentarme”, queda coja. La decisión fue mía. El acompañamiento, no.

Un arrebato de sensatez

Al final no fue un plan perfecto ni una curva de confianza impecable. Fue un arrebato de sensatez: presentarme con lo que tenía, en la fecha que había, en lugar de esperar a sentirme merecedor.

Aprobé.

No voy a convertir eso en una moraleja de que “el síndrome del impostor se vence así”. No se vence del todo. Lo que sí puedo decir es que valió la pena. Tengo la certificación, y eso no me convierte de la noche a la mañana en un experto en Google Cloud. Sí deja una imagen de seriedad y de compromiso: conmigo y con la empresa, que confió en mí.

Una certificación no sustituye los años de práctica que Pau ya tenía. Tampoco borra lo que aún no sé. Lo que hace, al menos en mi caso, es otra cosa: obliga a recorrer un mapa, a sentarse, a no abandonar cuando la duda pide aplazamiento, y a devolver algo de lo que te han dado. Y creo que, lo más importante, aparte de que me ha ayudado a aprender mucho sobre arquitectura, despliegues, redes, bases de datos, infraestructura, integraciones y un largo etcétera, me ha hecho acercarme más a este maravilloso mundo.

Qué es, y qué no es, este badge

El Associate Cloud Engineer (se abre en una pestaña nueva) evalúa la capacidad de montar un entorno, planificar e implementar una solución, operarla y configurar acceso y seguridad en Google Cloud. Para mí el valor no está en memorizar el temario. Está en haberme sentado a hacerlo sin sentirme listo, con ayuda real, y en poder señalar el resultado de forma verificable. El badge está en Credly. Quien quiera comprobarlo, puede.

Si alguien está en un sitio parecido —un rol que pide más cloud del que uno cree tener, una fecha límite, ganas de no ir— no tengo un método que vender. Solo esto: a veces el siguiente paso no es sentirse preparado. Es presentarse. Y, si puedes, no hacerlo solo.

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.