Proyectos de n8n: Automatiza sin código

Actualizado el 07/10/2026 — Este artículo fue actualizado con información reciente y secciones nuevas.

Cuando un equipo pasa de 5 a 40 automatizaciones, el problema deja de ser técnico y pasa a ser de orden. Por eso mucha gente busca n8n project topic: quiere saber cómo clasificar workflows, separar permisos y no perderse en una lista interminable. Acá te explicamos cómo se resuelve con las herramientas reales de n8n y qué buenas prácticas conviene aplicar.

Un n8n project topic no es una función con nombre propio en n8n. Es la forma de referirse a organizar workflows por tema combinando tres herramientas: proyectos (separan accesos y credenciales), carpetas (agrupan workflows dentro de un proyecto) y etiquetas o tags (clasifican de manera transversal). Sirve para equipos que comparten una instancia y necesitan orden, permisos claros y búsqueda rápida.

¿Cómo se organizan los workflows en n8n?

En n8n los workflows se organizan en tres niveles: proyectos, carpetas y tags. El proyecto es el contenedor principal y define accesos y credenciales. Las carpetas agrupan workflows dentro de un proyecto. Los tags clasifican por tema y se usan para filtrar. Cada herramienta resuelve un problema distinto, y conviene no pedirle a una lo que hace otra.

Fijate cómo se reparten las responsabilidades:

• Proyecto: es el límite de seguridad. Dentro de él viven workflows y credenciales, y se asignan roles a cada usuario.
• Carpeta: es una estructura de árbol. Un workflow está en una sola carpeta a la vez, y las carpetas pueden anidarse.
• Tag: es una etiqueta plana. Un workflow puede tener varios, y sirven para filtrar la lista sin importar en qué carpeta esté.

Además, cada usuario tiene un proyecto personal donde guarda lo suyo. Los proyectos de equipo son los que se comparten. La disponibilidad de proyectos de equipo, la cantidad y los roles depende del plan o de la licencia. Chequeá la página de precios de n8n y la documentación de tu versión antes de diseñar la estructura.

¿Qué es un n8n project topic?

Un n8n project topic es el criterio temático con el que ordenás los workflows de un proyecto: facturación, CRM, notificaciones, agentes de IA. En n8n no hay un objeto llamado “topic”. Ese criterio se implementa con tags y carpetas, y el proyecto aporta el aislamiento de permisos. La documentación oficial no lo nombra así; es el término que usa la gente al buscar.

Dicho de otra manera: el tema es una decisión tuya, no un botón de la interfaz. La implementación práctica es esta:

• El tema grande va en el proyecto: “Ventas”, “Finanzas” o “IT Operations” se resuelven con proyectos, porque necesitan permisos propios.
• El subtema va en la carpeta: “Onboarding de clientes” o “Reportes semanales” agrupan workflows de un mismo proceso.
• El atributo transversal va en el tag: “CRM”, “Facturación” o “IA” cruzan carpetas y se usan para buscar.

Una aclaración que evita malentendidos: ni las carpetas ni los tags restringen el acceso. Si un usuario tiene rol en el proyecto, ve sus workflows. Para limitar quién ve qué, la herramienta correcta es el proyecto.

¿Qué roles y permisos hay en los proyectos de n8n?

n8n maneja dos niveles de roles. A nivel instancia existen Owner, Admin y Member. A nivel proyecto existen Project Admin, Project Editor y Project Viewer. Un mismo usuario puede tener un rol distinto en cada proyecto, por ejemplo editor en Marketing y solo lectura en Finanzas. Verificá en la documentación cuáles están incluidos en tu plan.

• Owner de la instancia: es quien instaló o administra la instancia y tiene control total.
• Admin de la instancia: gestiona usuarios y puede intervenir en los proyectos.
• Project Admin: administra el proyecto, sus miembros y su contenido.
• Project Editor: crea y modifica workflows y credenciales del proyecto, pero no gestiona miembros.
• Project Viewer: solo lectura. Es el rol indicado para auditores, consultores o stakeholders.

La regla de oro es el mínimo privilegio. Si alguien solo necesita mirar el estado de las automatizaciones, dale Viewer. Los incidentes por ediciones accidentales casi siempre vienen de dar Editor a todos “por comodidad”.

