Docker மூலம் VPS-ல் Chatwoot-ஐ நிறுவுவது எப்படி?

நீங்கள் உருவாக்குவது என்ன

ஒரு VPS-ல் Chatwoot-ஐ self-host செய்ய நீங்கள் நான்கு containers-ஐ இயக்க வேண்டும்: ஒரு Rails web process, ஒரு Sidekiq background worker, pgvector extension கொண்ட PostgreSQL, மற்றும் Redis. Chatwoot என்பது ஒரு open source customer support desk ஆகும். எனவே, உங்கள் கட்டுப்பாட்டில் உள்ள server-ல் பகிரப்பட்ட team inbox மற்றும் website chat widget ஆகியவற்றை நீங்கள் பெறுகிறீர்கள். இந்த நிறுவல் சுமார் இருபது நிமிடங்கள் எடுக்கும். மின்னஞ்சல் அனுப்புதல், backups, upgrades மற்றும் sizing போன்ற நிறுவல் முடிந்த பிறகு நீங்கள் செய்யும் செயல்பாடுகளே, இந்த சேவை ஒரு வருடம் கழித்தும் தொடர்ந்து இயங்குமா என்பதைத் தீர்மானிக்கின்றன.

ஒவ்வொரு container-க்கும் ஒரு பணி உண்டு. Rails, agent dashboard மற்றும் widget API (application programming interface)-ஐ வழங்குகிறது. Sidekiq மெதுவான பணிகளைச் செய்கிறது: மின்னஞ்சல் அனுப்புதல், இணைக்கப்பட்ட channels-ஐ polling செய்தல், automation rules-ஐ இயக்குதல் மற்றும் அறிக்கைகளை உருவாக்குதல். Postgres உரையாடல்கள், தொடர்புகள், agent accounts மற்றும் dashboard-ல் நீங்கள் மாற்றும் ஒவ்வொரு அமைப்பையும் சேமித்து வைக்கிறது. Redis, Sidekiq queues மற்றும் ActionCable pub/sub channel-ஐக் கொண்டுள்ளது; இது page reload செய்யாமலேயே புதிய செய்தியை dashboard-க்குத் தள்ளுகிறது. இங்கு Redis என்பது வெறும் தற்காலிக cache அல்ல; ஏனெனில் அதை இழந்தால் வரிசையில் உள்ள பணிகள் (queued jobs) அழிந்துவிடும்.

Upstream compose file-ல் உள்ள Postgres image, சாதாரண postgres image-க்கு பதிலாக pgvector/pgvector:pg16 ஆக உள்ளது. ஏனெனில், Chatwoot-ன் schema அதன் AI அம்சங்களுக்காக vector extension-ஐப் பயன்படுத்துகிறது. நீங்கள் சாதாரண Postgres-ஐப் பயன்படுத்தினால், முதல் database run-ன் போதே ERROR: extension "vector" is not available பிழையுடன் நின்றுவிடும், ஏனெனில் அந்த image-ல் extension-ன் control file இருக்காது. Upstream வழங்கும் image-ஐயே பயன்படுத்தவும்.

இந்த வழிகாட்டி, உங்கள் server-ல் Docker மற்றும் reverse proxy ஏற்கனவே இயங்குவதாகக் கருதுகிறது. அவை இயங்கவில்லை என்றால், Docker Compose on a VPS-ல் தொடங்கிவிட்டு மீண்டும் வரவும்.

சுயமாக இயங்கும் (self-hosted) Chatwoot-க்கு எவ்வளவு VPS தேவை?

ஆகஸ்ட் 2026 நிலவரப்படி, அதிகாரப்பூர்வ தேவைகளின்படி குறைந்தபட்சம் 4 GB RAM மற்றும் 4 CPU cores தேவைப்படுகிறது; இது ஒரு நாளைக்கு 10,000 உரையாடல்களைக் கையாளும் திறன் கொண்டது. 8 GB RAM மற்றும் 8 cores இருந்தால் ஒரு நாளைக்கு 20,000 உரையாடல்கள் வரை கையாளலாம். குறைந்தது 1 GB swap memory-ஐ வைத்திருக்கவும்; upgrade செய்யும்போது memory பற்றாக்குறை ஏற்படாமல் இருக்க இது அவசியம் என அறிவுறுத்தப்படுகிறது. கோப்பு பதிவேற்றங்களை (file uploads) கணக்கிடுவதற்கு முன்பே, Postgres-க்காக 5 GB முதல் 10 GB வரை disk space ஒதுக்கீடு செய்யவும்.

இப்போது யதார்த்தமான நிலையைப் பார்ப்போம். 2 GB VPS-ல் Chatwoot-ஐத் தொடங்க முடியும், இரண்டு முகவர்கள் (agents) மற்றும் குறைவான பயன்பாடு உள்ள inbox-க்கு இது சரியாகத் தெரியும். ஆனால் இது இரண்டு இடங்களில் தோல்வியடையும். முதலாவது Sidekiq; அதிக பயன்பாடுள்ள server-ல் இது 1 GB-க்கும் மேல் memory-ஐ எடுத்துக்கொள்ளும். எனவே, மின்னஞ்சல்கள் அல்லது report job-கள் அதிகரிக்கும்போது, Rails, Postgres மற்றும் Redis ஆகியவற்றின் பயன்பாட்டிற்கு முன்பே server-ன் memory தீர்ந்துவிடும். இரண்டாவது, upgrade செய்யும்போது ஏற்படும் சிக்கல்; ஏனெனில் db:chatwoot_prepare புதிய Rails process-ஐத் தொடங்கி migrations-ஐச் செய்யும். இந்த image-ல் Rails தொடங்குவதற்கே நூற்றுக்கணக்கான megabytes தேவைப்படும்.

