Installare Chatwoot su VPS con Docker e Traefik

Cosa si sta configurando

Per eseguire Chatwoot in self-hosting su un VPS, avvii quattro container: un processo web Rails, un worker in background Sidekiq, PostgreSQL con l'estensione pgvector e Redis. Chatwoot è un help desk open source per l'assistenza clienti. Offre quindi una casella di posta condivisa per il team e un widget di chat per il sito web, su un server sotto il tuo controllo. L'installazione richiede circa venti minuti. Tutto ciò che viene dopo, ovvero recapito della posta, backup, aggiornamenti e dimensionamento, determina se il servizio sarà ancora operativo tra un anno.

Ogni container svolge una sola funzione. Rails pubblica il pannello degli agenti e l'API (application programming interface) del widget. Sidekiq esegue le attività lente: invio delle email, interrogazione periodica dei canali collegati, esecuzione delle regole di automazione e generazione dei report. Postgres archivia conversazioni, contatti, account degli agenti e tutte le impostazioni modificate nel pannello. Redis gestisce le code Sidekiq e il canale pub/sub di ActionCable, che inserisce un nuovo messaggio in un pannello aperto senza ricaricare la pagina. In questo caso Redis non è una cache temporanea, perché perderlo significa perdere i job accodati.

L'immagine Postgres nel file compose upstream è pgvector/pgvector:pg16 anziché l'immagine standard postgres, perché lo schema di Chatwoot abilita l'estensione vector per le funzioni di intelligenza artificiale. Se sostituisci l'immagine con Postgres standard, la prima esecuzione del database si interrompe con ERROR: extension "vector" is not available, perché il file di controllo dell'estensione non è presente in quell'immagine. Usa l'immagine distribuita dall'upstream.

Questa guida presuppone che Docker e un reverse proxy siano già operativi sul server. In caso contrario, inizia da Docker Compose su un VPS e poi torna qui.

Di quante risorse VPS ha bisogno Chatwoot self-hosted?

Ad agosto 2026, la pagina dei requisiti upstream indica 4 GB di RAM e 4 core CPU come requisiti minimi e associa questa configurazione a un massimo di 10.000 conversazioni al giorno. Indica 8 GB e 8 core per un massimo di 20.000 conversazioni al giorno. Richiede inoltre almeno 1 GB di swap e ne spiega direttamente il motivo: evitare che la macchina esaurisca la memoria durante un aggiornamento. Prevedi da 5 GB a 10 GB di spazio disco per Postgres, senza includere gli upload dei file.

Veniamo al punto. Una VPS da 2 GB avvia Chatwoot e può funzionare senza problemi con due agenti e una casella con poco traffico. I problemi si verificano in due situazioni. La prima riguarda Sidekiq, che upstream misura in oltre 1 GB su un server sotto carico. Un picco di email o un job di report può quindi esaurire la memoria della macchina prima che Rails, Postgres e Redis abbiano utilizzato la propria quota. La seconda riguarda l'aggiornamento, perché db:chatwoot_prepare avvia un nuovo processo Rails per applicare le migrazioni e l'avvio di Rails su questa immagine richiede centinaia di megabyte prima di eseguire qualsiasi attività utile.

Non viene visualizzato prima un avviso chiaro. L'out of memory killer del kernel invia SIGKILL al processo più grande, Docker rileva l'arresto del container e restart: always lo avvia di nuovo. docker compose ps mostra quindi un container che torna continuamente a Exited (137), dove 137 significa che il processo è stato terminato dal segnale 9. Conferma il comportamento con sudo dmesg -T | grep -i "killed process", che identifica il processo scelto dal kernel.

Se 4 GB non rientrano nel budget, puoi usare una macchina da 2 GB con 2 GB di swap, accettando tempi di risposta peggiori sotto carico invece dell'arresto completo del servizio. In ogni caso, conviene impostare un limite massimo di memoria per ogni servizio, in modo che il worker non possa causare l'arresto del database. Consulta i limiti di memoria in Docker Compose.

Gli upload dei file sono l'elemento che cresce senza un limite definito. Ogni screenshot allegato da un cliente viene salvato nel volume di storage e resta al suo interno. Per questo, monitora docker system df -v invece di presumere che sia il database ad aver esaurito lo spazio disco.

Ottieni il file Compose e fissa un tag di versione