¿Cómo crear un proyecto y organizar workflows?

Para organizar workflows en n8n creás primero el proyecto, después invitás a los usuarios con su rol, armás las carpetas y por último asignás tags. Ese orden importa porque los permisos se definen arriba y el resto se hereda hacia abajo. Los pasos concretos son estos:

• Creá el proyecto: desde el panel lateral usá la opción de agregar un proyecto. Elegí un nombre que describa el área o el proceso, por ejemplo “Ventas” o “Finanzas”.
• Invitá a los miembros: en la configuración del proyecto asigná a cada persona el rol que necesita, no más.
• Armá las carpetas: creá una por proceso, como “Leads”, “Facturación” o “Alertas”. Evitá anidar más de dos niveles.
• Definí la lista de tags: acordala por escrito antes de empezar. Después asignalos desde cada workflow.
• Cargá las credenciales dentro del proyecto: así quedan aisladas y solo las usan los workflows de ese proyecto.
• Documentá cada workflow: usá notas (sticky notes) dentro del canvas para explicar qué hace, qué sistemas toca y quién es responsable.

Si ya tenés workflows sueltos, podés moverlos a un proyecto o carpeta. Después de mover un workflow, revisá las credenciales que usa. n8n te pide decidir cómo manejarlas al transferirlo, y un nodo con credenciales que el proyecto destino no puede usar va a fallar al ejecutarse.

¿Cuáles son las mejores prácticas de n8n?

Las mejores prácticas de n8n se agrupan en seis áreas: nomenclatura consistente, manejo de errores, workflows modulares, credenciales aisladas, versionado y operación del servidor. Aplicarlas desde el inicio evita tener que reordenar 60 workflows seis meses después. Ninguna requiere código complejo; casi todas son decisiones de organización y configuración.

¿Cómo nombrar proyectos, workflows y tags?

Elegí un criterio único de nombres y mantenelo en todo el equipo. Si los proyectos van por departamento, todos van por departamento. Para los workflows, un patrón simple como “Área – Acción – Sistema” (por ejemplo, “Ventas – Alta de lead – CRM”) permite entender qué hace cada uno sin abrirlo.

• Tags en un solo formato: “CRM”, “crm” y “Crm” aparecen como etiquetas distintas. Definí mayúsculas y singular o plural, y respetalo.
• Lista de tags aprobada: compartí un documento interno con cada tag y cuándo usarlo.
• Idioma único: no mezcles nombres en español e inglés dentro de la misma estructura.

¿Cómo manejar errores en los workflows de n8n?

La forma recomendada es crear un workflow dedicado a errores, que empiece con el nodo Error Trigger, y asignarlo en la configuración de cada workflow productivo. Cuando algo falla, ese workflow recibe los datos de la ejecución y puede avisarte por Slack, correo o el canal que uses.

• Un workflow de errores central: evita duplicar la lógica de alertas en cada automatización.
• Reintentos en nodos inestables: los nodos tienen una opción para reintentar si falla, útil con APIs externas que a veces no responden.
• Alertas con contexto: incluí el nombre del workflow, el nodo que falló y un enlace a la ejecución.

¿Conviene dividir los workflows en sub-workflows?

Sí, conviene cuando una lógica se repite o un workflow crece demasiado. Con el nodo Execute Workflow podés llamar a un workflow desde otro y reutilizar bloques, como “validar un CUIT” o “enviar notificación”. Un canvas de 80 nodos es difícil de leer, de probar y de mantener.

Un criterio práctico: si copiaste el mismo grupo de nodos dos veces, ya es hora de extraerlo a un sub-workflow.

¿Cómo cuidar las credenciales y los webhooks?

Guardá las credenciales siempre en el gestor de n8n, dentro del proyecto que las usa, y nunca las escribas dentro de los nodos o en campos de texto. Para los webhooks, activá algún tipo de autenticación en el nodo Webhook, porque una URL pública sin protección puede ser invocada por cualquiera.