இது உங்களுக்கு முன்கூட்டியே எச்சரிக்கை தராது. Kernel-ன் out of memory killer, அதிக memory-ஐப் பயன்படுத்தும் process-க்கு SIGKILL அனுப்பும். Docker அந்த container செயலிழந்ததைக் கண்டறிந்து, restart: always மூலம் அதை மீண்டும் தொடங்கும். அப்போது docker compose ps-ல் container மீண்டும் மீண்டும் Exited (137) நிலைக்குச் செல்வதைக் காணலாம்; இதில் 137 என்பது signal 9 மூலம் கொல்லப்பட்டதைக் குறிக்கும். sudo dmesg -T | grep -i "killed process" கட்டளையைப் பயன்படுத்தி, kernel எந்த process-ஐத் தேர்ந்தெடுத்தது என்பதை உறுதிப்படுத்தவும்.

4 GB RAM உங்கள் பட்ஜெட்டில் இல்லை என்றால், 2 GB VPS-ல் 2 GB swap சேர்த்துப் பயன்படுத்தலாம். இதனால் service முழுமையாக முடங்குவதற்குப் பதிலாக, அதிக சுமையின்போது response time சற்று குறையும். எப்படி இருந்தாலும், ஒவ்வொரு service-க்கும் memory வரம்பை (memory ceiling) நிர்ணயிப்பது நல்லது; அப்போதுதான் worker process-ஆல் database-ஐ முடக்க முடியாது. இதைப் பற்றி மேலும் அறிய Docker Compose-ல் memory வரம்புகள் பகுதியைப் பார்க்கவும்.

கோப்பு பதிவேற்றங்கள் (file uploads) நீங்கள் நிர்ணயிக்கும் வரம்பின்றி வளரக்கூடியவை. வாடிக்கையாளர்கள் பதிவேற்றும் ஒவ்வொரு screenshot-ம் storage volume-ல் சேமிக்கப்படும். எனவே, database-ஆல் தான் disk நிரம்பியது என்று கருதாமல், docker system df -v மூலம் disk பயன்பாட்டைக் கண்காணித்து வரவும்.

Compose கோப்பைப் பெற்று ஒரு version tag-ஐ pin செய்யவும்

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

நீங்கள் இப்போது பதிவிறக்கம் செய்த கோப்பில் image: chatwoot/chatwoot:latest என்று குறிப்பிடப்பட்டுள்ளது. வேறு எதையும் செய்வதற்கு முன்பு அதை மாற்றவும்.

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

latest என்பது அடுத்தமுறை docker compose pull கட்டளையை இயக்கும்போது, அன்று காலை வெளியிடப்பட்ட எந்தவொரு பதிப்பையும் அது பதிவிறக்கும் என்பதைக் குறிக்கிறது. இது நீங்கள் படிக்காத மாற்றங்களைக் கொண்ட ஒரு major version-ஆக இருக்கலாம். Chatwoot-ன் தரவுத்தள மாற்றங்களை (migrations) நடைமுறையில் பின்னோக்கி மாற்ற முடியாது. எனவே, தற்செயலாக புதிய பதிப்பிற்கு மாறினால், அதைத் தவிர்க்க backup-லிருந்து தரவை மீட்டெடுக்க வேண்டியிருக்கும். எனவே, ஒரு குறிப்பிட்ட tag-ஐ pin செய்து, கவனமாக மாற்றவும். ஆகஸ்ட் 2026 நிலவரப்படி v4.16.2 தற்போதைய release ஆகும்; இன்று நீங்கள் pin செய்ய வேண்டிய tag-ஐ அறிய releases page-ஐச் சரிபார்க்கவும்.

base service என்பது ஒரு YAML anchor ஆகும். இதை rails மற்றும் sidekiq ஆகிய இரண்டுமே பயன்படுத்துகின்றன. எனவே, ஓரிடத்தில் tag-ஐ மாற்றினால் அது இரண்டிற்கும் பொருந்தும். கோப்பில் மாற்றங்களைச் செய்யும்போது, மேலே உள்ள version: '3' வரியை நீக்கிவிடவும். நவீன Compose இதைத் தவிர்க்கிறது, மேலும் ஒவ்வொரு கட்டளையின்போதும் the attribute 'version' is obsolete, it will be ignored என்ற எச்சரிக்கையை இது அச்சிடுகிறது.

.env கோப்பை நிரப்புதல்

முதலில் ரகசியக் குறியீட்டை (secret) உருவாக்கவும். Upstream ஆவணங்கள் எழுத்து மற்றும் எண்களைக் கொண்ட (alphanumeric) மதிப்பை பரிந்துரைக்கின்றன, ஏனெனில் சிறப்பு எழுத்துக்கள் shell அல்லது YAML parser வழியாகச் செல்லும்போது சிதைந்துவிட வாய்ப்புள்ளது.

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

