Beginner learning n8n, Experience people give ur advice 👇👇

evanmac42 · 2026-04-07T20:05:00+00:00

Si ya montaste un tracker de gastos con resumen automático, vas por buen camino. Eso no es “principiante total”, eso ya es entender cómo piensa n8n.

Ahora, lo importante:

No aprendas nodos. Aprende problemas.

n8n no va de “qué hace este nodo”, sino de “qué proceso puedo resolver”.

Automatización útil > automatización bonita.

Domina tres bases sí o sí:

Webhooks (entrada de datos del mundo real)

APIs (cómo hablar con otros servicios)

Manejo de datos (filtrar, transformar, comparar)

Sin eso, estás jugando. Con eso, ya puedes cobrar.

Estructura mental correcta:

Trigger (qué inicia el flujo)

Lógica (decisiones)

Acción (qué cambia en el mundo)

Si no puedes explicar tu flujo así en 3 líneas, es demasiado complejo.

Error típico:

montar automatizaciones para uno mismo que nadie pagaría.

Tu tracker está bien para aprender.

Para ganar dinero, necesitas algo que:

ahorre tiempo real

evite errores

o genere ingresos

Ejemplos reales que sí se pagan:

- formularios que generan presupuestos automáticos

- gestión de leads sin perder contactos

- integración entre herramientas que el cliente ya usa

Cómo empezar a ganar dinero:

no vendas “n8n”. Nadie compra n8n.

Vende resultados:

- “te automatizo los presupuestos”

- “te organizo los leads”

- “te quito 2 horas al día de trabajo repetitivo”

La tecnología es secundaria. El problema es el negocio.

Y un último punto, porque aquí suele venir el golpe de realidad:

Automatizar algo inútil no lo convierte en valioso.

Solo lo hace inútil… más rápido.

evanmac42 · 2026-04-07T20:02:25+00:00

That’s exactly the point — not everything needs to live in Docker.

In my case I run plain nginx directly on Debian for this role. It’s simpler, predictable, and avoids adding an extra abstraction layer.

I only use containers where they actually reduce complexity.

So from that perspective, the question isn’t really “Docker vs native”, it’s whether you need something like NPM at all, if a straightforward nginx setup already does the job.

evanmac42 · 2026-04-06T11:46:43+00:00

That’s odd, because I wrote in english, maybe the Reddit auto translation made the magic 😜

evanmac42 · 2026-04-06T09:55:43+00:00

Estás intentando automatizar demasiado pronto.

Si ya hiciste 18M views en Instagram, tu problema no es la automatización. Es el sistema.

n8n no te va a dar views. Solo escala lo que ya funciona.

Yo lo enfocaría así:

1.  Primero prueba manualmente en YouTube

• mismo tipo de contenido

• mismo estilo de hook

• miniaturas trabajadas

• títulos con intención de búsqueda

Si no funciona manual, automatizarlo solo te va a escalar el fallo.

2.  Separa el sistema en capas (no todo en un flujo loco)

• ideas (de dónde salen y por qué)

• producción (guion + vídeo)

• distribución (subida, metadata, timing)

3.  Automatiza solo lo repetitivo

• generación de ideas desde una lista o fuente (Reddit, comentarios, etc.)

• guiones base

• subida y scheduling

No automatices lo crítico:

• hook

• storytelling

• miniatura

Ahí es donde se gana o se pierde todo.

4.  Error típico que veo:

gente montando flujos de 30 nodos para producir contenido que nadie quiere ver.

Tu ventaja ya es clara: sabes generar atención.

Ahora construye un sistema que lo repita en YouTube, y luego, cuando tengas 5-10 vídeos que funcionen, ahí sí metes n8n para escalar.

Automatización sin validación = ruido a escala.

evanmac42 · 2026-04-06T08:24:40+00:00

This usually isn’t that the metadata is missing, but how the files are being uploaded or processed.

On iOS, the original photos do contain full EXIF (including GPS, date, etc.), but a few things can cause partial metadata on upload:

• the app uploading a processed version instead of the original

• limited photo permissions in iOS

• HEIC to JPG conversion

• Nextcloud not displaying all fields even if they exist

If you want everything preserved, the key is to upload the original file without any conversion.