mkdir -p ~/chatwoot && cd ~/chatwoot
wget -O .env https://raw.githubusercontent.com/chatwoot/chatwoot/develop/.env.example
wget -O docker-compose.yaml https://raw.githubusercontent.com/chatwoot/chatwoot/develop/docker-compose.production.yaml
chmod 600 .env

Il file appena scaricato contiene image: chatwoot/chatwoot:latest. Modificalo prima di eseguire qualsiasi altra operazione.

services:
  base: &base
    image: chatwoot/chatwoot:v4.16.2
    env_file: .env
    volumes:
      - storage_data:/app/storage

latest significa che il successivo docker compose pull utilizza qualunque versione sia stata pubblicata quella mattina. Potrebbe trattarsi di una versione principale con migrazioni non documentate. In pratica, le migrazioni di Chatwoot non sono reversibili. Un aggiornamento accidentale richiede quindi un ripristino dal backup, non un annullamento. Fissa il tag e modificalo deliberatamente. v4.16.2 era la versione corrente ad agosto 2026; consulta la pagina delle release per verificare quale tag fissare oggi.

Il servizio base è un ancoraggio YAML che rails e sidekiq importano entrambi. Modificando il tag in un solo punto, lo cambi per entrambi i servizi. Mentre lavori sul file, elimina la riga version: '3' iniziale. Le versioni moderne di Compose la ignorano e visualizzano the attribute 'version' is obsolete, it will be ignored a ogni comando.

Compila il file .env

Genera prima il secret. Upstream richiede un valore alfanumerico, perché i caratteri speciali possono essere alterati quando il valore passa attraverso una shell o un parser YAML.

head /dev/urandom | tr -dc A-Za-z0-9 | head -c 63 ; echo ''

Imposta quindi queste chiavi in .env.

SECRET_KEY_BASE=<the 63 characters you just generated>
FRONTEND_URL=https://support.example.com
FORCE_SSL=true
DEFAULT_LOCALE=en
ENABLE_ACCOUNT_SIGNUP=true

POSTGRES_HOST=postgres
POSTGRES_USERNAME=postgres
POSTGRES_PASSWORD=<long random string>
POSTGRES_DATABASE=chatwoot

REDIS_URL=redis://redis:6379
REDIS_PASSWORD=<a different long random string>

RAILS_ENV=production
INSTALLATION_ENV=docker
ACTIVE_STORAGE_SERVICE=local

POSTGRES_HOST=postgres e redis://redis:6379 sono i nomi dei servizi Compose, che vengono risolti sulla rete predefinita del progetto. FRONTEND_URL non è un valore ornamentale. Chatwoot lo usa per costruire l’URL dello script del widget e ogni link contenuto nelle email in uscita. Un valore errato produce link per il ripristino della password che puntano a un host non raggiungibile.

Ora considera il problema nel file upstream. Il servizio postgres non legge .env. Contiene un proprio blocco environment con POSTGRES_PASSWORD= vuoto. Di conseguenza, impostare la password soltanto in .env lascia il database senza password e l’applicazione con una password configurata. Imposta il servizio in modo che utilizzi la stessa variabile:

  postgres:
    image: pgvector/pgvector:pg16
    restart: always
    volumes:
      - postgres_data:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=chatwoot
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}

Compose legge .env dalla directory del progetto per la sostituzione di ${...}. In questo modo entrambi i componenti ricevono la stessa stringa. Se il valore non è corretto, Rails si interrompe con PG::ConnectionBad: FATAL: password authentication failed for user "postgres".

Un comportamento sorprende quasi tutti: l’immagine Postgres applica POSTGRES_PASSWORD soltanto quando inizializza una directory dati vuota. La modifica successiva del valore non ha effetto, perché initdb non viene eseguito una seconda volta. Se lo stack è già stato avviato, modifica il valore direttamente nel database.

docker compose exec postgres psql -U postgres -c "ALTER USER postgres WITH PASSWORD 'the-new-password';"

ENABLE_ACCOUNT_SIGNUP=true è temporaneo. Apre il modulo pubblico di registrazione, così puoi creare il primo account. Impostalo su false ed esegui di nuovo docker compose up -d non appena l’account è disponibile. In caso contrario, chiunque trovi l’URL può registrarsi nel tuo help desk. In seguito, gli agenti accedono tramite invito e le relative password vengono gestite soltanto da questa applicazione. Questo approccio è adeguato finché non gestisci una mezza dozzina di servizi e non vuoi più mantenere un elenco di account separato per ciascuno. A quel punto, un identity provider self-hosted come Authentik sostituisce questi elenchi.