பின்பு .env-ல் இந்த keys-ஐ அமைக்கவும்.

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 மற்றும் redis://redis:6379 ஆகியவை Compose service பெயர்கள், இவை project-ன் default network-ல் இயங்கும். FRONTEND_URL என்பது அலங்காரத்திற்காக அல்ல. Chatwoot தனது widget script URL மற்றும் மின்னஞ்சல்களில் உள்ள அனைத்து இணைப்புகளையும் இதைக் கொண்டே உருவாக்குகிறது; எனவே தவறான மதிப்பை உள்ளிட்டால், password reset இணைப்புகள் பதிலளிக்காத host-க்குச் செல்லும்.

இப்போது upstream கோப்பில் உள்ள ஒரு சிக்கல். postgres service, .env-ஐ வாசிப்பதில்லை. இது தனது சொந்த environment தொகுதியைக் கொண்டுள்ளது, அதில் POSTGRES_PASSWORD= காலியாக விடப்பட்டுள்ளது. எனவே .env-ல் மட்டும் password-ஐ அமைத்தால், database-க்கு password இருக்காது, ஆனால் application-க்கு இருக்கும். எனவே அந்த service-ஐ அதே variable-க்கு சுட்டிக்காட்டவும்:

  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, ${...} மாற்றீட்டிற்காக project directory-லிருந்து .env-ஐ வாசிக்கிறது, எனவே இப்போது இரண்டு பக்கமும் ஒரே string கிடைக்கும். இதைச் சரியாகச் செய்யாவிட்டால், PG::ConnectionBad: FATAL: password authentication failed for user "postgres" பிழையுடன் Rails நின்றுவிடும்.

ஒரு செயல்பாடு பலரை ஆச்சரியப்படுத்தும்: Postgres image, காலியான data directory-ஐ initialize செய்யும்போது மட்டுமே POSTGRES_PASSWORD-ஐப் பயன்படுத்தும். அதன் பிறகு மதிப்பை மாற்றினால் எந்த மாற்றமும் இருக்காது, ஏனெனில் initdb மீண்டும் இயங்காது. நீங்கள் ஏற்கனவே stack-ஐ ஒருமுறை தொடங்கிவிட்டீர்கள் என்றால், database-க்கு உள்ளேயே மதிப்பை மாற்றவும்.

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

ENABLE_ACCOUNT_SIGNUP=true என்பது தற்காலிகமானது. இது பொதுப் பதிவு படிவத்தைத் (public registration form) திறக்கும், இதன் மூலம் நீங்கள் முதல் கணக்கை உருவாக்கலாம். உங்கள் கணக்கை உருவாக்கியவுடன், அதை false என மாற்றிவிட்டு, மீண்டும் docker compose up -d-ஐ இயக்கவும்; இல்லையெனில் URL-ஐக் கண்டறியும் எவரும் உங்கள் support desk-ல் பதிவு செய்ய முடியும். அதன் பிறகு, முகவர்கள் (agents) அழைப்பின் மூலம் மட்டுமே சேர முடியும், அவர்களின் கடவுச்சொற்கள் இந்த app-ல் மட்டுமே இருக்கும். நீங்கள் பல சேவைகளை இயக்கும்போது, ஒவ்வொன்றிற்கும் தனித்தனி கணக்கு வைத்திருப்பது கடினமாக இருக்கும்; அப்போது Authentik போன்ற self-hosted identity provider-ஐப் பயன்படுத்துவது சிறந்தது.

.env இப்போது இந்த stack-ன் அனைத்து ரகசியங்களையும் plain text-ல் கொண்டுள்ளது, எனவே இதை mode 600-ல் வைத்து, git-ல் பதிவேற்றாமல் பாதுகாக்கவும். Compose env கோப்புகளை எவ்வாறு வாசிக்கிறது மற்றும் ரகசியங்கள் எவ்வாறு கசிகின்றன என்ற கட்டுரை, env_file மற்றும் environment-க்கு இடையிலான வேறுபாடு உள்ளிட்ட நுணுக்கங்களை விளக்குகிறது.

Chatwoot-ஐ ஏற்கனவே உள்ள உங்கள் Traefik-க்கு பின்னால் அமைத்தல்

ஒரே application-க்காக இரண்டாவது reverse proxy-ஐ உருவாக்க வேண்டாம். இந்த server-ல் ஏற்கனவே உள்ள பிற container-களுக்கு Traefik மூலம் TLS (transport layer security) termination செய்யப்படுகிறது என்றால், Chatwoot-ஐ ஒரு label block மூலம் அதனுடன் இணைக்கலாம். உங்களிடம் இன்னும் அத்தகைய அமைப்பு இல்லை என்றால், பல Docker Compose செயலிகளுக்கு முன்னால் Traefik என்பதை ஒருமுறை அமைத்துவிட்டு, பிறகு இங்கே திரும்பவும்.

Upstream-ன் docker-compose.yaml கோப்பை அதன் இயல்பு நிலையிலேயே வைத்திருங்கள். அப்போதுதான் புதிய பதிப்பு வரும்போது அதை எளிதாக diff செய்ய முடியும். உங்கள் மாற்றங்களை ஒரு override கோப்பில் சேமிக்கவும். Compose தானாகவே docker-compose.override.yaml கோப்புகளை ஒன்றிணைக்கும். Compose கோப்புகளை பல பகுதிகளாகப் பிரித்தல் என்பது இந்த இணைப்பு விதிகளை விளக்குகிறது.

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