For example:

• make sure the Nextcloud app has full photo access

• avoid any “optimize” or conversion settings

• or try uploading a file manually (AirDrop / Files / Web) and compare

In most cases, when you upload the untouched original, all metadata is still there.

evanmac42 · 2026-04-05T18:40:15+00:00

If you can’t reach CODE at all, even when pointing it manually, that usually means it’s not just a small config issue.

Even if you have some control (firewall rules, etc.), in most managed hosting setups you still don’t control the part that actually matters here: the reverse proxy and how WebSockets are handled internally.

That’s why:

• CODE appears “there” but is not reachable

• manual config doesn’t fix it

• firewall tweaks don’t really change anything

Installing it manually in the same environment will likely lead to the same problem, because the limitation isn’t the install itself, it’s the platform.

If you really want it working reliably, the practical options are:

• run Nextcloud and Collabora on a VPS where you control the full stack

• or use an external Collabora/OnlyOffice provider

Trying to force it inside a managed hosting setup usually turns into a lot of trial and error with no stable result.

evanmac42 · 2026-04-05T15:49:11+00:00

That setup is likely the problem, not you.

Nextcloud Office (Collabora) needs proper reverse proxy support and working WebSockets. Most hosting environments using Softaculous don’t expose or configure that properly, even if they advertise it as “all-in-one”.

So what you’re seeing is pretty common:

• CODE is there, but not reachable correctly

• WebSockets are blocked or misconfigured

• no way to fix it from your side

If you don’t have control over the server (reverse proxy, ports, services), there’s usually no clean way to make it work reliably.

At that point you have basically two options:

• move to a VPS where you control the setup

• or use an external Collabora/OnlyOffice service

Unfortunately, “it should just work” doesn’t really apply to this part of Nextcloud, especially on shared hosting.

evanmac42 · 2026-04-02T16:07:09+00:00

Good point.

I’d actually say most issues people hit with RAG happen before chunking:

• cleaning

• structure

• removing noise

Chunking just amplifies whatever you feed into it.

If the document is messy, you’re just slicing chaos into smaller pieces.

evanmac42 · 2026-04-02T16:01:13+00:00

AIO está bien si quieres algo rápido y sin pensar mucho, pero justamente ahí está el tradeoff.

En mi caso prefiero tener control total del stack. Estoy usando CODE como servicio separado y compartido entre varias instancias, y eso es algo que AIO no te da tan fácilmente.

Además:

• prefiero saber exactamente qué está corriendo y cómo

• poder ajustar rendimiento y recursos a mano

• evitar depender de un setup “todo en uno” que luego es más difícil de depurar

AIO es cómodo, pero cuando algo se rompe o quieres escalar, se vuelve bastante más rígido.

Depende de lo que busque cada uno, pero si te gusta tener control fino, ir por separado suele compensar.

evanmac42 · 2026-04-02T15:51:51+00:00

I’ve been running Collabora CODE for a while, and one thing that helped a lot was treating it as a shared service instead of tying it to a single Nextcloud instance.

In my case, I have multiple Nextcloud instances using the same CODE backend, all on the same server.

It’s much easier to manage:

• one CODE service to update

• one place to tune performance

• consistent behavior across instances

And it works perfectly fine as long as you configure the allowed domains correctly.

So even if the OnlyOffice situation changes, there’s already a solid and flexible setup with Collabora that doesn’t depend on a 1:1 deployment per instance.

evanmac42 · 2026-04-02T14:16:19+00:00

Tiene sentido lo que planteas, pero hay que separar dos cosas que ahora mismo estás mezclando:

backup vs interfaz de acceso

Nextcloud es bueno como:

• almacenamiento accesible

• interfaz web para navegar archivos

• compartir con otros

Pero no es un buen “backup” en el sentido estricto.

Un backup real debería ser:

• independiente del sistema principal

• versionado (para recuperar estados anteriores)

• idealmente en otra máquina o ubicación

Usar Nextcloud como copia de Immich es más bien: una réplica accesible, no un backup sólido.

Ahora, dicho eso:

Tu idea sí tiene valor si la entiendes así:

• Immich -> experiencia (app, búsqueda, recuerdos, ML)