.env contiene ora tutti i secret utilizzati da questo stack, in chiaro. Imposta quindi i permessi a mode 600 e non inserirlo in git. Come Compose legge i file env e dove possono fuoriuscire i secret descrive i principali rischi, inclusa la differenza tra env_file e environment.

Metti Chatwoot dietro il tuo Traefik esistente

Non creare un secondo reverse proxy per una sola applicazione. Se Traefik gestisce già la terminazione TLS (transport layer security) per altri container su questo server, Chatwoot può utilizzarlo tramite un blocco di label. Se non hai ancora questa configurazione, impostala una sola volta seguendo Traefik davanti a più applicazioni Docker Compose, quindi torna qui.

Mantieni il file docker-compose.yaml dell’upstream il più possibile invariato, così in seguito potrai confrontarlo con una copia più recente, e inserisci le modifiche in un file di override. Compose esegue automaticamente il merge di docker-compose.override.yaml; suddividere Compose in più file spiega le regole di merge.

services:
  rails:
    networks:
      - default
      - proxy
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.chatwoot.rule=Host(`support.example.com`)"
      - "traefik.http.routers.chatwoot.entrypoints=websecure"
      - "traefik.http.routers.chatwoot.tls.certresolver=letsencrypt"
      - "traefik.http.services.chatwoot.loadbalancer.server.port=3000"

networks:
  proxy:
    external: true

Usa i nomi che hai scelto per l’entrypoint e il certresolver. Il container deve trovarsi sulla stessa rete Docker di Traefik, come specificato dall’istruzione proxy, e deve restare anche su default, altrimenti perde l’accesso a Postgres e Redis. Questa è la seconda riga che viene spesso dimenticata.

Lascia invariato il blocco ports:. Upstream lo associa a 127.0.0.1:3000, che accetta connessioni solo sull’interfaccia di loopback; quindi non è raggiungibile da Internet e resta utile per i test eseguiti dall’interno del server con curl -I http://127.0.0.1:3000.

Il dashboard dell’agente mantiene aperta una connessione websocket a /cable per la distribuzione in tempo reale dei messaggi. Traefik inoltra l’upgrade HTTP senza configurazioni aggiuntive, quindi non devi aggiungere nulla. Se in seguito metti una CDN o un altro proxy davanti a Traefik, abilita i websocket anche su quel componente: il sintomo è un dashboard che si carica normalmente, mentre i nuovi messaggi compaiono soltanto dopo un aggiornamento manuale.

Inizializzare il database e avviare lo stack

Avviare prima i servizi dati e attendere il completamento della prima esecuzione di Postgres.

docker compose up -d postgres redis
docker compose logs postgres | tail -n 5

Attendere database system is ready to accept connections. Quindi creare lo schema.

docker compose run --rm rails bundle exec rails db:chatwoot_prepare

Questo comando crea il database se non esiste, quindi carica lo schema e i dati seed predefiniti. Stampa le righe delle migrazioni e termina correttamente. Se continua a stampare postgres:5432 - no response, l’entrypoint sta attendendo un database che non accetta ancora connessioni. Al primo avvio, di solito significa che initdb è ancora in esecuzione. Attendere, leggere i log di Postgres, quindi eseguire nuovamente il comando. Se si interrompe sull’estensione vector, l’immagine pgvector è stata sostituita con un’immagine standard di Postgres.

docker compose up -d
docker compose ps
docker compose logs --tail 30 rails

Tutti e quattro i container dovrebbero riportare Up e il log di Rails dovrebbe terminare con una riga di Puma in ascolto su http://0.0.0.0:3000. Quindi verificare il percorso pubblico:

curl -sI https://support.example.com | head -n 1

HTTP/2 200 indica che l’intera catena funziona. Un errore 404 da Traefik indica che la regola del router non corrisponde, di solito a causa di un errore di battitura nel nome host. Un errore 502 indica che Traefik ha trovato il router, ma non riesce a raggiungere il container. Nella quasi totalità dei casi manca la rete proxy oppure loadbalancer.server.port non è impostato su 3000.

Aprire l’URL, creare l’account su /app/auth/signup, quindi impostare ENABLE_ACCOUNT_SIGNUP=false ed eseguire docker compose up -d per chiudere il modulo.