உங்களுடைய சொந்த entrypoint மற்றும் certresolver பெயர்களைப் பயன்படுத்தவும். இந்த container, Traefik இருக்கும் அதே Docker network-ல் இருக்க வேண்டும். அதற்காகவே proxy உள்ளீடு செய்யப்படுகிறது. மேலும், இது default-லும் இருக்க வேண்டும், இல்லையெனில் Postgres மற்றும் Redis உடனான இணைப்பு துண்டிக்கப்படும். இந்த இரண்டாவது வரியைத்தான் பலர் மறந்துவிடுகிறார்கள்.

ports: பகுதியை மாற்ற வேண்டாம். Upstream இதை 127.0.0.1:3000-உடன் இணைக்கிறது. இது loopback-க்கு மட்டுமே என்பதால், இணையத்திலிருந்து இதை நேரடியாக அணுக முடியாது. அதேசமயம், server-க்கு உள்ளிருந்தே curl -I http://127.0.0.1:3000 மூலம் சோதனைகளைச் செய்ய இது பயனுள்ளதாக இருக்கும்.

Agent dashboard, நேரலை செய்திகளைப் பெறுவதற்காக /cable-க்கு ஒரு websocket இணைப்பைத் திறந்து வைத்திருக்கும். Traefik எந்த கூடுதல் அமைப்பும் இன்றி HTTP upgrade-ஐ forward செய்துவிடும், எனவே இதில் புதிதாக எதையும் சேர்க்க வேண்டியதில்லை. ஒருவேளை நீங்கள் Traefik-க்கு முன்னால் CDN அல்லது வேறொரு proxy-ஐ அமைத்தால், அங்கே websocket-ஐ அனுமதிக்கவும். இல்லையெனில், dashboard சாதாரணமாகத் தெரியும், ஆனால் புதிய செய்திகள் manual refresh செய்த பிறகுதான் தோன்றும்.

Database-ஐத் தொடங்கி stack-ஐ இயக்கும் முறை

முதலில் data services-ஐத் தொடங்கி, Postgres அதன் முதல் run-ஐ முடிக்கும் வரை காத்திருக்கவும்.

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

database system is ready to accept connections-க்காகக் காத்திருக்கவும். பின் schema-வை உருவாக்கவும்.

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

இது database இல்லையெனில் அதை உருவாக்கி, schema மற்றும் default seed data-வை ஏற்றும். இது migration வரிகளை அச்சிட்டு, வெற்றிகரமாக வெளியேறும். இது postgres:5432 - no response-ஐத் தொடர்ந்து அச்சிட்டுக் கொண்டிருந்தால், database இன்னும் இணைப்புகளை ஏற்கத் தயாராகவில்லை என்று அர்த்தம்; முதல் run-ல் initdb இன்னும் இயங்கிக் கொண்டிருக்கிறது என்று பொருள். காத்திருந்து, Postgres logs-ஐப் படித்துவிட்டு, மீண்டும் இயக்கவும். இது vector extension-ல் நின்றால், நீங்கள் pgvector image-க்கு பதிலாக சாதாரண Postgres-ஐப் பயன்படுத்தியுள்ளீர்கள் என்று அர்த்தம்.

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

நான்கு containers-ம் Up என்று காட்ட வேண்டும், மேலும் rails log-ன் இறுதியில் Puma http://0.0.0.0:3000-ல் listening செய்வதைக் குறிக்கும் வரி இருக்க வேண்டும். பின் public path-ஐச் சரிபார்க்கவும்:

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

HTTP/2 200 என்பது முழு சங்கிலியும் சரியாக வேலை செய்கிறது என்பதைக் குறிக்கும். Traefik-லிருந்து 404 பிழை வந்தால், router rule பொருந்தவில்லை என்று அர்த்தம்; பெரும்பாலும் hostname-ல் எழுத்துப் பிழை இருக்கலாம். 502 பிழை வந்தால், Traefik router-ஐக் கண்டறிந்துவிட்டது, ஆனால் container-ஐ அடைய முடியவில்லை என்று அர்த்தம்; இது பெரும்பாலும் proxy network விடுபட்டதாலோ அல்லது loadbalancer.server.port 3000-ஆக இல்லாததாலோ நிகழும்.

URL-ஐத் திறந்து, /app/auth/signup-ல் உங்கள் கணக்கை உருவாக்கவும், பின் ENABLE_ACCOUNT_SIGNUP=false-ஐ அமைத்து, படிவத்தை மூட docker compose up -d-ஐ இயக்கவும்.

SMTP இல்லாமல் கடவுச்சொல் மீட்டமைப்பு மற்றும் மின்னஞ்சல் உரையாடல்கள் ஏன் தோல்வியடைகின்றன