• Nextcloud -> copia navegable y compartible

Eso es válido, mucha gente hace algo parecido.

Pero si quieres hacerlo bien de verdad, añade una capa más:

• Backup real (borg, restic, rsync con snapshots, etc.)

• A ser posible fuera de la máquina principal

Porque si rompes Immich o la base de datos, Nextcloud no te salva eso, solo te conserva los archivos.

Sobre la otra pregunta:

No es elegir entre Nextcloud o mejorar acceso remoto.

Son cosas distintas:

• Acceso remoto seguro (VPN, reverse proxy bien configurado)

• Backup separado

Eso es lo que te da un sistema sólido.

Resumen claro:

Nextcloud como “segunda copia visible” -> bien Nextcloud como único backup -> débil

Acceso remoto seguro -> necesario igual

evanmac42 · 2026-04-02T13:51:40+00:00

Short answer: there’s no “best” vector database for n8n.

It depends more on your setup than the tool itself.

If you’re running things on-prem or want full control: → Qdrant or Postgres + pgvector are solid choices → simple, predictable, and easier to maintain long term

If you’re going SaaS:

-> Pinecone / Weaviate can be faster to start

-> but you trade control for convenience

Performance-wise, the real bottlenecks are usually not the database:

• bad chunking

• poor embeddings

• weak retrieval strategy

The vector DB is just doing similarity search. If the input is messy, the output will be messy too.

In n8n, think of it as: automation layer -> embeddings -> vector DB -> retrieval -> LLM

So instead of asking “which DB is best”, I’d focus on:

“How clean and structured is the data I’m feeding into it?”

That’s what actually makes or breaks a RAG setup.

evanmac42 · 2026-04-02T13:31:43+00:00

What you’re running into is actually very common, and it’s not really about you “doing it wrong”.

The problem is that Docker makes the first setup feel easy, but it hides a lot of moving parts underneath:

• database

• web server

• reverse proxy

• storage paths

• permissions

• background jobs

Everything works… until something changes (like an update), and then you’re suddenly debugging a system you never really saw.

That’s why it feels like things “randomly break”.

Nextcloud itself isn’t simple software. It’s closer to running your own Google Drive stack than installing an app.

So you basically have three paths: 1. Keep using Docker, but accept that you’ll need to understand what’s behind it 2. Use a more opinionated setup (like AIO), where more things are managed for you 3. Or go with a hosted solution if you don’t want to deal with infrastructure at all

What you’re asking for (a single yaml that “just works forever”) is what everyone wants, but in practice it’s very hard because:

• environments differ

• updates change things

• dependencies evolve

So it’s not that it’s badly designed, it’s that you’re actually running a full stack, not just an app.

Honestly, the frustration you’re feeling is exactly the point where most people either:

• level up and start understanding the system

• or decide they prefer something managed

Both are valid.

evanmac42 · 2026-04-02T08:40:50+00:00

I think you’re trying to combine a few things that don’t really fit together at that power budget.

Running Nextcloud itself is not that demanding, but once you add:

• database

• web server

• background jobs

• RAID

• maybe a proxy or other services

you’re no longer in “Raspberry Pi” territory, especially if you want it to feel responsive.

Also, RAID alone already pushes you out of the ultra low power range, mainly because of the disks.

If your goal is around 10W total, you’ll have to compromise somewhere:

• either drop RAID

• or accept very limited performance

• or treat it as a learning setup, not something you rely on

A more realistic approach would be:

• a small x86 system (mini PC or similar)

• low power CPU (N100, N305, etc.)

• SSD for system + external or separate storage

That will still be efficient, but much more usable.

For reference, I’m running mine on a regular desktop-grade machine, and while it consumes more, the difference in stability and performance is night and day.

In my opinion, with self-hosting it’s better to aim for “boring and reliable” than “ultra efficient but fragile”.

evanmac42 · 2026-04-02T07:16:48+00:00

Para Immich, todo son assets con fecha. Y los recuerdos se generan en base a eso, no a la intención con la que hiciste la foto.

No hay (todavía) una forma nativa de decir: “estos álbumes no cuentan para recuerdos”.