Perché il reset delle password e le conversazioni email non funzionano senza SMTP

Chatwoot senza le impostazioni SMTP (simple mail transfer protocol) è un help desk che non può inviare email, e questo interrompe più delle sole notifiche. Il reset delle password non funziona più, quindi un amministratore che rimane bloccato fuori dall'account non può rientrare. Anche gli inviti agli agenti non funzionano, perché un invito viene inviato tramite email. Le risposte ai clienti nelle conversazioni email non vengono più inviate, quindi la conversazione procede in una sola direzione. È il passaggio che molti saltano e che poi scoprono nella settimana peggiore.

Il meccanismo è semplice. Senza impostazioni SMTP, ActionMailer mantiene il valore predefinito e consegna la posta a localhost sulla porta 25. Nel container Rails non è presente alcun server di posta, quindi il job di consegna genera Errno::ECONNREFUSED: Connection refused - connect(2) for "localhost" port 25. La posta viene inviata da un job in background, quindi quella riga finisce nel log di Sidekiq e non nel log di Rails. Nel frattempo, la persona che fa clic su "password dimenticata" visualizza una conferma rassicurante, ma non riceve nulla.

MAILER_SENDER_EMAIL=Support <support@example.com>
SMTP_DOMAIN=example.com
SMTP_ADDRESS=smtp.example.com
SMTP_PORT=587
SMTP_USERNAME=support@example.com
SMTP_PASSWORD=<the relay password>
SMTP_AUTHENTICATION=plain
SMTP_ENABLE_STARTTLS_AUTO=true

Usa la porta 587 con STARTTLS. La connessione viene aperta in testo in chiaro e poi aggiornata a una connessione cifrata prima dell'autenticazione. La maggior parte dei provider VPS blocca la porta 25 in uscita per limitare lo spam, quindi un relay sulla porta 587 è generalmente l'unico endpoint a cui sia possibile connettersi. SMTP_DOMAIN è il dominio che il server annuncia durante la conversazione SMTP, e alcuni relay rifiutano una mancata corrispondenza.

Applica le impostazioni e monitora il worker:

docker compose up -d rails sidekiq
docker compose logs -f sidekiq

Avvia un reset della password dalla pagina di accesso. Quando la consegna funziona, nel log di Sidekiq il job del mailer termina normalmente. In caso di errore, viene mostrata la classe dell'eccezione, quindi Sidekiq ritenta con un backoff crescente. Per questo un relay non funzionante produce lo stesso errore ogni pochi minuti per ore.

Sono comuni due rifiuti, e nessuno dei due è un bug di Chatwoot. 535 Authentication failed indica che il nome utente o la password non sono corretti per quel relay; molti provider richiedono una password per applicazioni invece della password dell'account. 550 Sender address rejected indica che MAILER_SENDER_EMAIL è un indirizzo da cui il relay non consente di inviare, quindi deve essere una casella o un dominio che hai verificato presso il provider.

La ricezione delle email in una conversazione è un'attività separata. Richiede MAILER_INBOUND_EMAIL_DOMAIN e RAILS_INBOUND_EMAIL_SERVICE, oltre a un server di posta che inoltri i messaggi in arrivo a Chatwoot. Noleggiare un relay è la soluzione più rapida. Se preferisci gestire internamente l'intero flusso di posta, gestire un server di posta autonomo con Mailcow spiega cosa comporta realmente questa scelta.

Cosa sottoporre a backup e come verificare che il ripristino funzioni

Un backup di Chatwoot comprende quattro elementi. Se ne salti anche solo uno, il ripristino diventa una ricostruzione.

• Il database Postgres, che contiene conversazioni, contatti, account degli agenti e tutte le impostazioni.
• Il volume storage_data, perché ACTIVE_STORAGE_SERVICE=local scrive i file caricati su disco e conserva in Postgres soltanto una riga di riferimento.
• Il file .env, perché contiene SECRET_KEY_BASE e le chiavi ACTIVE_RECORD_ENCRYPTION_*.
• I file compose, perché registrano il tag esatto dell'immagine compatibile con lo schema del database.

Se ripristini solo il database, tutte le conversazioni tornano disponibili con gli allegati non funzionanti, perché le righe puntano a file che non sono più presenti su disco.

cd ~/chatwoot
docker compose exec -T postgres pg_dump -U postgres -Fc chatwoot > db-$(date +%F).dump