SMTP (Simple Mail Transfer Protocol) அமைப்புகள் இல்லாத Chatwoot, மின்னஞ்சல்களை அனுப்ப முடியாத ஒரு support desk ஆகிவிடும். இது அறிவிப்புகளை மட்டும் பாதிக்காது; கடவுச்சொல் மீட்டமைப்பு (password reset) வேலை செய்யாது, எனவே லாக்-அவுட் ஆன நிர்வாகி மீண்டும் உள்ளே நுழைய முடியாது. முகவர் அழைப்புகள் (agent invitations) மின்னஞ்சல் வழியாக அனுப்பப்படுவதால், அவையும் வேலை செய்யாது. வாடிக்கையாளரின் மின்னஞ்சலுக்குப் பதில் அனுப்பும் வசதியும் முடங்கிவிடும், இதனால் உரையாடல் ஒரு பக்கமாக மட்டுமே இருக்கும். பலரும் தவிர்க்கும் இந்த அமைப்பை, ஒரு இக்கட்டான சூழலில் மட்டுமே கவனிக்கிறார்கள்.

இதன் செயல்முறை எளிதானது. SMTP அமைப்புகள் இல்லை என்றால், ActionMailer தனது இயல்புநிலை அமைப்பான localhost-ஐ port 25-ல் பயன்படுத்த முயலும். Rails container-க்குள் மின்னஞ்சல் சேவையகம் (mail server) இல்லாததால், அந்த delivery job Errno::ECONNREFUSED: Connection refused - connect(2) for "localhost" port 25 என்ற பிழையை ஏற்படுத்தும். மின்னஞ்சல் ஒரு background job மூலம் அனுப்பப்படுவதால், இந்த பிழை Rails log-ல் வராது, Sidekiq log-ல் மட்டுமே பதிவாகும். இதற்கிடையில், "forgot password" என்பதைக் கிளிக் செய்யும் பயனர், மின்னஞ்சல் அனுப்பப்பட்டதாகத் திரையில் பார்த்தாலும், அவருக்கு எந்த மின்னஞ்சலும் கிடைக்காது.

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

STARTTLS உடன் port 587-ஐப் பயன்படுத்தவும். இது இணைப்பை plain text-ல் தொடங்கி, authentication-க்கு முன்பாகவே அதை encrypted ஆக மாற்றும். பெரும்பாலான VPS நிறுவனங்கள் spam-ஐத் தடுக்க port 25-ஐ முடக்கியுள்ளன, எனவே port 587-ல் உள்ள relay மட்டுமே பெரும்பாலும் வேலை செய்யும். SMTP_DOMAIN என்பது SMTP உரையாடலின் போது உங்கள் server அறிவிக்கும் domain ஆகும்; சில relay-கள் இதில் முரண்பாடு இருந்தால் இணைப்பை நிராகரிக்கும்.

அமைப்புகளைச் செயல்படுத்தி, worker-ஐக் கவனிக்கவும்:

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

Login பக்கத்திலிருந்து கடவுச்சொல் மீட்டமைப்பைத் தூண்டவும். மின்னஞ்சல் சரியாக அனுப்பப்பட்டால், Sidekiq log-ல் mailer job வெற்றிகரமாக முடிந்ததைக் காணலாம். தோல்வியடைந்தால், பிழை வகை (exception class) காட்டப்படும், மேலும் Sidekiq அதைத் தொடர்ந்து மீண்டும் மீண்டும் முயலும் (backoff). இதனால்தான், தவறான relay அமைப்புகள் பல மணிநேரங்களுக்குத் தொடர்ந்து பிழையை உருவாக்குகின்றன.

பொதுவாக இரண்டு வகையான நிராகரிப்புகள் ஏற்படும், இவை Chatwoot-ன் பிழைகள் அல்ல. 535 Authentication failed என்பது அந்த relay-க்கான பயனர் பெயர் அல்லது கடவுச்சொல் தவறானது என்று பொருள்; பல நிறுவனங்கள் கணக்கின் கடவுச்சொல்லுக்குப் பதிலாக application password-ஐப் பயன்படுத்தக் கோருகின்றன. 550 Sender address rejected என்பது MAILER_SENDER_EMAIL என்ற முகவரியிலிருந்து relay மின்னஞ்சலை அனுப்ப மறுக்கிறது என்று பொருள்; எனவே, நீங்கள் அந்த நிறுவனத்தில் சரிபார்த்த (verified) மின்னஞ்சல் முகவரி அல்லது domain-ஐ மட்டுமே பயன்படுத்த வேண்டும்.

உரையாடலுக்கு மின்னஞ்சல்களைப் பெறுவது ஒரு தனி வேலை. அதற்கு MAILER_INBOUND_EMAIL_DOMAIN மற்றும் RAILS_INBOUND_EMAIL_SERVICE, மற்றும் உள்வரும் மின்னஞ்சல்களை Chatwoot-க்கு அனுப்பும் ஒரு mail server தேவை. ஒரு relay-ஐ வாடகைக்கு எடுப்பது விரைவான வழி. மின்னஞ்சல் பாதையை முழுமையாக நீங்களே நிர்வகிக்க விரும்பினால், Mailcow மூலம் சொந்தமாக mail server-ஐ இயக்குதல் என்ற கட்டுரை, அதற்குத் தேவையான பணிகளை விளக்குகிறது.

எதை பேக்கப் எடுக்க வேண்டும் மற்றும் மீட்டெடுப்பு சரியாக வேலை செய்கிறதா என்பதை உறுதிப்படுத்துவது எப்படி