• Una credencial por proyecto y por entorno: no uses la misma clave de producción para pruebas.
• Autenticación en webhooks: el nodo ofrece opciones como Basic Auth, header o JWT.
• Clave de cifrado resguardada: si hosteás vos, la variable N8N_ENCRYPTION_KEY cifra las credenciales. Si la perdés, no podés recuperarlas.
• Revisión periódica: auditá miembros y credenciales cada trimestre, sobre todo cuando alguien deja el equipo.

¿Cómo versionar y separar entornos en n8n?

n8n ofrece integración con Git (source control) y entornos para versionar workflows y moverlos entre desarrollo y producción. Esta función está incluida solo en los planes que la habilitan, así que confirmala en tu licencia. Si no la tenés, exportá los workflows como JSON de forma periódica y guardalos en un repositorio propio.

Sea cual sea el método, el objetivo es el mismo: poder volver atrás si un cambio rompe algo. Probá siempre en una instancia o proyecto de pruebas antes de tocar lo que corre en producción.

¿Qué configurar en el servidor si hosteás n8n?

Si hosteás n8n vos mismo, usá PostgreSQL como base de datos para producción en lugar de SQLite, limitá el historial de ejecuciones y programá backups. La instalación por defecto funciona para pruebas, pero una instancia con carga real necesita estos ajustes.

• Base de datos PostgreSQL: es más robusta que SQLite cuando hay muchas ejecuciones y usuarios.
• Limpieza de ejecuciones: las variables EXECUTIONS_DATA_PRUNE y EXECUTIONS_DATA_MAX_AGE permiten borrar ejecuciones viejas para que la base no crezca sin control.
• Modo queue para cargas altas: con Redis y workers separados, n8n reparte la ejecución entre varios procesos.
• Backups de la base y de la clave de cifrado: sin ambas, una restauración queda incompleta.
• HTTPS con proxy inverso: Nginx o Caddy delante de n8n, con certificado válido.
• Actualizaciones controladas: leé las notas de versión antes de actualizar y probá en un entorno aparte.

¿Cómo se combinan los proyectos con guardar y publicar?

En las versiones recientes, n8n separa guardar un cambio de publicarlo. Así podés editar un workflow sin afectar la versión que está corriendo, y publicar recién cuando esté probado. Combinado con proyectos, definís quién edita y quién tiene permiso para llevar cambios a producción, según el rol que le asignaste.

El flujo de trabajo sano para un workflow crítico es este:

• Editá sin tocar producción: hacé los cambios y probalos con datos de prueba, usando la opción de fijar datos (pin data) para no depender de sistemas externos.
• Revisá con otra persona: un segundo par de ojos detecta errores de lógica antes de publicar.
• Publicá en un horario tranquilo: evitá los picos de uso del proceso de negocio.
• Controlá las primeras ejecuciones: mirá el historial para confirmar que todo funciona.

Si tu versión todavía usa el interruptor clásico de activo e inactivo, el criterio es el mismo: no edites directamente workflows que corren cada pocos minutos. Duplicá el workflow, probá la copia y reemplazá cuando esté listo.

¿Qué estructuras de proyectos se usan en la práctica?

Las estructuras más comunes separan los proyectos por área de negocio y aíslan los casos sensibles, como finanzas. No hay una única forma correcta. Lo que sí se repite es que los datos y las credenciales delicadas quedan en proyectos con pocos miembros. Estos son cuatro ejemplos de armado que podés adaptar.

Proyecto de ventas y CRM

Un proyecto “Ventas” con carpetas como “Leads”, “Seguimiento” y “Reportes”. Los tags pueden ser “CRM”, “Notificaciones” y “En pruebas”. El equipo comercial edita, y el área de sistemas entra como Viewer para auditar. Las credenciales del CRM quedan solo en este proyecto.

Proyecto de agentes de IA

Los workflows con agentes de IA suelen usar claves de API de modelos y necesitan más pruebas. Separarlos en un proyecto propio permite controlar quién accede a esas claves. Los tags pueden indicar la función (“Chatbot”, “Resumen de documentos”) o el proveedor del modelo.

Proyecto de IT y operaciones

