Hello everyone!
What’s the best way to migrate from normal n8n to the langchain/AI n8n to ensure that no data is lost?
Do I just change the image path in my docker-compose?
Was there a reason why the Langchain version is a separate to the “core”?
Edit: ah I now see Langchain is in Beta and thats probably way it’s not merged with the core version.
Hi @Nikto655 
That’s right, the Langchain version is in beta 
If you want to upgrade your existing instance you can simply change the Docker image to use the tag ai-beta in your docker-compose file, so it would be:
n8n:
image: n8nio/n8n:ai-beta
If you just want to play around a little bit and not update your main instance, you can spin up the LangChain version for testing on a different port (like 5679) via this command:
docker run -it --rm --name n8n -p 5679:5678 -v ~/.n8n:/home/node/.n8n docker.n8n.io/n8nio/n8n:ai-beta
Hi @EmeraldHerald I’m curious to test out this AI version.
When I docker-compose up -d it pulled the image and after 1 minute I got these errors that indicate some kind of issues with the arm64 architecture. This VPS runs with arm64 (Ampere).
I guess I will try it with x86 architecture, but not sure why this is a problem at all, since main n8n image runs perfectly on arm64.
Thanks.
@yukyo This warning message shouldn’t prevent you from running the image. Even on your screeenshot, the container seems to have started. What do you see when you try to access the n8n instance? Are there any logs coming from the container?
Hi @oleg thanks for the response.
This is the error, HTTP ERROR 502.
No logs, even I turned ON logs:
If I remove the :ai-beta from the image and load the main n8n image, docker compose stop and up -d again then it works as always…
Any ideas?
Thanks.
@oleg more context:
I tried again with a different subdomain, and now the error is:
My .env file is OK, my caddy/Caddyfile file is OK but for some reason Caddy is not “creating/renewing” the certificate. But it works OK if I run the main image…
If I check logs I can see an error with the SSL targeting a different subdomain + domain.
Any ideas or how to force Caddy to renew/create a new certificate for the AI image?
@yukyo Sorry, not familiar with Caddy.
In the screenshot you have log level(N8N_LOG_LEVEL) set to error so if n8n container is running and doesn’t output any logs, there shouldn’t be any errors. Try setting the log level info and see if you get the n8n initliazation logs:
...
Initializing n8n process
n8n ready on 0.0.0.0, port 5678
...
If you see those, check the logs of Caddy container — are there any errors? Both on initialization and when you visit the instance.
Finally, you might want to run the docker compose up with --build option to rebuild the images, perhaps that might help.
Thanks for your help @oleg, but still can’t figure out what the issue is. Clearly, some configuration / architecture is incompatible with Caddy and this AI image.
As soon as I go back to n8n main image everything works, the page works I can access the editor. But if I try again, the AI image then doesn’t work.
Some logs:
n8n service:
n8n-docker-caddy-n8n-1 | exec /sbin/tini: exec format error
n8n-docker-caddy-n8n-1 | exec /sbin/tini: exec format error
n8n-docker-caddy-n8n-1 | exec /sbin/tini: exec format error
n8n-docker-caddy-n8n-1 | exec /sbin/tini: exec format error
n8n-docker-caddy-n8n-1 | exec /sbin/tini: exec format error
caddy service:
n8n-docker-caddy-caddy-1 | {"level":"info","ts":1697116286.6617663,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","config_adapter":"caddyfile"}
n8n-docker-caddy-caddy-1 | {"level":"warn","ts":1697116286.6628096,"msg":"Caddyfile input is not formatted; run 'caddy fmt --overwrite' to fix inconsistencies","adapter":"caddyfile","file":"/etc/caddy/Caddyfile","line":2}
n8n-docker-caddy-caddy-1 | {"level":"info","ts":1697116286.6653538,"logger":"admin","msg":"admin endpoint started","address":"localhost:2019","enforce_origin":false,"origins":["//localhost:2019","//[::1]:2019","//127.0.0.1:2019"]}
n8n-docker-caddy-caddy-1 | {"level":"info","ts":1697116286.6655428,"logger":"http.auto_https","msg":"server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS","server_name":"srv0","https_port":443}
n8n-docker-caddy-caddy-1 | {"level":"info","ts":1697116286.6655538,"logger":"http.auto_https","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}
n8n-docker-caddy-caddy-1 | {"level":"info","ts":1697116286.6658545,"logger":"http","msg":"enabling HTTP/3 listener","addr":":443"}
n8n-docker-caddy-caddy-1 | {"level":"info","ts":1697116286.6659184,"msg":"failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 2048 kiB, got: 416 kiB). See link for details."}
n8n-docker-caddy-caddy-1 | {"level":"info","ts":1697116286.6660383,"logger":"http.log","msg":"server running","name":"srv0","protocols":["h1","h2","h3"]}
n8n-docker-caddy-caddy-1 | {"level":"info","ts":1697116286.6661184,"logger":"http.log","msg":"server running","name":"remaining_auto_https_redirects","protocols":["h1","h2","h3"]}
n8n-docker-caddy-caddy-1 | {"level":"info","ts":1697116286.6661246,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["ai.xxxxxx.com"]}
n8n-docker-caddy-caddy-1 | {"level":"info","ts":1697116286.666843,"msg":"autosaved config (load with --resume flag)","file":"/config/caddy/autosave.json"}
n8n-docker-caddy-caddy-1 | {"level":"info","ts":1697116286.6669052,"msg":"serving initial configuration"}
n8n-docker-caddy-caddy-1 | {"level":"info","ts":1697116286.6669893,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0x40004ba300"}
n8n-docker-caddy-caddy-1 | {"level":"info","ts":1697116286.6670558,"logger":"tls","msg":"cleaning storage unit","description":"FileStorage:/data/caddy"}
n8n-docker-caddy-caddy-1 | {"level":"info","ts":1697116286.6680942,"logger":"tls","msg":"finished cleaning storage units"}
n8n-docker-caddy-caddy-1 | {"level":"error","ts":1697116292.0561206,"logger":"http.log.error","msg":"dial tcp [INTERNAL_IP]:5678: i/o timeout","request":{"remote_ip":"[EXTERNAL_IP]","client_ip":"[EXTERNAL_IP]","proto":"HTTP/2.0","method":"GET","host":"ai.xxxxxx.com","uri":"/","headers":{[REDACTED]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"ai.xxxxxx.com"}},"duration":3.000466198,"status":502,"err_id":"55nwuwjad","err_trace":"reverseproxy.statusError (reverseproxy.go:1248)"}
Tried docker compose down and up -d again:
root@ai-n8n:/home/n8n-docker-caddy# sudo docker compose down
[+] Running 3/3
✔ Container n8n-docker-caddy-caddy-1 Removed 0.4s
✔ Container n8n-docker-caddy-n8n-1 Removed 0.0s
✔ Network n8n-docker-caddy_default Removed 0.2s
root@ai-n8n:/home/n8n-docker-caddy# sudo docker compose up -d
[+] Running 2/3
✔ Network n8n-docker-caddy_default Created0.1s -caddy-n8n-1 Creating 0.0s
⠿ Container n8n-docker-caddy-n8n-1 [+] Running 2/4ting0.1s
✔ Network n8n-docker-caddy_default Created0.1s
⠿ Container n8n-docker-caddy-n8n-1 [+] Running 2/4ting0.2s
✔ Network n8n-docker-caddy_default Created0.1s
⠿ Container n8n-docker-caddy-n8n-1 [+] Running 4/4ting0.3s
✔ Network n8n-docker-caddy_default Created0.1s
✔ Container n8n-docker-caddy-n8n-1 Started0.4s
✔ Container n8n-docker-caddy-caddy-1 Started0.4s
! n8n The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested 0.0s
Tried force build as well:
root@ai-n8n:/home/n8n-docker-caddy# sudo docker compose down
[+] Running 3/3
✔ Container n8n-docker-caddy-n8n-1 Removed 0.3s
✔ Container n8n-docker-caddy-caddy-1 Removed 0.4s
✔ Network n8n-docker-caddy_default Removed 0.2s
root@ai-n8n:/home/n8n-docker-caddy# sudo docker compose up --build -d
[+] Running 2/1
✔ Network n8n-docker-caddy_default Created0.1s
⠿ Container n8n-docker-caddy-n8n-1 [+] Running 2/4ting0.1s
✔ Network n8n-docker-caddy_default Created0.1s
⠿ Container n8n-docker-caddy-n8n-1 [+] Running 2/4ting0.2s
✔ Network n8n-docker-caddy_default Created0.1s
⠿ Container n8n-docker-caddy-n8n-1 [+] Running 2/4ting0.3s
✔ Network n8n-docker-caddy_default Created0.1s
⠿ Container n8n-docker-caddy-n8n-1 [+] Running 4/4ting0.4s
✔ Network n8n-docker-caddy_default Created0.1s
✔ Container n8n-docker-caddy-n8n-1 Started0.5s
✔ Container n8n-docker-caddy-caddy-1 Started0.4s
! n8n The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested 0.0s
root@ai-n8n:/home/n8n-docker-caddy#
Restarted caddy service, pruned volume, etc. nothing seems to work…
Not sure what could be the issue… it should not be that hard to start a docker compose image with caddy, I do this every time, and again, as said, as soon as I replace the image and I remove the :ai-beta, everything works.
Caddyfile:
ai.xxxxxxxx.com {
reverse_proxy n8n:5678 {
flush_interval -1
}
}
docker-compose.yml:
version: "3.7"
services:
caddy:
image: caddy:latest
restart: unless-stopped
ports:
- "80:80"
- "443:443"
volumes:
- caddy_data:/data
- ${DATA_FOLDER}/caddy_config:/config
- ${DATA_FOLDER}/caddy_config/Caddyfile:/etc/caddy/Caddyfile
n8n:
image: docker.n8n.io/n8nio/n8n:ai-beta
restart: always
ports:
- 5678:5678
environment:
- N8N_HOST=${SUBDOMAIN}.${DOMAIN_NAME}
- N8N_PORT=5678
- N8N_PROTOCOL=https
- NODE_ENV=production
- WEBHOOK_URL=https://${SUBDOMAIN}.${DOMAIN_NAME}/
- GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
volumes:
- n8n_data:/home/node/.n8n
- ${DATA_FOLDER}/local_files:/files
volumes:
caddy_data:
external: true
n8n_data:
external: true
.env file:
# Replace <directory-path> with the path where you created folders earlier
DATA_FOLDER=/home/n8n-docker-caddy
# The top level domain to serve from, this should be the same as the subdomain you created above
DOMAIN_NAME=xxxxxxx.com
# The subdomain to serve from
SUBDOMAIN=ai
# DOMAIN_NAME and SUBDOMAIN combined decide where n8n will be reachable from
# above example would result in: https://n8n.example.com
# Optional timezone to set which gets used by Cron-Node by default
# If not set New York time will be used
GENERIC_TIMEZONE=America/New_York
# The email address to use for the SSL certificate creation
[email protected]
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
Thanks.
Edit: I just created a VPS x86 (AMD) and made the installation in less 3 minutes and everything works perfect, so if I had to guess, I would say the issue seems to be architecture incompatibility.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