Chatwoot பேக்கப்பில் நான்கு பகுதிகள் உள்ளன. இதில் எதை விடுபட்டாலும், மீட்டெடுப்பு என்பது ஒரு முழுமையான மறுசீரமைப்பாக (rebuild) மாறிவிடும்.

• Postgres database: இது உரையாடல்கள், தொடர்புகள், ஏஜென்ட் கணக்குகள் மற்றும் அனைத்து அமைப்புகளையும் கொண்டுள்ளது.
• storage_data volume: ஏனெனில் ACTIVE_STORAGE_SERVICE=local பதிவேற்றப்பட்ட கோப்புகளை வட்டில் (disk) சேமித்து, Postgres-ல் அதற்கான குறிப்பை (reference row) மட்டுமே வைத்திருக்கும்.
• .env கோப்பு: ஏனெனில் இது SECRET_KEY_BASE மற்றும் ACTIVE_RECORD_ENCRYPTION_* சாவிகளை (keys) கொண்டுள்ளது.
• compose கோப்புகள்: ஏனெனில் இவை உங்கள் database schema-வுடன் பொருந்தக்கூடிய துல்லியமான image tag-ஐப் பதிவு செய்கின்றன.

database-ஐ மட்டும் மீட்டெடுத்தால், அனைத்து உரையாடல்களும் சிதைந்த இணைப்புகளுடன் (broken attachments) வரும். ஏனெனில், அந்த வரிசைகள் (rows) வட்டில் இல்லாத கோப்புகளைச் சுட்டிக்காட்டும்.

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

-T முக்கியமானது. இது இல்லையென்றால், Compose ஒரு pseudo terminal-ஐ ஒதுக்கும். இது stream-ல் உள்ள newline bytes-ஐ மாற்றி எழுதும், இதனால் pg_restore நிராகரிக்கும் ஒரு dump கோப்பு கிடைக்கும். -Fc என்பது தனிப்பயன் வடிவமாகும் (custom format), இது கோப்பைச் சுருக்கி, pg_restore தேர்ந்தெடுக்கப்பட்ட முறையில் வேலை செய்ய அனுமதிக்கிறது.

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

volume பெயர் என்பது உங்கள் project directory பெயர் மற்றும் _storage_data சேர்ந்ததாகும். அந்த கட்டளையை நம்புவதற்கு முன் docker volume ls | grep storage_data மூலம் அதை உறுதிப்படுத்தவும். ஏனெனில், இல்லாத ஒரு பெயரை நீங்கள் குறிப்பிடும்போது, Docker பிழையைக் காட்டாமல் ஒரு காலியான volume-ஐ உருவாக்கிவிடும். உங்களுக்கு பிழை ஏதுமின்றி ஒரு செல்லுபடியாகும், ஆனால் காலியான archive கிடைக்கும். பிறகு ls -lh storage-*.tgz மூலம் கோப்பின் அளவைச் சரிபார்க்கவும்.

இப்போது இரண்டு கோப்புகளும் அவை பாதுகாக்க வேண்டிய அதே வட்டில் உள்ளன, இது எந்தப் பாதுகாப்பையும் வழங்காது. அவற்றை server-லிருந்து வெளியேற்றி, encrypt செய்யவும். ஏனெனில், database dump-ல் ஒவ்வொரு வாடிக்கையாளரின் செய்தியும் plain text-ல் இருக்கும். restic மூலம் encrypt செய்யப்பட்ட off-site பேக்கப்கள் பகுதியில் இதற்கான கால அட்டவணை மற்றும் சேமிப்பு முறை விளக்கப்பட்டுள்ளது.

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

Chatwoot-ஐ புதிய tag-க்கு upgrade செய்வது எப்படி

கட்டளைகளை விட, அவற்றைச் செயல்படுத்தும் வரிசைமுறை மிக முக்கியமானது.

1. உங்கள் தற்போதைய tag-க்கும் இலக்கு tag-க்கும் இடைப்பட்ட release notes-ஐ வாசிக்கவும்; அதில் ஏதேனும் கைமுறை மாற்றங்கள் (manual steps) தேவைப்படுகிறதா என்று பார்க்கவும்.
2. database-ன் புதிய dump மற்றும் storage-ன் archive-ஐ எடுக்கவும்; இரண்டு கோப்புகளின் அளவும் சரியாக உள்ளதா என்று சரிபார்க்கவும்.
3. docker-compose.yaml-ல் உள்ள base service-ன் image tag-ஐ மாற்றவும்.
4. புதிய image-ஐ pull செய்யவும், stack-ஐ நிறுத்தவும், migrations-ஐ இயக்கவும், பிறகு மீண்டும் தொடங்கவும்.

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

Migration-ஐ இயக்குவதற்கு முன்பே புதிய image-ஐ pull செய்யவும். ஏனெனில், புதிய migration கோப்புகள் புதிய image-ல் மட்டுமே இருக்கும்; பழைய image-ல் அவை இருக்காது. Migration-ஐ இயக்குவதற்கு முன் stack-ஐ நிறுத்தவும். ஏனெனில், பழைய code-க்கும் புதிய schema-வுக்கும் இடையே முரண்பாடு ஏற்படலாம்; இதனால் இயங்கிக்கொண்டிருக்கும் பழைய Rails process பிழைகளை உருவாக்கலாம் அல்லது புதிய schema ஏற்காத தரவுகளை எழுதலாம். மேலும், migration-க்குத் தேவையான memory-ஐ விடுவிக்க stack-ஐ நிறுத்துவது அவசியம்; இதனால்தான் upstream-ல் swap தேவைப்படுகிறது.