Monitoreo, alertas y scripts de mantenimiento. Solo el equipo técnico tiene acceso. Las carpetas pueden ser “Servidores”, “Backups” y “Alertas”. Es el lugar natural para el workflow central de errores que mencionamos antes.

Proyecto de finanzas y cumplimiento

Facturación, conciliaciones y reportes. Tiene los permisos más restrictivos: pocos editores y un Viewer para auditoría. Mantenerlo aislado reduce el riesgo de exponer datos financieros a quien no los necesita.

¿Qué errores son comunes al organizar n8n?

Los errores más frecuentes son usar un solo proyecto para todo, mezclar criterios de nombres, dar permisos de más y editar workflows en producción sin probar. Todos se evitan con decisiones tomadas al principio. Corregirlos después cuesta mucho más, porque implica mover workflows y reconfigurar credenciales.

• Un único proyecto para todo: obliga a dar permisos de más a mucha gente. Separá por área desde el inicio.
• Usar tags para controlar acceso: los tags no restringen nada. Si necesitás aislar, usá proyectos.
• Tags inconsistentes: variantes del mismo nombre fragmentan los filtros y vuelven inútil la clasificación.
• Mover workflows sin revisar credenciales: el workflow llega al destino, pero sus nodos pueden fallar.
• Editor para todos: reservá Viewer para quienes solo necesitan mirar.
• Sin workflow de errores: te enterás de las fallas cuando alguien del negocio reclama.
• Sin backups de la clave de cifrado: en self-hosting, perderla deja las credenciales ilegibles.

Comparativa: sin proyectos vs con proyectos

La diferencia principal entre una instancia sin estructura y una con proyectos, carpetas y tags está en el control de accesos y en la facilidad para encontrar cosas. La tabla resume los puntos que más se notan cuando el equipo crece.

Aspecto	Sin estructura	Con proyectos, carpetas y tags
Visibilidad de workflows	Una lista única para todos	Cada usuario ve los proyectos donde tiene rol
Credenciales	Mezcladas, difíciles de acotar	Aisladas por proyecto
Permisos	Los mismos para toda la instancia	Roles distintos por proyecto
Búsqueda	Solo por nombre	Por proyecto, carpeta y tag
Onboarding de personas nuevas	Hay que explicar todo	Acceso al proyecto relevante
Consultores externos	Acceso amplio o ninguno	Viewer en proyectos puntuales
Cambios en producción	Se editan directamente	Se prueban y se publican con criterio

¿Conviene hostear n8n en un VPS de Donweb?

Conviene si querés control sobre la instancia, los datos y los backups, y tenés a alguien que pueda administrar un servidor. Un VPS de Donweb te permite instalar n8n con Docker, elegir la base de datos y dimensionar recursos según la carga. Si preferís no administrar infraestructura, el servicio cloud de n8n es la alternativa más simple.

Estas son las ventajas concretas del self-hosting:

• Control de los datos: la información de tus workflows y credenciales queda en un servidor que administrás vos.
• Recursos a medida: ajustás CPU, RAM y disco según cuántos workflows corren y qué tan pesados son.
• Configuración completa: podés usar PostgreSQL, modo queue, limpieza de ejecuciones y las variables de entorno que necesites.
• Todo en un mismo proveedor: servidor, dominio y correo pueden convivir en la misma cuenta.
• Soporte en español: atención en tu idioma y en tu huso horario.

El costo es la responsabilidad. Con self-hosting te encargás de actualizar n8n, renovar certificados, monitorear el servidor y hacer los backups. Algunas funciones de equipo, como proyectos con roles, requieren una licencia de n8n. Consultá las condiciones vigentes en su documentación antes de planificar.

Un esquema de instalación típico incluye estos pasos:

• Preparar el VPS: instalá una distribución Linux actualizada y configurá acceso por SSH con claves.
• Instalar Docker: n8n publica imágenes oficiales y guías de despliegue con Docker Compose.
• Levantar n8n con PostgreSQL: usá volúmenes persistentes y definí la clave de cifrado desde el primer día.
• Publicar con HTTPS: poné un proxy inverso con certificado y apuntá tu dominio.
• Programar backups: guardá la base y la clave de cifrado fuera del servidor.
• Crear la estructura: recién ahí armá proyectos, carpetas y tags.

