Lo que cambia el archivado del repositorio AGPL de AppFlowy
AppFlowy tenía dos partes distintas: la aplicación cliente (Flutter + Rust, aún activa) y AppFlowy-Cloud, el servidor de colaboración multiusuario. Es este segundo repositorio — AppFlowy-IO/AppFlowy-Cloud — el que fue archivado el 11 de septiembre de 2026 por la organización.
La organización ahora dirige a los usuarios a AppFlowy-SelfHost-Commercial: un repositorio cuya base de código es propietaria. Todavía se puede desplegar AppFlowy como servidor, pero ya no bajo licencia libre. No se trata de un cambio de licencia en el mismo código: es una bifurcación comercial cerrada que reemplaza el repositorio público.
Para los equipos que citaban la licencia AGPL como condición de despliegue — requisitos de cumplimiento, política de TI, contratos con clientes — ese argumento desaparece de un día para otro.
Lo que no cambia — y lo que cambia de verdad
- La aplicación cliente AppFlowy sigue siendo código abierto (AGPL-3.0) y recibe actualizaciones regulares — v0.14.8 publicada el 8 de octubre de 2026.
- En modo individual o local, AppFlowy sigue funcionando: el archivado no deshabilita nada en el lado cliente.
- El servidor multiusuario ya no está bajo licencia libre: ninguna auditoría de seguridad externa puede cubrir la base de código comercial.
- Los parches de seguridad del lado servidor ya no se publicarán como código abierto. Un CVE en el servidor ya no puede verificarse de forma independiente.
- La comunidad que mantenía forks y plugins alrededor de AppFlowy-Cloud ha perdido su base.
- La migración forzada al servidor comercial introduce una dependencia del proveedor que AGPL precisamente buscaba evitar.
Docmost: lo que AGPL sigue cubriendo en 2026
Docmost es una base de conocimiento colaborativa publicada bajo AGPL-3.0 en github.com/docmost/docmost. Su modelo de distribución se parece a lo que AppFlowy prometía: un núcleo completamente libre, con extensiones comerciales opcionales para grandes organizaciones.
La edición Open Source cubre lo esencial: espacios y páginas jerárquicas, edición colaborativa en tiempo real, comentarios, historial de versiones, permisos granulares por espacio y soporte RTL (añadido en v0.96.0 — septiembre 2026). Sin límite de miembros, sin funciones bloqueadas detrás de un paywall en la edición base.
AppFlowy-Cloud AGPL vs Docmost — estado a 9 de octubre de 2026
Desplace la tabla
| Criterio | AppFlowy-Cloud (AGPL) | Docmost |
|---|---|---|
| Licencia servidor | AGPL-3.0 → archivado sept. 2026 | AGPL-3.0 activa |
| Repositorio servidor | Archivado (solo lectura) | Activo, v0.96.0 (sept. 2026) |
| Parches seguridad servidor | Sin más parches públicos | Publicados en GitHub |
| Colaboración tiempo real | Sí (cliente) | Sí (servidor + cliente) |
| Edición en navegador | Sí | Sí |
| Permisos por espacio | Limitado en AGPL | Incluido en edición libre |
| Historial de versiones | Sí | Sí |
| Soporte RTL (árabe) | Parcial | Completo desde v0.96.0 |
| Self-hosting Docker | AppFlowy-SelfHost-Commercial (propietario) | Docker Compose oficial |
Por qué un repositorio cliente activo no compensa el archivado del servidor
Un argumento habitual en los hilos de discusión: el repositorio principal AppFlowy-IO/AppFlowy — la aplicación de escritorio y móvil — sigue activo. Es cierto. Pero este argumento confunde la capa cliente y la capa servidor.
En un despliegue de equipo, el servidor gestiona la autenticación, la sincronización de datos, los permisos y el almacenamiento de páginas. Es el componente que recibe tus documentos. Es el componente que aplica las reglas de acceso. La aplicación cliente, por muy abierta que sea, no cambia la naturaleza del componente con el que se comunica.
Quedar en el último commit AGPL de AppFlowy-Cloud significa: sin correcciones de seguridad futuras, incompatibilidades progresivas con el cliente (que sigue evolucionando) y una base de código sin mantenimiento. Esta es la definición de deuda técnica a corto plazo.
Lo que dice la licencia AGPL sobre este caso
AGPL-3.0 exige que un servicio de red que modifica el código fuente distribuya sus modificaciones. No exige al editor continuar desarrollando un proyecto de código abierto. Un editor puede archivar un repositorio y pasar a un modelo comercial: eso es legal. Lo que AGPL garantiza es que el código ya distribuido sigue siendo redistribuible. Lo que no garantiza es que ese código recibirá parches de seguridad.
Migrar de AppFlowy a Docmost: qué planificar
AppFlowy y Docmost no comparten un formato de exportación nativo común. La migración más limpia pasa por la exportación en Markdown desde AppFlowy (disponible desde la interfaz cliente) y la importación en Docmost. Las imágenes y archivos adjuntos requieren tratamiento separado.
Docmost gestiona la importación de archivos Markdown y estructuras de páginas jerárquicas. Para volúmenes grandes, la importación masiva vía API es el camino más fiable.
Cuatro puntos a verificar antes de cambiar: la estructura de los espacios AppFlowy (un espacio = un espacio Docmost), las integraciones de terceros conectadas a AppFlowy-Cloud, los permisos asignados por grupo y los usuarios sin correo electrónico verificado que no pasarán el flujo de invitación estándar de Docmost.
Requisitos previos para alojar Docmost en un VPS
- Mínimo 2 vCPU y 4 GB de RAM — suficiente para un equipo de 20 a 50 miembros.
- Docker y Docker Compose instalados en el servidor.
- Un nombre de dominio con certificado TLS válido — Docmost no sirve tráfico HTTP plano.
- Un proxy inverso (nginx o Caddy) para terminar TLS y enrutar al contenedor Docmost.
- Un volumen persistente para la base de datos PostgreSQL y el almacenamiento de archivos adjuntos.
- Un servidor SMTP o relay de correo transaccional para las invitaciones del equipo.
Desplegar Docmost en un VPS en 5 pasos
Preparar el servidor
Conéctate a tu VPS por SSH. Instala Docker y Docker Compose:
curl -fsSL https://get.docker.com | sh apt install -y docker-compose-pluginVerifica que los puertos 80 y 443 están abiertos en tu firewall.
Obtener la configuración oficial
Clona el repositorio o descarga directamente el
docker-compose.ymldesde el repositoriodocmost/docmost:mkdir -p /opt/docmost && cd /opt/docmost curl -O https://raw.githubusercontent.com/docmost/docmost/main/docker-compose.yml curl -O https://raw.githubusercontent.com/docmost/docmost/main/.env.example cp .env.example .envConfigurar las variables de entorno
Edita
.envy establece como mínimo:-
APP_URL: tu dominio (https://wiki.your-domain.com)
-APP_SECRET: una cadena aleatoria larga (genera conopenssl rand -hex 32)
-DATABASE_URL: mantén el valor por defecto si usas el PostgreSQL del Compose
-SMTP_HOST,SMTP_PORT,SMTP_USERNAME,SMTP_PASSWORD: tu relay de correoIniciar los contenedores
docker compose up -dDocmost arranca con PostgreSQL y Redis. Verifica que los tres contenedores están en estado
Up:docker compose psEl primer acceso mediante tu dominio activa el asistente de creación de cuenta de administrador.
Configurar el proxy inverso TLS
Apunta tu nombre de dominio a la IP del VPS. Con nginx, añade un vhost que enrute al puerto interno de Docmost (por defecto
3000) y termina TLS con Let's Encrypt:apt install -y certbot python3-certbot-nginx certbot --nginx -d wiki.your-domain.comReinicia nginx. Docmost es accesible por HTTPS.
Notion / Docmost / AppFlowy — lo que pagas realmente
Desplace la tabla
| Herramienta | Coste servidor (equipo 20) | Licencia código servidor | Actualizaciones seguridad |
|---|---|---|---|
| Notion Business | $400/mes (IA incluida) | SaaS propietario | Responsabilidad de Notion |
| AppFlowy + servidor comercial | Infraestructura + licencia editor | Propietario (desde sept. 2026) | Responsabilidad del editor |
| Docmost Open Source | Solo coste VPS | AGPL-3.0 | Publicadas en GitHub, auditables |
| Docmost Business | Coste VPS + licencia Business | AGPL-3.0 (núcleo) | Publicadas en GitHub, auditables |
Lo que el archivado de AppFlowy dice sobre el modelo open-core
AppFlowy no es el primer proyecto en dar este paso. El patrón está documentado: una herramienta comienza bajo licencia permisiva o copyleft, gana popularidad, recibe financiación y progresivamente reserva el código del servidor. Lo que ilustra este archivado es el límite del modelo open-core cuando el núcleo comercial es el servidor.
La distinción que importa para un responsable técnico: un proyecto cuyo editor obtiene ingresos de la licencia del servidor tiene un interés directo en hacer ese servidor difícil de sustituir. Un proyecto cuyo editor obtiene ingresos de las ediciones Enterprise — construidas sobre un núcleo de código abierto estable — tiene interés en mantener ese núcleo en buen estado. Esta es la tensión que AGPL intenta reducir.
Docmost sigue el segundo modelo. Su núcleo AGPL es la base sobre la que los equipos depositan su confianza al elegir el autoalojamiento.
Verificar la salud de un proyecto de código abierto antes de migrar
Antes de migrar una base de conocimiento de equipo a una herramienta autoalojada, tres señales a verificar: la frecuencia de commits en el repositorio servidor (no solo el cliente), la política de publicación de CVE y el modelo de negocio del editor. Un proyecto sin ingresos o cuyos ingresos provienen exclusivamente del SaaS tiene poco incentivo para mantener la versión autoalojada. Un proyecto cuyos clientes de pago se autoalojan tiene un fuerte incentivo.
Docmost en producción: puntos a tener en cuenta
Docmost es estable en producción desde finales de 2025. Algunos puntos antes de un despliegue en equipo.
Copias de seguridad: los datos residen en PostgreSQL y en el volumen de almacenamiento de archivos. Una copia de seguridad diaria automatizada de ambos es suficiente. pg_dump programado vía cron, y rsync o snapshot S3 para los adjuntos.
Actualizaciones: Docmost publica lanzamientos regulares — aproximadamente uno al mes en 2026. El procedimiento es un docker compose pull seguido de docker compose up -d. Las migraciones de esquema se aplican al arranque. Lee las notas de versión antes de actualizar.
Autenticación SSO: Docmost soporta SAML 2.0 y OIDC en las ediciones Business y Enterprise. La edición Open Source gestiona autenticación por correo electrónico e invitaciones.
Rendimiento: en 2 vCPU / 4 GB RAM, Docmost maneja cómodamente 20 a 50 miembros activos simultáneamente. Más de 100 miembros con espacios de uso intensivo requiere 4 vCPU / 8 GB y un nodo PostgreSQL dedicado.
Por qué alojar Docmost en un VPS dedicado en lugar de hosting compartido
- Docmost requiere Docker: el hosting compartido no lo ofrece.
- PostgreSQL debe ser accesible desde el contenedor: la mayoría de los planes compartidos no dan acceso a un PostgreSQL local.
- Los volúmenes persistentes para archivos adjuntos deben sobrevivir a los reinicios: un VPS con almacenamiento NVMe ofrece esta garantía.
- El acceso root es necesario para configurar el proxy inverso TLS y las reglas del firewall.
- La escalabilidad vertical de un VPS — añadir RAM o CPU sin migración — cubre el crecimiento del equipo sin reestructurar la infraestructura.