ஒவ்வொரு container-ம் தற்போது எந்த tag-ல் இயங்குகிறது என்பதை docker compose images காட்டும். tag-ஐ மாற்றிவிட்டு pull செய்ய மறந்துவிட்டால், இந்த கட்டளை அதை உறுதிப்படுத்தும்.

ஒரே நேரத்தில் பல பதிப்புகளைத் தாண்டி upgrade செய்ய வேண்டாம். பழைய install-களுக்கு, இடைப்பட்ட tag-கள் வழியாகச் செல்வதே upstream-ன் அறிவுரை. ஏனெனில், அடிப்படை schema-வுடன் இணைக்கப்பட்ட பிறகு பழைய migrations நீக்கப்படலாம்; இதனால் மிகப்பழைய database-ஐ upgrade செய்ய வழி இல்லாமல் போகலாம். ஒரு நேரத்தில் ஒரு minor version-ஆக நகர்ந்து, ஒவ்வொரு முறையும் prepare படியை இயக்கவும்.

Migration இயங்குவதற்கு முன்பே Rails தொடங்கினால், அது சேவையை வழங்க மறுத்து ActiveRecord::PendingMigrationError: Migrations are pending என்று log செய்யும். restart: always அமைக்கப்பட்டிருந்தால், container மீண்டும் மீண்டும் restart ஆகும்; இதனால் docker compose ps-ல் uptime சில வினாடிகளுக்கு ஒருமுறை reset ஆவதைக் காணலாம். Prepare படியை இயக்கினால் இந்தப் பிரச்சனை சரியாகிவிடும்.

Rollback செய்வது என்பது பழைய tag-ஐ மீண்டும் அமைத்து, dump-ஐ restore செய்வதாகும். நம்பகமான reverse migration வழிமுறை எதுவும் இல்லை என்பதால், 2-வது படி மிக முக்கியமானது.

தோல்வி முறைகள் மற்றும் நீங்கள் காணும் செய்திகள்

Traefik-லிருந்து 502 Bad Gateway. router கோரிக்கையை ஏற்றுக்கொண்டது, ஆனால் backend பதிலளிக்கவில்லை. docker compose ps-ஐச் சரிபார்த்து rails என்பது Up என உள்ளதா என்று பார்க்கவும், பின் docker network inspect proxy-ஐ இயக்கி rails container அதன் பட்டியலில் உள்ளதா என்பதை உறுதிப்படுத்தவும். ஒரு container இணைக்கப்படவில்லை என்றால், அது Traefik-க்குத் தெரியாது; எனவே கோரிக்கை router-ஐ அடைந்தாலும், அது செல்ல வேண்டிய இடத்திற்குச் செல்லாது.

Dashboard ஏற்றப்படுகிறது, ஆனால் புதிய செய்திகளுக்கு refresh தேவைப்படுகிறது. /cable-க்கான websocket இணைக்கப்படவில்லை, அல்லது FRONTEND_URL உலாவியின் முகவரிப் பட்டியில் உள்ள முகவரியுடன் பொருந்தவில்லை. முரண்பாடு இருந்தால், பக்கம் வேறொரு origin-க்கு websocket-ஐத் திறக்க முயலும், அதை உலாவி தடுக்கும்.

FATAL: password authentication failed for user "postgres". .env-ல் உள்ள கடவுச்சொல்லும், Postgres தரவுத் தொகுப்பில் (data volume) உள்ள கடவுச்சொல்லும் வெவ்வேறாக உள்ளன. இயங்கிக்கொண்டிருக்கும் container-க்குள் ALTER USER மூலம் இதைச் சரிசெய்யவும், ஏனெனில் .env-ஐ மீண்டும் திருத்தினாலும் ஏற்கனவே initialized செய்யப்பட்ட தரவுத்தளத்தில் மாற்றம் ஏற்படாது.

NOAUTH Authentication required. Redis --requirepass-உடன் இயங்குகிறது, ஆனால் application கடவுச்சொல் இன்றி இணைக்க முயல்கிறது. எனவே REDIS_PASSWORD என்பது .env-ல் விடுபட்டுள்ளது அல்லது எடுத்துக்கொள்ளப்படவில்லை. இதை நேரடியாக docker compose exec redis redis-cli -a "$REDIS_PASSWORD" ping மூலம் சோதிக்கவும், இது PONG எனப் பதிலளிக்க வேண்டும்.

Containers code 137-உடன் வெளியேறுகின்றன. இது SIGKILL ஆகும். சிறிய server-களில் இது kernel-ன் out of memory killer-ஆல் நிகழ்கிறது. Swap-ஐச் சேர்க்கவும், ஒவ்வொரு service-க்கும் memory வரம்புகளை அமைக்கவும், அல்லது பெரிய server plan-க்கு மாறவும்.

FAQ

