Apache Airflow 3 en un VPS: guía completa y CVE-2026-58076

Airflow es la herramienta que eligen los equipos de datos cuando quieren describir sus pipelines en Python puro: cada DAG es un archivo .py que define tareas, sus dependencias y su planificación. El ecosistema de providers es inmenso (bases SQL, S3, BigQuery, dbt, Spark…) y la comunidad, enorme. Los servicios gestionados facturan caro el entorno por hora; al autoalojar Airflow en un VPS obtienes el mismo motor por el coste de un servidor, y tus DAG se ejecutan cerca de tus fuentes de datos internas. También es una cuestión de control: versiones de los providers, dependencias Python propias, variables y conexiones, todo queda en tus manos. Airflow 3, versión vigente desde abril 2025 (3.3.0 en julio 2026, 3.3.1 en agosto 2026), aporta una arquitectura orientada a API: los workers ya no acceden a PostgreSQL directamente.

Airflow 3.0 introdujo rupturas importantes. Se han retirado los atributos schedule_interval, los SubDAGs y execution_date; los providers exigen Airflow 3.1 como mínimo desde mayo 2026. Si empiezas un proyecto nuevo, instala Airflow 3 directamente: el archivo docker-compose.yaml oficial ya está adaptado. Si mantienes DAG existentes que usan schedule_interval, execution_date o SubDAGs, quédate en la última versión 2.x y planifica la migración: la documentación oficial ofrece una guía de actualización desde Airflow 2.7 como mínimo. La imagen Docker sigue el mismo esquema: apache/airflow:3.3.1 para la rama estable actual, apache/airflow:2.11.0 para mantenerte en la rama 2.

Airflow es la pila más exigente de esta serie en configuración CeleryExecutor, porque ejecuta a la vez webserver, scheduler, worker(s), triggerer, un servidor de API interno, Redis y PostgreSQL. La documentación oficial recomienda 4 GB de RAM como mínimo, pero en la práctica cuenta con 4 vCPU y 8 GB para una carga cómoda. Prevé 16 GB si tus DAG cargan pandas o grandes volúmenes. Opta por el modo LocalExecutor (sin Celery ni Redis) si empiezas en un VPS de 4 GB: la pila se reduce a la mitad. También necesitarás Docker 24+ y Docker Compose v2 (no el antiguo docker-compose v1), 40 GB de disco SSD y un dominio apuntando a tu servidor.

Si has seguido los pasos anteriores con una imagen anterior a 3.3.1, estás afectado. CVE-2026-58076 (CVSS 8.8) afecta a Apache Airflow desde 3.0.0 hasta 3.3.0 incluida; la corrección está en 3.3.1. La capa de serialización reconstruía los nodos de excepción (airflow_exc_ser / base_exc_ser) importando una clase cuyo nombre procede del propio blob serializado y luego instanciándola con argumentos de esos mismos datos, sin restricción útil sobre lo que podía importarse. El executor_config de un operador alcanza esa ruta: un autor de DAG puede hacer que se cargue y ejecute un callable arbitrario. El scheduler pasa por ese código en su bucle normal al reconstruir los DAG serializados; el servidor de API pasa por él en una lectura autenticada, por ejemplo al mostrar el detalle de un DAG. La corrección de 3.3.1 restringe la clase importada a subclases de BaseException.

Para actualizar: cambia la etiqueta a apache/airflow:3.3.1 en tu docker-compose.yaml *y* en el FROM de tu imagen propia, después docker compose pull && docker compose up -d. Verifica con docker compose exec airflow-apiserver airflow version.

⚠️ Una actualización hecha por CVE-2026-33264 no basta: ese aviso cubría solo la rama trigger del mismo deserializador — es un punto de entrada distinto y su corrección no cierra este.

⚠️ El vector es el autor del DAG, no un visitante anónimo. Actualizar es necesario; la pregunta añadida es *quién puede dejar un archivo en ./dags y quién tiene cuenta en la interfaz*.

Si tienes DAG existentes, revisa estos puntos antes de actualizar la imagen. schedule_interval se ha eliminado: sustitúyelo por schedule. execution_date ya no está disponible en el contexto de las tareas: usa logical_date. Los SubDAGs se han retirado: migra a TaskGroups o a dynamic task mapping. Los XComs en pickle están desactivados por defecto: tus XComs deben ser tipos serializables en JSON. El acceso directo a la base de metadatos desde el código de tarea (vía Session o settings.engine) ya no funciona: pasa por los hooks oficiales de Airflow. El comando airflow db upgrade sustituye a airflow db init para actualizar un esquema existente.

PermissionError: [Errno 13] Permission denied: '/opt/airflow/logs/scheduler' — falta el archivo .env o AIRFLOW_UID no coincide con el UID del propietario de las carpetas montadas. Corrige con sudo chown -R $(id -u):0 ./dags ./logs ./plugins ./config y reinicia. The scheduler does not appear to be running (banner naranja en la interfaz) — comprueba que el contenedor airflow-scheduler está healthy (docker compose ps); si el banner persiste pero desaparece al recargar, es un falso positivo documentado en el tracker de Airflow, sin impacto funcional. error: invalid command 'webserver' — una dependencia Python instalada ha introducido un conflicto de importación al arrancar: reconstruye la imagen fijando las versiones.

Airflow 3 expone de forma nativa trazas OpenTelemetry: actívalas con AIRFLOW__METRICS__OTEL_ON=True y apunta a tu colector (Grafana Tempo, Jaeger). Para un panel rápido, Airflow también expone métricas Prometheus mediante el plugin airflow-exporter. Configura docker compose con una política de reinicio (restart: unless-stopped) para que la pila vuelva sola tras reiniciar el VPS. Mantén PostgreSQL actualizado por separado. Purga con regularidad los metadatos antiguos con docker compose exec airflow-scheduler airflow db clean --clean-before-timestamp 2025-01-01 para evitar el crecimiento de la base.