-T è importante. Senza questa opzione Compose alloca un terminale pseudo-TTY, che modifica i byte di nuova riga nel flusso. Il risultato è un file di dump che pg_restore rifiuta. -Fc indica il formato custom, che comprime i dati e consente a pg_restore di lavorare in modo selettivo.

docker run --rm -v chatwoot_storage_data:/data:ro -v "$PWD":/backup alpine \
  tar czf /backup/storage-$(date +%F).tgz -C /data .

Il nome del volume è il nome della directory del progetto seguito da _storage_data. Confermalo con docker volume ls | grep storage_data prima di eseguire quel comando, perché Docker crea un volume vuoto invece di segnalare un errore quando indichi un volume inesistente. Otterresti un archivio valido ma vuoto, senza alcun errore. Controlla poi le dimensioni con ls -lh storage-*.tgz.

Ora entrambi i file si trovano sullo stesso disco dei dati che dovrebbero proteggere. Questo non offre alcuna protezione. Copiali fuori dal server e cifrali, perché un dump del database contiene in chiaro tutti i messaggi dei clienti. Backup cifrati fuori sede con restic descrive la pianificazione e la gestione della conservazione.

docker compose up -d postgres
docker compose exec -T postgres pg_restore -U postgres -d chatwoot --clean --if-exists < db-2026-08-10.dump
docker run --rm -v chatwoot_storage_data:/data -v "$PWD":/backup alpine \
  sh -c 'rm -rf /data/* && tar xzf /backup/storage-2026-08-10.tgz -C /data'
docker compose up -d

Come aggiornare Chatwoot a un nuovo tag

L’ordine delle operazioni è più importante dei comandi.

1. Leggi le note di rilascio comprese tra il tuo tag e quello di destinazione e verifica se sono richieste operazioni manuali.
2. Crea un nuovo dump del database e un archivio dello storage. Controlla che le dimensioni di entrambi siano plausibili.
3. Modifica il tag dell’immagine del servizio base in docker-compose.yaml.
4. Scarica la nuova immagine, arresta lo stack, esegui le migrazioni, quindi riavvia lo stack.

docker compose pull
docker compose down
docker compose run --rm rails bundle exec rails db:chatwoot_prepare
docker compose up -d
docker compose images

Scarica l’immagine prima di eseguire le migrazioni, perché la migrazione deve essere eseguita dalla nuova immagine. L’immagine precedente non contiene i nuovi file di migrazione. Arresta lo stack prima di eseguire le migrazioni, perché il codice precedente e il nuovo schema non sono compatibili. Un processo Rails ancora in esecuzione può quindi generare errori o scrivere righe che il nuovo schema non accetta. L’arresto libera inoltre la memoria necessaria alla migrazione. Questo è il motivo per cui il progetto upstream richiede lo swap.

docker compose images stampa il tag effettivamente in esecuzione in ogni container. In questo modo rileva il caso in cui hai modificato il tag ma hai dimenticato di scaricare la nuova immagine.

Non passare direttamente attraverso molte versioni. Per un’installazione precedente, il progetto upstream consiglia di procedere attraverso tag intermedi, perché le migrazioni vengono rimosse quando sono integrate nello schema di base. Un database molto vecchio può quindi raggiungere uno stato senza un percorso di aggiornamento possibile. Procedi una versione minor alla volta ed esegui il passaggio di preparazione dopo ciascuna versione.

Se Rails si avvia prima dell’esecuzione della migrazione, rifiuta di gestire le richieste e registra ActiveRecord::PendingMigrationError: Migrations are pending. Se restart: always è impostato, il container entra in un ciclo di riavvio. Di conseguenza, docker compose ps mostra un uptime che si azzera ogni pochi secondi. Esegui il passaggio di preparazione per risolvere il problema.

Per eseguire il rollback, ripristina il tag precedente e ripristina il dump. Non esiste un percorso di migrazione inversa su cui fare affidamento. È questo il motivo per cui il passaggio 2 è necessario.

Modalità di errore e stringhe visualizzate

502 Bad Gateway da Traefik. Il router ha eseguito il matching, ma il backend non ha risposto. Verifica che docker compose ps mostri rails come Up, quindi esegui docker network inspect proxy e conferma che il container rails compaia nell’elenco dei container. Un container non collegato è invisibile a Traefik: la richiesta corrisponde a un router, ma poi non viene inoltrata.