Preguntas frecuentes

¿Qué es un project topic en n8n?

Un project topic es el tema con el que organizás los workflows de un proyecto, pero n8n no tiene una función con ese nombre. Se implementa combinando proyectos para los permisos, carpetas para agrupar procesos y tags para clasificar y filtrar de forma transversal.

¿Los tags de n8n restringen el acceso a un workflow?

No, los tags no restringen el acceso. Solo sirven para clasificar y filtrar. Para limitar quién ve o edita un workflow tenés que usar proyectos y asignar roles a los usuarios dentro de cada uno.

¿En qué se diferencia una carpeta de un tag en n8n?

Una carpeta agrupa workflows en una estructura de árbol y un workflow solo puede estar en una. Un tag es una etiqueta plana: un workflow puede tener varios y sirven para filtrar sin importar la carpeta.

¿Qué roles existen dentro de un proyecto de n8n?

Los roles de proyecto son Project Admin, Project Editor y Project Viewer. El admin gestiona el proyecto y sus miembros, el editor modifica workflows y el viewer solo lee. Un usuario puede tener un rol distinto en cada proyecto.

¿Los proyectos están disponibles en todos los planes de n8n?

No, la disponibilidad y la cantidad de proyectos de equipo dependen del plan o de la licencia. Cada usuario tiene su proyecto personal, pero los proyectos compartidos con roles se habilitan según el plan. Verificá las condiciones vigentes en la página de precios y en la documentación de n8n.

¿Qué pasa con las credenciales si muevo un workflow a otro proyecto?

Las credenciales no acompañan al workflow de forma automática en todos los casos. n8n te pide decidir cómo manejarlas al transferirlo. Después de mover, revisá cada nodo que use credenciales y reconfigurá las que haga falta en el proyecto destino.

¿Cómo me entero cuando falla un workflow de n8n?

Creá un workflow de errores con el nodo Error Trigger y asignalo en la configuración de tus workflows productivos. Cuando uno falla, ese workflow recibe los datos de la ejecución y envía el aviso por el canal que elijas, como Slack o correo.

¿Qué base de datos conviene usar con n8n en producción?

Para producción conviene PostgreSQL. SQLite es la opción por defecto y alcanza para pruebas, pero con muchas ejecuciones y usuarios es más robusto usar PostgreSQL y configurar la limpieza de ejecuciones antiguas.

¿Qué tengo que respaldar en una instancia propia de n8n?

Tenés que respaldar la base de datos y la clave de cifrado (N8N_ENCRYPTION_KEY). Sin esa clave, las credenciales guardadas no se pueden descifrar al restaurar. Conviene guardar ambos backups fuera del servidor.

¿Puedo instalar n8n en un VPS de Donweb?

Sí, podés instalar n8n en un VPS de Donweb con Docker. Necesitás acceso por SSH, PostgreSQL, volúmenes persistentes y un proxy inverso con HTTPS. n8n publica guías oficiales de despliegue que podés seguir paso a paso.

¿Es mejor n8n self-hosted o el cloud de n8n?

Depende de si querés administrar infraestructura. El cloud de n8n evita el mantenimiento del servidor. El self-hosting en un VPS te da control sobre datos, recursos y configuración, a cambio de encargarte de actualizaciones, seguridad y backups.

Conclusión

Ordenar n8n por temas no depende de una función mágica. Depende de usar bien tres herramientas: proyectos para los permisos, carpetas para agrupar procesos y tags para buscar. Sumale buenas prácticas básicas, como workflow de errores, credenciales aisladas, backups y pruebas antes de publicar, y vas a poder crecer sin perder el control.

Si recién empezás, dedicá media hora a definir la estructura antes de crear el primer workflow. Y si vas a hostear n8n por tu cuenta, un VPS de Donweb te da una base sólida para armarlo a tu medida.

Fuentes

• Documentación oficial de n8n: secciones sobre proyectos, carpetas, tags, roles, manejo de errores, source control y configuración de entorno, disponibles en docs.n8n.io.
• Página de precios y licencias de n8n: para confirmar qué funciones incluye cada plan al momento de planificar tu implementación.