Chatwoot-ஐ self-host செய்ய ஒரு VPS-க்கு எவ்வளவு RAM தேவை?

ஆகஸ்ட் 2026 நிலவரப்படி, ஒரு நாளைக்கு 10,000 உரையாடல்களைக் கையாள குறைந்தபட்சம் 4 GB RAM மற்றும் 4 CPU cores தேவை என upstream பரிந்துரைக்கிறது. 20,000 உரையாடல்களுக்கு 8 GB RAM மற்றும் 8 cores தேவை. குறைந்தது 1 GB swap memory-ஐச் சேர்க்கவும்; ஏனெனில் upgrade செய்யும்போது migrations-ஐப் பயன்படுத்த இரண்டாவது Rails process இயங்கும், அப்போதுதான் குறைந்த திறன் கொண்ட server-களில் memory பற்றாக்குறை ஏற்படும். 2 GB VPS-ல் சில agents-க்கு இது வேலை செய்யும், ஆனால் அதிக சுமை இருக்கும்போது Sidekiq மட்டுமே 1 GB-க்கு மேல் memory-ஐப் பயன்படுத்தும். எனவே, அதிக வேலைப்பளு இருக்கும்போதும், upgrade செய்யும்போதும் containers exit code 137 மூலம் நிறுத்தப்பட வாய்ப்புள்ளது.

Chatwoot password reset மின்னஞ்சல்கள் ஏன் வருவதில்லை?

SMTP அமைப்புகள் configure செய்யப்படாததே இதற்குக் காரணம். இதனால் ActionMailer, localhost-ல் உள்ள port 25-க்கு மின்னஞ்சலை அனுப்ப முயல்கிறது, ஆனால் container-க்குள் mail server இல்லை. இதனால் Sidekiq-ல் அந்த வேலை Errno::ECONNREFUSED: Connection refused - connect(2) for "localhost" port 25 பிழையுடன் தோல்வியடைகிறது, அதேசமயம் browser-ல் வெற்றிச் செய்தி காட்டப்படுகிறது. .env கோப்பில் SMTP_ADDRESS, SMTP_PORT, SMTP_USERNAME, SMTP_PASSWORD மற்றும் MAILER_SENDER_EMAIL ஆகியவற்றை அமைத்து, rails மற்றும் sidekiq services-ஐ restart செய்யவும். பின்னர், reset செய்யும்போது docker compose logs -f sidekiq-ஐக் கண்காணிக்கவும்.

Chatwoot-ஐ restore செய்ய எவற்றையெல்லாம் backup எடுக்க வேண்டும்?

Postgres database, storage_data Docker volume, .env கோப்பு மற்றும் compose கோப்புகள். Database-ஐ மட்டும் backup எடுத்தால் போதாது; ஏனெனில் பதிவேற்றப்பட்ட கோப்புகள் volume-ல் இருக்கும், Postgres-ல் அவற்றிற்கான references மட்டுமே இருக்கும். எனவே, database-ஐ மட்டும் restore செய்தால், இணைப்புகள் (attachments) வேலை செய்யாத உரையாடல்களே கிடைக்கும். .env முக்கியமானது, ஏனெனில் வேறொரு SECRET_KEY_BASE இருந்தால் அனைத்து பயனர்களும் வெளியேற்றப்படுவார்கள் (sign out), மேலும் வேறொரு ACTIVE_RECORD_ENCRYPTION_* சாவிகள் இருந்தால் encrypted columns-ஐப் படிக்க முடியாது.

Database-ஐப் பாதிக்காமல் Chatwoot-ஐ எப்படி upgrade செய்வது?

முதலில் backup எடுக்கவும், உங்கள் compose கோப்பில் உள்ள image tag-ஐ மாற்றவும், பிறகு docker compose pull, docker compose down, docker compose run --rm rails bundle exec rails db:chatwoot_prepare மற்றும் docker compose up -d ஆகிய கட்டளைகளை இயக்கவும். புதிய image-லிருந்துதான் migrations இயங்க வேண்டும் என்பதால், முதலில் pull செய்யவும். பழைய code புதிய schema-வுடன் இயங்கும்போது பிழைகள் ஏற்படும் என்பதால், முதலில் stack-ஐ நிறுத்தவும். பழைய installation-ஆக இருந்தால், ஒரு நேரத்தில் ஒரு minor version-ஆக upgrade செய்யவும், ஏனெனில் migrations base schema-வில் இணைக்கப்பட்ட பிறகு அவை நீக்கப்பட்டுவிடும்.

pgvector-க்கு பதிலாக standard postgres image-ஐப் பயன்படுத்தலாமா?

கூடாது. Chatwoot-ன் schema vector extension-ஐப் பயன்படுத்துகிறது. எனவே, சாதாரண postgres image-ஐப் பயன்படுத்தினால் db:chatwoot_prepare-ன் போது ERROR: extension "vector" is not available பிழை ஏற்படும், ஏனெனில் அந்த image-ல் extension-க்கான control கோப்பு இருக்காது. Upstream compose கோப்பில் உள்ள pgvector/pgvector:pg16-ஐ அப்படியே பயன்படுத்தவும் அல்லது உங்கள் Postgres major version-க்கு ஏற்ற pgvector வசதி கொண்ட மற்றொரு image-ஐப் பயன்படுத்தவும்.