La dashboard viene caricata, ma per visualizzare i nuovi messaggi è necessario aggiornare la pagina. La connessione WebSocket a /cable non passa, oppure FRONTEND_URL non corrisponde all’indirizzo visualizzato nella barra del browser. Una mancata corrispondenza indica che la pagina tenta di aprire una connessione WebSocket verso un’origine diversa, che il browser blocca.

FATAL: password authentication failed for user "postgres". La password in .env e quella memorizzata nel volume dati di Postgres sono diverse. Correggi il problema con ALTER USER all’interno del container in esecuzione, perché modificare di nuovo .env non cambia un database già inizializzato.

NOAUTH Authentication required. Redis è in esecuzione con --requirepass, ma l’applicazione si è connessa senza password. Di conseguenza, REDIS_PASSWORD manca da .env oppure non è stato acquisito. Verificalo direttamente con docker compose exec redis redis-cli -a "$REDIS_PASSWORD" ping, che dovrebbe rispondere PONG.

I container terminano con codice 137. Si tratta di SIGKILL e, su un server con risorse limitate, la causa è il meccanismo del kernel che termina i processi quando esaurisce la memoria. Aggiungi swap, imposta limiti di memoria per ogni servizio oppure passa a un piano con più risorse.

FAQ

Quanta RAM richiede una VPS con Chatwoot self-hosted?

Ad agosto 2026, il progetto upstream richiede almeno 4 GB di RAM e 4 core CPU, con un carico dichiarato fino a 10.000 conversazioni al giorno, oppure 8 GB e 8 core per arrivare a 20.000. Aggiungete almeno 1 GB di swap, perché durante un aggiornamento viene avviato un secondo processo Rails per applicare le migration: è in questa fase che le macchine più piccole esauriscono la memoria. Una VPS da 2 GB si avvia e funziona per un paio di operatori, ma il solo Sidekiq può superare 1 GB sotto carico. Durante i periodi di maggiore attività e gli aggiornamenti, prevedete quindi l'arresto dei container con codice di uscita 137.

Perché le email di reimpostazione della password di Chatwoot non arrivano?

Perché non sono configurate le impostazioni SMTP. ActionMailer tenta quindi di consegnare il messaggio a localhost sulla porta 25, ma nel container non è presente alcun mail server. Il job fallisce in Sidekiq con Errno::ECONNREFUSED: Connection refused - connect(2) for "localhost" port 25, mentre il browser continua a mostrare un messaggio di operazione completata. Impostate SMTP_ADDRESS, SMTP_PORT, SMTP_USERNAME, SMTP_PASSWORD e MAILER_SENDER_EMAIL in .env, riavviate i servizi rails e sidekiq, quindi monitorate docker compose logs -f sidekiq mentre avviate una procedura di reimpostazione.

Che cosa devo includere nel backup per ripristinare Chatwoot?

Il database Postgres, il volume Docker storage_data, il file .env e i file compose. Il solo database non è sufficiente, perché i file caricati sono memorizzati nel volume, mentre Postgres conserva soltanto i riferimenti. Un ripristino del solo database produce quindi conversazioni con allegati non disponibili. .env è importante perché un SECRET_KEY_BASE diverso disconnette tutti gli utenti, mentre chiavi ACTIVE_RECORD_ENCRYPTION_* diverse rendono illeggibili le colonne cifrate.

Come posso aggiornare Chatwoot senza danneggiare il database?

Eseguite un backup, modificate il tag dell'immagine nel file compose, quindi eseguite docker compose pull, docker compose down, docker compose run --rm rails bundle exec rails db:chatwoot_prepare e docker compose up -d. Eseguite prima il pull, perché le migration devono essere eseguite dalla nuova immagine. Arrestate prima lo stack, perché il vecchio codice utilizzato con un nuovo schema genera errori. In un'installazione precedente, passate da una minor version alla successiva, perché le migration vengono rimosse quando vengono integrate nello schema di base.

Posso usare l'immagine standard postgres invece di pgvector?

No. Lo schema di Chatwoot abilita l'estensione vector. L'immagine standard postgres fallisce durante db:chatwoot_prepare con ERROR: extension "vector" is not available, perché in quell'immagine non è presente il file di controllo dell'estensione. Mantenete pgvector/pgvector:pg16 dal file compose upstream oppure usate un'altra immagine che includa pgvector per la vostra major version di Postgres.