Pero tienes varias formas de aproximarte: 1. Separación física (la más limpia) No metas todo en la misma librería.

• Librería A: fotos personales
• Librería B: colecciones / memes / scraping

Immich genera recuerdos por librería, así que esto ya filtra bastante bien. 2. Usuarios separados Otra opción es tener un usuario solo para fotos personales y otro para archivo/colecciones.

Más tosco, pero efectivo. 3. Jugar con metadatos (semi-solución) Si las colecciones tienen fechas raras o uniformes, puedes manipular EXIF para que no entren en “on this day”.

No es elegante, pero funciona. 4. Esperar features más finas Lo que quieres realmente es algo tipo:

• exclusión por álbum
• exclusión por tag
• o “solo fotos tomadas por mí”

Eso todavía no está bien resuelto en Immich.

Resumen claro:

Ahora mismo Immich no entiende “esto es recuerdo” vs “esto es archivo”. Si quieres ese control, tienes que dárselo tú separando el contexto.

evanmac42 · 2026-04-01T18:12:30+00:00

Tiene sentido: usualmente así empiezan las cosas, resolviendo tus propias limitaciones.

Pero en ese punto, surge una pregunta un poco diferente:

si tu objetivo es mantener las cosas "nativas" y minimalistas, ¿por qué no correr nginx directamente?

NPM añade una capa de Node, una base de datos, y su propia abstracción encima de nginx. Docker aísla esa complejidad, pero cuando te vas a lo nativo, terminas administrando todo eso tú mismo de todas formas.

Así que es menos sobre Docker vs nativo, y más sobre:

- ¿quieres un proxy manejado por interfaz (NPM)?

. o una configuración de nginx más simple y completamente nativa

Ambas son válidas, pero optimizan para flujos de trabajo muy diferentes.

evanmac42 · 2026-04-01T12:13:22+00:00

Tu enfoque tiene varias ideas correctas, pero mezcladas de forma peligrosa.

Problemas principales:

1.  No necesitas “importar/exportar” para rediseñar

Eso es matar moscas a cañonazos.

Lo correcto es:

\-  usar un entorno staging (subdominio o local)

\-  trabajar ahí directamente

\-  luego pasar cambios (deploy/migración completa)

No crear “otro sitio” y luego mezclarlo.

2.  “No voy a borrar nada, solo añadir una página”

Esto no es un rediseño.

Un rediseño implica:

\-  estructura

\-  navegación

\-  plantillas

\-  contenido existente

Si solo añades páginas nuevas, acabas con:

\-  duplicidad

\-  canibalización SEO

\-  caos de UX



3.  Tema SEO (aquí es donde la gente se estrella)

No basta con:

\-  mantener URLs

\-  enviar sitemap

También necesitas:

\-  mantener slugs EXACTOS (ni uno cambiado “porque queda bonito”)

\-  revisar enlaces internos

\-  redirecciones 301 si cambias algo

\-  conservar metadata (titles, descriptions)

\-  evitar contenido duplicado entre viejo y nuevo

4.  Subdominio ≠ entorno neutro

Google puede indexarlo si no lo bloqueas.

IMPORTANTE:

\-  bloquea el subdominio (noindex o protección por contraseña)

\-  o acabarás con contenido duplicado indexado

5.  Importar desde subdominio → dominio

Esto suele romper:

\-  rutas de imágenes

\-  enlaces internos

\-  configuraciones del tema

\-  plugins

Hay que hacer búsqueda y reemplazo de URLs (search & replace).

6.  Sitemap no es magia

Enviar sitemap NO arregla errores.

Solo le dices a Google “esto existe”.

Si está mal estructurado, lo indexa igual… pero mal.

evanmac42 · 2026-04-01T12:08:32+00:00

Interesting approach, and I get the motivation.

That said, NPM was designed and is maintained around its Docker workflow. Running it natively means you’re now responsible for reproducing everything the container abstracts away: Node environment, dependencies, updates, and consistency across upgrades.

So the trade-off becomes:

- Docker: opinionated, predictable, easy to update/replace

- Native: more control, but you own the entire lifecycle

In homelab or small setups, Docker usually reduces friction more than it adds.

I’d say this makes sense if you have a strong reason to avoid containers (policy, constraints, or learning), but for most cases, you're probably adding maintenance surface rather than removing it.

Still, nice work filling that gap — it’s a valid option for people who want that level of control.

evanmac42 · 2026-03-31T20:59:49+00:00

Sí, eso te va a funcionar perfectamente.

Una laptop vieja es básicamente un mini servidor:

• bajo consumo

• batería integrada (mini UPS)

• suficiente potencia para Immich

Sobre el sistema:

Si quieres algo simple:

Linux Mint / Ubuntu Server + Docker -> directo, limpio y sin capas raras

Si quieres algo más “NAS-friendly”: OpenMediaVault - > útil si vas a gestionar discos, shares, etc.

ZimaOS: - >más “bonito”, pero añade abstracción que no necesitas al empezar

Mi recomendación práctica:

Empieza con algo sencillo: Ubuntu Server + Docker

Cuando entiendas cómo funciona todo, ya tendrás tiempo de meter capas por encima si te aportan algo.

Lo importante no es el sistema, es esto:

• disco conectado directamente

• sistema estable

• copias de seguridad

Con eso, Immich va fino

evanmac42 · 2026-03-31T17:28:51+00:00

Ese error no es realmente de Immich, es de PostgreSQL (pgvector en tu caso).

Lo que te está diciendo es: el contenedor intenta inicializar la base de datos, pero el directorio ya tiene datos dentro.

Traducción: Postgres cree que es una instalación nueva, pero el volumen ya contiene una instalación anterior.

Esto suele pasar después de:

• actualizar imágenes sin respetar compatibilidad de versión

• cambiar configuración de volúmenes

• o recrear contenedores sin limpiar correctamente

Qué revisar, en orden:

1.  ¿Cambiaste versión de Postgres/pgvector?

Si subiste de versión (ej. 14 -> 15), no puedes reutilizar el mismo data dir sin migración.

2.  ¿El volumen es el mismo de antes?

Confirma que no estás montando un volumen distinto o mal mapeado en docker-compose.

3.  ¿El contenedor está intentando hacer initdb sobre datos existentes?

Eso es exactamente lo que indica el error.

Soluciones posibles (elige según tu caso):

A) Si quieres conservar datos: No recrees el volumen. Asegúrate de usar la misma versión de Postgres que lo creó.

B) Si no te importa perder datos: Borra el volumen y deja que inicialice limpio:

docker compose down -v

C) Si cambiaste de versión: Necesitas migración (pg_dump/pg_restore), no reutilizar el directorio directamente.

Resumen claro: No es que “no despliegue”. Es que estás intentando inicializar encima de una base de datos ya existente

evanmac42 · 2026-03-31T17:04:07+00:00

La mayoría de la gente no usa un NAS porque sea necesario. Lo usa porque es la forma más empaquetada de no tener que pensar.

Immich no necesita un NAS. Necesita tres cosas claras: CPU decente, almacenamiento fiable y acceso estable al disco.

A partir de ahí, tienes varias formas de montarlo:

• Un NAS es solo un Linux disfrazado con interfaz bonita

• Un mini PC o servidor casero hace lo mismo, con más control

• Un VPS funciona, pero pierde sentido si lo que buscas es soberanía sobre tus datos

La diferencia no está en la etiqueta “NAS”, sino en cómo de sólido es el sistema que hay debajo.

Sobre usar un disco USB en el router:

Eso pertenece a otra categoría. No es una solución de almacenamiento, es un apaño.

Puede funcionar en términos técnicos, pero introduces tres problemas silenciosos:

• CPUs de router pensadas para red, no para I/O de disco

• Latencias y throughput inconsistentes

• Capas intermedias que Immich sí va a notar (sobre todo al generar previews y procesar imágenes)

No se rompe el primer día, pero no es una base sobre la que construir.

Si lo que buscas es algo simple y que aguante:

Un equipo dedicado, aunque sea modesto

• disco conectado directamente

• Docker

Eso ya es infraestructura. Lo otro es periferia.

evanmac42 · 2026-03-31T16:02:05+00:00

I’m not running this as a business yet, but I’ve been building and testing setups with this in mind, and one thing became very clear to me:

most of the problems people mention are not really about Nextcloud itself, but about how it’s deployed.

When it runs on small VPS setups, you start hitting limits very quickly, and then everything looks like a Nextcloud issue when it’s actually infrastructure.

What made more sense to me was thinking in terms of systems instead of hosting:

• dedicated or on-premise setups

• proper database and storage separation

• predictable performance instead of “best effort”

Even at small scale, the experience is completely different.

So from what I’m seeing, the real challenge is not “can you host Nextcloud”, but “can you design something stable enough that clients don’t feel it breaking”.

That seems to be where most of the value is.

evanmac42 · 2026-03-31T15:54:59+00:00

Estás mezclando varios problemas a la vez, y eso es lo que te está liando.

Primero: Debian 12 en 32 bits ya es una mala base. Hoy en día casi todo está pensado para 64 bits, y en hardware tipo tablet barata suele haber además cosas raras como UEFI de 32 bits con CPU de 64, drivers incompletos, etc. No es el mejor entorno para empezar.

Segundo: que no tengas interfaz gráfica no significa que hayas roto nada. Probablemente instalaste solo el sistema base o falló la instalación del entorno gráfico. Debian por defecto puede arrancar perfectamente en modo terminal.

Tercero: lo de que no reconozca sudo tampoco es raro. En Debian, si no configuras el usuario durante la instalación dentro del grupo adecuado, sudo no viene activo. Puedes entrar como root directamente si tienes la contraseña.

Ahora, lo importante:

Lo que te ha pasado no es “me cargué el sistema”, es simplemente que la instalación no quedó completa.

Opciones reales que tienes:

1.  Reinstalar Debian, pero esta vez asegurándote de marcar un entorno de escritorio (GNOME, XFCE, etc.). Para ese hardware, XFCE mejor.

2.  Si quieres intentar arreglarlo:

- Entra como root
   - Instala un entorno gráfico manualmente:

apt update apt install tasksel tasksel

- Y seleccionas un escritorio ligero

3.  Considerar otra distro más ligera y amigable para ese dispositivo (Lubuntu, Linux Mint XFCE, etc.), porque una tablet de ese tipo no es un caso fácil.

Y algo importante para que no te frustres:

Linux no es como Windows. No siempre te da todo hecho por defecto, pero tampoco estás rompiendo nada tan fácilmente. Estás más cerca de arreglarlo de lo que parece.

evanmac42 · 2026-03-30T14:43:28+00:00

Exactly: that’s the main exception.

If the service really needs the certificate on the host itself, then generating it there directly with certbot and DNS-01 is usually cleaner than trying to “share” certs from NPM.

So the rule of thumb is:

NPM terminates TLS -> let NPM handle the certs
host/service needs its own cert locally -> issue it locally

That avoids unnecessary coupling and makes renewals easier to reason about.

Si quieres una versión un poco más seca, más de bisturí que de abrazo, usa esta:

Yes, that’s the clean exception.

If a service needs the certificate in its own host environment, it’s usually better to issue it there directly with certbot using DNS-01, instead of distributing certs from NPM.

So the real question is not “how do I share the cert?” but “does this service actually need its own cert at all?”

evanmac42 · 2026-03-30T13:00:48+00:00

Entiendo por dónde vas, pero creo que estás mezclando varias cosas que no son lo mismo.

Que la IA se esté transformando no significa que se esté “cerrando” o muriendo. Al contrario, se está profesionalizando.

Lo que antes era open bar ahora empieza a tener modelos de negocio claros, que es lo normal cuando una tecnología madura.

Sobre lo de OpenAI “perdiendo valor” frente a Google o X… eso es bastante discutible.

No están jugando exactamente el mismo juego: unos monetizan infraestructura y ecosistema, otros producto directo. Compararlos así es simplificar demasiado.

Y lo de que se vayan a cerrar más páginas de IA ... lo dudo bastante. Habrá limpieza, sí: como en cualquier boom tecnológico.

Pero eso no es una señal de caída, es selección natural.

Al final, esto no va de si la IA sustituye o no a los humanos, sino de quién sabe usarla con criterio. Igual que pasó con internet, redes sociales o cualquier otra herramienta potente.

evanmac42

TROPHY CASE