Docker తో VPS పై Chatwoot self-host ఎలా చేయాలి

మీరు ఏమి నిర్మిస్తున్నారు

VPS పై Chatwoot ను self-host చేయడానికి మీరు నాలుగు containers ను నడుపుతారు: ఒక Rails web process, ఒక Sidekiq background worker, pgvector extension తో కూడిన PostgreSQL, మరియు Redis. Chatwoot అనేది ఒక open source customer support desk, కాబట్టి మీరు నియంత్రించే సర్వర్‌లో ఒక shared team inbox మరియు website chat widget లభిస్తాయి. ఈ ఇన్‌స్టాలేషన్ సుమారు ఇరవై నిమిషాలు పడుతుంది. ఆ తర్వాత వచ్చే మెయిల్ డెలివరీ, బ్యాకప్‌లు, అప్‌గ్రేడ్‌లు మరియు సైజింగ్ వంటి అంశాలే, ఒక సంవత్సరం తర్వాత కూడా ఈ సేవ నడుస్తుందా లేదా అని నిర్ణయిస్తాయి.

ప్రతి container కు ఒకే పని ఉంటుంది. Rails ఏజెంట్ డాష్‌బోర్డ్ మరియు widget API (application programming interface) ను అందిస్తుంది. Sidekiq నెమ్మదిగా జరిగే పనులను చేస్తుంది: ఇమెయిల్ పంపడం, కనెక్ట్ చేయబడిన ఛానెల్‌లను పోల్ చేయడం, ఆటోమేషన్ నియమాలను అమలు చేయడం మరియు రిపోర్టులను రూపొందించడం. Postgres సంభాషణలు, కాంటాక్ట్‌లు, ఏజెంట్ ఖాతాలు మరియు మీరు డాష్‌బోర్డ్‌లో మార్చే ప్రతి సెట్టింగ్‌ను భద్రపరుస్తుంది. Redis లో Sidekiq క్యూలు మరియు ActionCable pub/sub ఛానెల్ ఉంటాయి, ఇవి పేజీని రీలోడ్ చేయకుండానే కొత్త సందేశాన్ని ఓపెన్ డాష్‌బోర్డ్‌లోకి పంపుతాయి. ఇక్కడ Redis కేవలం తాత్కాలిక cache కాదు, ఎందుకంటే అది పోతే క్యూలో ఉన్న పనులు కూడా పోతాయి.

Upstream compose ఫైల్‌లోని Postgres ఇమేజ్ స్టాక్ postgres ఇమేజ్ కాకుండా pgvector/pgvector:pg16 గా ఉంటుంది, ఎందుకంటే Chatwoot యొక్క schema దాని AI ఫీచర్ల కోసం vector extension ను ఎనేబుల్ చేస్తుంది. ఒకవేళ మీరు స్టాక్ Postgres ను ఉపయోగిస్తే, ఆ ఇమేజ్‌లో extension యొక్క కంట్రోల్ ఫైల్ లేనందున మొదటి డేటాబేస్ రన్ ERROR: extension "vector" is not available తో ఆగిపోతుంది. Upstream వారు అందించే ఇమేజ్‌నే వాడండి.

ఈ గైడ్ మీ సర్వర్‌లో Docker మరియు reverse proxy ఇప్పటికే పనిచేస్తున్నాయని భావిస్తుంది. ఒకవేళ అవి లేకపోతే, Docker Compose on a VPS తో ప్రారంభించి తిరిగి రండి.

Self-hosted Chatwoot కు ఎంత VPS అవసరం?

2026 అక్టోబర్ నాటికి upstream requirements page కనీసంగా 4 GB RAM మరియు 4 CPU cores కోరుతోంది. ఈ స్థాయి రోజుకు గరిష్ఠంగా 10,000 conversations వరకు నిర్వహించగలదని పేర్కొంటోంది. 8 GB RAM మరియు 8 cores ఉన్న వ్యవస్థ రోజుకు గరిష్ఠంగా 20,000 conversations వరకు నిర్వహించగలదని చెబుతోంది. కనీసం 1 GB swap కూడా అవసరం. కారణాన్ని కూడా స్పష్టంగా ఇస్తోంది: upgrade సమయంలో machine memory అయిపోకుండా ఉండటానికి. File uploads ను లెక్కలోకి తీసుకోకముందు Postgres కోసం 5 GB నుంచి 10 GB disk కేటాయించండి.

ఇప్పుడు స్పష్టంగా చెప్పాలంటే, 2 GB VPS లో Chatwoot ప్రారంభమవుతుంది. ఇద్దరు agents మరియు తక్కువ activity ఉన్న inbox తో అది సరిగానే కనిపిస్తుంది. కానీ రెండు సందర్భాల్లో విఫలమవుతుంది. మొదటిది Sidekiq. Busy server లో ఇది 1 GB కంటే ఎక్కువ memory ఉపయోగిస్తుందని upstream కొలిచింది. అందువల్ల email లేదా report job అకస్మాత్తుగా పెరిగితే, Rails, Postgres మరియు Redis తమ memory భాగాన్ని తీసుకునేలోపే machine memory పరిమితిని దాటుతుంది. రెండవది upgrade. ఎందుకంటే migrations అమలు చేయడానికి db:chatwoot_prepare కొత్త Rails process ను ప్రారంభిస్తుంది. ఈ image లో Rails boot ఉపయోగకరమైన పని ప్రారంభించేలోపే వందల MB memory ఉపయోగిస్తుంది.

ముందుగా మీకు స్పష్టమైన warning రాదు. Kernel యొక్క out of memory killer తాను ఎంచుకున్న process కు SIGKILL పంపుతుంది. సాధారణంగా అది అత్యధిక memory ఉపయోగిస్తున్న process అయి ఉంటుంది. Docker ఆ container ఆగిపోయిందని గుర్తించి, restart: always దాన్ని మళ్లీ ప్రారంభిస్తుంది. తరువాత docker compose ps --all నిరంతరం restarting అవుతున్న container ను లేదా Exited (137) వద్ద ఉన్న container ను చూపిస్తుంది. ఇక్కడ 137 అంటే signal 9 వల్ల process terminate అయిందని అర్థం. --all లేకపోతే stopped container అసలు జాబితాలో కనిపించదు. Exit code 137 మాత్రమే memory కారణమని నిరూపించదు. ఎందుకంటే docker kill కూడా అదే signal పంపుతుంది. అందువల్ల kernel ఎంచుకున్న process పేరును చూపించే sudo dmesg -T | grep -i "killed process" తో నిర్ధారించండి.

4 GB మీ బడ్జెట్‌కు మించినదైతే, 2 GB machine ను 2 GB swap తో నడపండి. Load పెరిగినప్పుడు response times ఎక్కువ అవుతాయని అంగీకరించాలి. Swap memory అయిపోకుండా ఉండేందుకు ఉపయోగపడే buffer మాత్రమే; ఇది హామీ కాదు. Burst తగినంత ఎక్కువగా ఉంటే container అయినా terminate కావచ్చు. ఏ పరిస్థితిలోనైనా ప్రతి service కు hard memory ceiling నిర్ణయించడం మంచిది. అప్పుడు worker దానితో పాటు database ను కూడా down చేయలేడు. Docker Compose లో memory limits చూడండి.

File uploads కు మీరు నిర్ణయించిన పరిమితి లేకపోతే అవే నిరంతరం పెరుగుతాయి. Customer జత చేసే ప్రతి screenshot storage volume లో చేరి అక్కడే ఉంటుంది. అందువల్ల disk నిండింది database వల్లేనని అనుకోకుండా docker system df -v ను monitor చేయండి.

Compose ఫైల్‌ను పొందండి, version tag ను స్థిరపరచండి

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

మీరు ఇప్పుడే download చేసిన ఫైల్‌లో image: chatwoot/chatwoot:latest ఉంది. మరేదైనా చేసే ముందు దాన్ని మార్చండి.

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

latest అంటే తదుపరి docker compose pull ఆ ఉదయం publish చేసిన ఏదైనా version ను తీసుకుంటుంది. మీరు చదవని migrations కలిగిన major version కూడా అందులో ఉండవచ్చు. Chatwoot migrations వాస్తవ వినియోగంలో reversible కావు. కాబట్టి అనుకోకుండా version మారితే undo చేయడం సాధ్యం కాదు; backup నుంచి restore చేయాలి. tag ను స్థిరపరచి, దాన్ని ఉద్దేశపూర్వకంగా మార్చండి. October 2026 నాటికి v4.18.0 ప్రస్తుత release. Security fixes కోసం release notes దీన్ని సిఫార్సు చేస్తున్నాయి. ఈ రోజు మీరు స్థిరపరచాల్సిన tag కోసం releases పేజీ చూడండి. Database ను నిర్వహించే ఏదైనా సాఫ్ట్‌వేర్‌కు ఇదే జాగ్రత్త అవసరం. అందుకే openGym workout tracker ను self-host చేయడం ఈ అప్లికేషన్ కంటే చాలా చిన్నదైనా, ముందుగా git tag ను స్థిరపరచడంతో ప్రారంభమవుతుంది.

base service ఒక YAML anchor. rails మరియు sidekiq రెండూ దాన్ని merge చేస్తాయి. అందువల్ల tag ను ఒక చోట మార్చితే రెండింటికీ మారుతుంది. మీరు ఫైల్‌లో ఉన్నప్పుడే, పైభాగంలోని version: '3' line ను తొలగించండి. Modern Compose దాన్ని పట్టించుకోదు. ప్రతి command సమయంలో the attribute 'version' is obsolete, it will be ignored ను ప్రింట్ చేస్తుంది.

.env ఫైల్‌ను నింపండి

ముందుగా secret ను రూపొందించండి. అక్షరాలు మరియు అంకెలు మాత్రమే ఉన్న విలువను ఉపయోగించాలని upstream సూచిస్తుంది, ఎందుకంటే ప్రత్యేక అక్షరాలు shell లేదా YAML parser ద్వారా వెళ్ళేటప్పుడు పాడయ్యే అవకాశం ఉంది.

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

ఆ తర్వాత .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 మరియు redis://redis:6379 అనేవి Compose సర్వీస్ పేర్లు, ఇవి ప్రాజెక్ట్ యొక్క డిఫాల్ట్ నెట్‌వర్క్‌లో రిజాల్వ్ అవుతాయి. FRONTEND_URL అనేది కేవలం అలంకారం కాదు. Chatwoot విడ్జెట్ స్క్రిప్ట్ URL ను మరియు బయటకు వెళ్లే ప్రతి ఇమెయిల్‌లోని లింక్‌లను దీని ఆధారంగానే నిర్మిస్తుంది, కాబట్టి తప్పుడు విలువను ఇస్తే, పాస్‌వర్డ్ రీసెట్ లింక్‌లు స్పందించని హోస్ట్‌కు దారితీస్తాయి.

ఇప్పుడు upstream ఫైల్‌లో ఉన్న ఒక చిక్కు ఉంది. postgres సర్వీస్ .env ను చదవదు. ఇది సొంతంగా environment బ్లాక్‌ను కలిగి ఉంటుంది, అందులో POSTGRES_PASSWORD= ఖాళీగా ఉంటుంది. కాబట్టి .env లో మాత్రమే పాస్‌వర్డ్‌ను సెట్ చేస్తే, డేటాబేస్‌కు పాస్‌వర్డ్ ఉండదు, కానీ అప్లికేషన్‌కు ఉంటుంది. సర్వీస్‌ను అదే వేరియబుల్‌కు పాయింట్ చేయండి:

  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 ప్రాజెక్ట్ డైరెక్టరీ నుండి .env ను ${...} సబ్‌స్టిట్యూషన్ కోసం చదువుతుంది, కాబట్టి ఇప్పుడు రెండు వైపులా ఒకే స్ట్రింగ్ ఉంటుంది. ఇది తప్పుగా ఉంటే, Rails PG::ConnectionBad: FATAL: password authentication failed for user "postgres" తో ఆగిపోతుంది.

ఒక ప్రవర్తన అందరినీ ఆశ్చర్యపరుస్తుంది: Postgres ఇమేజ్ POSTGRES_PASSWORD ను కేవలం ఖాళీ డేటా డైరెక్టరీని ప్రారంభించేటప్పుడు మాత్రమే వర్తింపజేస్తుంది. ఆ తర్వాత విలువను మార్చినా ఎటువంటి ప్రభావం ఉండదు, ఎందుకంటే initdb రెండోసారి రన్ అవ్వదు. మీరు ఇప్పటికే stack ను ఒకసారి ప్రారంభించి ఉంటే, డేటాబేస్ లోపలే దాన్ని మార్చండి.

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

ENABLE_ACCOUNT_SIGNUP=true అనేది తాత్కాలికమైనది. ఇది పబ్లిక్ రిజిస్ట్రేషన్ ఫారమ్‌ను తెరుస్తుంది, తద్వారా మీరు మొదటి ఖాతాను సృష్టించవచ్చు. దీన్ని false గా సెట్ చేయండి మరియు మీ ఖాతా సృష్టించబడిన వెంటనే docker compose up -d ను మళ్ళీ రన్ చేయండి, లేకపోతే URL తెలిసిన ఎవరైనా మీ సపోర్ట్ డెస్క్‌లో రిజిస్టర్ చేసుకోవచ్చు. ఆ తర్వాత ఏజెంట్లు ఆహ్వానం ద్వారా మాత్రమే వస్తారు మరియు వారి పాస్‌వర్డ్‌లు ఈ యాప్‌లోనే ఉంటాయి. మీరు అరడజను సేవలను నడుపుతూ, ప్రతిదానికీ విడివిడి ఖాతాల జాబితాను నిర్వహించడం విసుగు తెప్పిస్తే, అప్పుడు Authentik వంటి self-hosted identity provider వాటి స్థానంలో ఉపయోగపడుతుంది.

.env ఇప్పుడు ఈ stack కు సంబంధించిన ప్రతి secret ను plain text లో కలిగి ఉంది, కాబట్టి దీన్ని mode 600 లో ఉంచండి మరియు git లోకి వెళ్లకుండా చూడండి. Compose env ఫైళ్లను ఎలా చదువుతుంది మరియు secrets ఎక్కడ లీక్ అవుతాయి అనే అంశం, env_file మరియు environment మధ్య వ్యత్యాసంతో సహా, ఇందులో ఉన్న ప్రమాదకరమైన అంశాలను వివరిస్తుంది.

మీ ప్రస్తుత Traefik వెనుక Chatwoot ను ఉంచడం

ఒకే అప్లికేషన్ కోసం రెండవ reverse proxy ని నిర్మించవద్దు. ఈ సర్వర్‌లో ఇతర కంటైనర్ల కోసం Traefik ఇప్పటికే TLS (transport layer security) ను నిర్వహిస్తుంటే, Chatwoot ను ఒక label block ద్వారా దానికి అనుసంధానించవచ్చు. ఒకవేళ మీరు ఇంకా అలా చేయకపోతే, అనేక Docker Compose అప్లికేషన్ల ముందు Traefik ను ఒకసారి సెటప్ చేసి, ఆపై ఇక్కడికి తిరిగి రండి.

అప్‌స్ట్రీమ్ యొక్క 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 పేర్లను ఉపయోగించండి. కంటైనర్ తప్పనిసరిగా Traefik ఉన్న అదే Docker నెట్‌వర్క్‌లో ఉండాలి, దీని కోసమే proxy ఎంట్రీని ఉపయోగిస్తాము. అలాగే, అది default లో కూడా ఉండాలి, లేకపోతే అది Postgres మరియు Redis కనెక్షన్‌లను కోల్పోతుంది. చాలామంది మర్చిపోయేది ఈ రెండవ లైన్ గురించే.

ports: బ్లాక్‌ను మార్చవద్దు. అప్‌స్ట్రీమ్ దీనిని 127.0.0.1:3000 కి బైండ్ చేస్తుంది, ఇది కేవలం loopback మాత్రమే. కాబట్టి ఇది ఇంటర్నెట్ నుండి అందుబాటులో ఉండదు, కానీ curl -I http://127.0.0.1:3000 ఉపయోగించి సర్వర్ లోపల నుండి పరీక్షించడానికి ఇది ఉపయోగకరంగా ఉంటుంది.

ఏజెంట్ డాష్‌బోర్డ్ లైవ్ మెసేజ్ డెలివరీ కోసం /cable కి ఒక websocket ను ఓపెన్‌గా ఉంచుతుంది. Traefik ఎటువంటి అదనపు కాన్ఫిగరేషన్ లేకుండానే HTTP upgrade ను ఫార్వార్డ్ చేస్తుంది, కాబట్టి దీని కోసం ప్రత్యేకంగా ఏమీ జోడించాల్సిన అవసరం లేదు. ఒకవేళ మీరు భవిష్యత్తులో Traefik ముందు ఒక CDN లేదా మరొక proxy ని ఉంచితే, అక్కడ websockets ను అనుమతించండి. లేకపోతే, డాష్‌బోర్డ్ సాధారణంగా లోడ్ అవుతుంది కానీ కొత్త సందేశాలు మాత్రం మాన్యువల్‌గా రిఫ్రెష్ చేసిన తర్వాతే కనిపిస్తాయి.

డేటాబేస్‌ను ప్రారంభించి, స్టాక్‌ను రన్ చేయడం

ముందుగా డేటా సేవలను ప్రారంభించండి, Postgres తన మొదటి రన్‌ను పూర్తి చేసే వరకు వేచి ఉండండి.

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

database system is ready to accept connections కోసం వేచి ఉండండి. ఆ తర్వాత స్కీమాను క్రియేట్ చేయండి.

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

ఇది డేటాబేస్ లేకపోతే కొత్తగా సృష్టిస్తుంది, ఆపై స్కీమాను మరియు డిఫాల్ట్ సీడ్ డేటాను లోడ్ చేస్తుంది. ఇది మైగ్రేషన్ లైన్లను ప్రింట్ చేసి, విజయవంతంగా ముగుస్తుంది. ఒకవేళ ఇది postgres:5432 - no response అని ప్రింట్ చేస్తూ ఆగిపోతే, ఎంట్రీ పాయింట్ ఇంకా కనెక్షన్‌లను స్వీకరించని డేటాబేస్ కోసం వేచి ఉంటోందని అర్థం. మొదటిసారి రన్ చేస్తున్నప్పుడు, సాధారణంగా initdb ఇంకా పని చేస్తూ ఉండటం వల్ల ఇలా జరుగుతుంది. వేచి ఉండండి, Postgres లాగ్స్‌ను చదవండి, ఆపై మళ్ళీ రన్ చేయండి. ఒకవేళ ఇది vector ఎక్స్‌టెన్షన్ వద్ద ఆగిపోతే, మీరు pgvector ఇమేజ్‌ను స్టాక్ Postgres తో భర్తీ చేశారని అర్థం.

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

నాలుగు కంటైనర్లు Up అని చూపించాలి, మరియు రైల్స్ లాగ్ చివరలో Puma http://0.0.0.0:3000 పోర్ట్ వద్ద వింటున్నట్లు (listening) ఉండాలి. ఆ తర్వాత పబ్లిక్ పాత్‌ను తనిఖీ చేయండి:

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

HTTP/2 200 అంటే మొత్తం చైన్ సరిగ్గా పనిచేస్తోందని అర్థం. Traefik నుండి 404 ఎర్రర్ వస్తే, రౌటర్ రూల్ మ్యాచ్ కాలేదని అర్థం, సాధారణంగా హోస్ట్‌నేమ్ టైపింగ్ తప్పుగా ఉండటం వల్ల ఇలా జరుగుతుంది. 502 ఎర్రర్ అంటే Traefik రౌటర్‌ను మ్యాచ్ చేసింది కానీ కంటైనర్‌ను చేరుకోలేకపోయిందని అర్థం. ఇది దాదాపు ఎప్పుడూ proxy నెట్‌వర్క్ లేకపోవడం వల్ల లేదా loadbalancer.server.port పోర్ట్ 3000 కాకపోవడం వల్ల జరుగుతుంది.

URLని ఓపెన్ చేయండి, /app/auth/signup వద్ద మీ ఖాతాను సృష్టించండి, ఆపై ENABLE_ACCOUNT_SIGNUP=false సెట్ చేసి, ఫారమ్‌ను క్లోజ్ చేయడానికి docker compose up -d రన్ చేయండి.

SMTP లేకుండా password resetలు మరియు email conversations ఎందుకు విఫలమవుతాయి

SMTP (simple mail transfer protocol) settings లేకుండా Chatwoot అనేది email పంపలేని support desk. దీని వల్ల notifications మాత్రమే కాకుండా మరెన్నో విధులు ఆగిపోతాయి. Password resetలు పనిచేయవు. అందువల్ల account నుంచి బయటపడిన admin తిరిగి ప్రవేశించలేరు. Agent invitations కూడా పనిచేయవు, ఎందుకంటే invitation ఒక email. Email conversationలో customerకు reply ఇవ్వడం కూడా ఆగిపోతుంది. అప్పుడు conversation ఒక దిశలో మాత్రమే సాగుతుంది. చాలామంది ఈ దశను దాటవేస్తారు. తరువాత అత్యంత అవసరమైన సమయంలో సమస్య బయటపడుతుంది.

విధానం సూటిగా ఉంటుంది. SMTP_ADDRESS సెట్ చేయకపోతే Chatwoot ActionMailer ను sendmail deliveryకి మార్చుతుంది. Upstream documentation ప్రకారం ఇది Postfix setup. v2.12.0 నుంచి ఇది defaultగా ఉంది. దాని సూచనల్లో sudo apt install -y postfix తో serverపై Postfixను install చేస్తారు. ఈ Docker setupలో అది ఎప్పుడూ చేయబడదు. అందువల్ల ఆ deliveryకి email అప్పగించడానికి configured mail server ఉండదు. Email background job నుంచి పంపబడుతుంది. కాబట్టి delivery ఉత్పత్తి చేసే error Sidekiq logలో కనిపిస్తుంది, Rails logలో కాదు. ఇదిలా ఉండగా "forgot password"ను click చేసిన వ్యక్తికి విజయవంతమైనట్టు కనిపించే confirmation వస్తుంది, కానీ email అందదు.

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ను ఉపయోగించండి. ఇది connectionను plain textలో ప్రారంభించి, authenticationకు ముందు encrypted connectionగా upgrade చేస్తుంది. Spamను పరిమితం చేయడానికి చాలా VPS providers outbound port 25ను block చేస్తాయి. అందువల్ల అసలు connect అయ్యే relay సాధారణంగా port 587 మాత్రమే. SMTP conversation సమయంలో మీ server ప్రకటించే domain SMTP_DOMAIN. ఇది సరిపోలకపోతే కొన్ని relays అభ్యర్థనను తిరస్కరిస్తాయి.

Settingsను వర్తింపజేసి workerను monitor చేయండి:

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

Login page నుంచి password resetను ప్రారంభించండి. Delivery సరిగ్గా పనిచేస్తే Sidekiq logలో mailer job సాధారణంగా పూర్తవుతుంది. విఫలమైతే ముందుగా exception class కనిపిస్తుంది. తరువాత Sidekiq పెరుగుతున్న backoffతో retry చేస్తుంది. అందువల్ల విఫలమైన relay అదే errorను ప్రతి కొన్ని నిమిషాలకు, అనేక గంటలపాటు ఉత్పత్తి చేస్తుంది.

సాధారణంగా రెండు రకాల rejections కనిపిస్తాయి. వీటిలో ఏదీ Chatwoot bug కాదు. 535 Authentication failed అంటే ఆ relayకు username లేదా password తప్పుగా ఉంది. చాలా providers account passwordకు బదులుగా application passwordను కోరుతాయి. 550 Sender address rejected అంటే MAILER_SENDER_EMAIL అనేది relay నుంచి పంపడానికి అనుమతించని address. కాబట్టి అది మీరు ఆ provider వద్ద verify చేసిన mailbox లేదా domain అయి ఉండాలి.

Emailను conversationలోకి స్వీకరించడం వేరే పని. దీనికి MAILER_INBOUND_EMAIL_DOMAIN మరియు RAILS_INBOUND_EMAIL_SERVICE అవసరం. అదనంగా incoming messagesను Chatwootకు అప్పగించే mail server కూడా కావాలి. Relayను అద్దెకు తీసుకోవడం వేగవంతమైన మార్గం. మొత్తం mail pathను మీరు స్వయంగా నిర్వహించాలనుకుంటే, Mailcowతో మీ స్వంత mail server నడపడం ఆ బాధ్యతలో వాస్తవంగా ఏమి ఉంటుందో వివరిస్తుంది.

ఏమి బ్యాకప్ చేయాలి మరియు రీస్టోర్ పనిచేస్తుందని ఎలా నిర్ధారించుకోవాలి

Chatwoot బ్యాకప్‌లో నాలుగు భాగాలు ఉంటాయి. వీటిలో దేనిని వదిలేసినా, రీస్టోర్ ప్రక్రియ కేవలం రీబిల్డ్ (rebuild) గా మారుతుంది.

• Postgres డేటాబేస్: ఇందులో సంభాషణలు, కాంటాక్టులు, ఏజెంట్ ఖాతాలు మరియు ప్రతి సెట్టింగ్ ఉంటాయి.
• storage_data వాల్యూమ్: ఎందుకంటే ACTIVE_STORAGE_SERVICE=local అప్‌లోడ్ చేసిన ఫైళ్లను డిస్క్‌లో సేవ్ చేస్తుంది, Postgresలో కేవలం ఒక రిఫరెన్స్ రో (row) మాత్రమే ఉంచుతుంది.
• .env ఫైల్: ఎందుకంటే ఇందులో SECRET_KEY_BASE మరియు ACTIVE_RECORD_ENCRYPTION_* కీలు ఉంటాయి.
• Compose ఫైళ్లు: మీ డేటాబేస్ స్కీమాకు సరిపోయే ఖచ్చితమైన ఇమేజ్ ట్యాగ్‌ను ఇవి నమోదు చేస్తాయి.

డేటాబేస్‌ను మాత్రమే రీస్టోర్ చేస్తే, సంభాషణలు తిరిగి వస్తాయి కానీ అటాచ్‌మెంట్లు పనిచేయవు. ఎందుకంటే డేటాబేస్ రోలు డిస్క్‌లో లేని ఫైళ్లను సూచిస్తాయి.

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

-T ముఖ్యం. ఇది లేకపోతే, Compose ఒక సూడో టెర్మినల్‌ను కేటాయిస్తుంది. ఇది స్ట్రీమ్‌లోని న్యూలైన్ బైట్‌లను మారుస్తుంది, దీనివల్ల pg_restore తిరస్కరించే డంప్ ఫైల్ తయారవుతుంది. -Fc అనేది కస్టమ్ ఫార్మాట్, ఇది డేటాను కంప్రెస్ చేస్తుంది మరియు pg_restore ఎంపిక చేసిన రీతిలో పనిచేయడానికి అనుమతిస్తుంది.

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

వాల్యూమ్ పేరు మీ ప్రాజెక్ట్ డైరెక్టరీ పేరు మరియు _storage_data కలిపి ఉంటుంది. ఆ కమాండ్‌ను నమ్మే ముందు docker volume ls | grep storage_data తో నిర్ధారించుకోండి. ఎందుకంటే లేని వాల్యూమ్ పేరును ఇస్తే, Docker ఎర్రర్ చూపకుండా ఖాళీ వాల్యూమ్‌ను సృష్టిస్తుంది. దీనివల్ల ఎర్రర్ లేకుండానే ఖాళీ ఆర్కైవ్ తయారవుతుంది. ఆ తర్వాత ls -lh storage-*.tgz తో ఫైల్ పరిమాణాన్ని తనిఖీ చేయండి.

ఈ రెండు ఫైళ్లు ప్రస్తుతం అవి దేనిని రక్షిస్తున్నాయో అదే డిస్క్‌లో ఉన్నాయి, కాబట్టి ఇవి ఏ రకమైన రక్షణను ఇవ్వవు. వీటిని సర్వర్ నుండి బయటకు పంపి, ఎన్‌క్రిప్ట్ చేయండి. ఎందుకంటే డేటాబేస్ డంప్‌లో కస్టమర్ సందేశాలన్నీ ప్లెయిన్ టెక్స్ట్‌గా ఉంటాయి. restic తో ఎన్‌క్రిప్ట్ చేసిన ఆఫ్-సైట్ బ్యాకప్‌లు షెడ్యూలింగ్ మరియు రిటెన్షన్ గురించి వివరిస్తుంది.

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 కి అప్‌గ్రేడ్ చేయడం ఎలా

కమాండ్ల కంటే వాటిని అమలు చేసే క్రమం చాలా ముఖ్యం.

1. మీరు ప్రస్తుతం వాడుతున్న tag కి మరియు మీరు వెళ్లాలనుకుంటున్న target tag కి మధ్య ఉన్న release notes చదవండి. ఇందులో ఏవైనా మాన్యువల్ పనులు చేయాల్సి ఉందేమో గమనించండి.
2. డేటాబేస్ యొక్క తాజా dump మరియు storage archive తీసుకోండి. ఆ ఫైల్ సైజులు సరిగ్గా ఉన్నాయో లేదో తనిఖీ చేయండి.
3. docker-compose.yaml లోని base సర్వీస్ వద్ద 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 ఫైల్స్ ఉండవు. Migration కి ముందే stack ని ఆపివేయండి, ఎందుకంటే పాత కోడ్ మరియు కొత్త schema మధ్య వైరుధ్యం ఉంటుంది. అప్పుడు రన్ అవుతున్న పాత Rails process ఎర్రర్లను ఇవ్వవచ్చు లేదా కొత్త schema అంగీకరించని డేటాను రాయవచ్చు. Stack ని ఆపడం వల్ల migration కి అవసరమైన మెమరీ అందుబాటులోకి వస్తుంది, అందుకే upstream వారు swap ని ఉపయోగించమని సూచిస్తారు.

docker compose images ప్రతి కంటైనర్ ప్రస్తుతం ఏ tag తో రన్ అవుతుందో చూపిస్తుంది. మీరు tag ని ఎడిట్ చేసి pull చేయడం మర్చిపోతే, ఇది ఆ విషయాన్ని గుర్తిస్తుంది.

ఒకేసారి చాలా వెర్షన్లను దాటకండి. పాత ఇన్‌స్టాలేషన్ల కోసం, మధ్యలో ఉన్న tag ల ద్వారా వెళ్లాలని upstream సూచిస్తుంది. ఎందుకంటే migrations ఒకసారి base schema లో కలిసిపోయిన తర్వాత అవి తొలగించబడతాయి, దీనివల్ల చాలా పాత డేటాబేస్ ముందుకు వెళ్లలేని స్థితికి చేరుకోవచ్చు. ఒకసారికి ఒక minor version చొప్పున అప్‌గ్రేడ్ చేస్తూ, ప్రతి దశ తర్వాత prepare స్టెప్ రన్ చేయండి.

Migration రన్ కాకముందే Rails ప్రారంభమైతే, అది సర్వీస్ అందించడానికి నిరాకరించి ActiveRecord::PendingMigrationError: Migrations are pending అని లాగ్ చేస్తుంది. restart: always సెట్ చేసి ఉంటే, కంటైనర్ రీస్టార్ట్ అవుతూ ఉంటుంది, దీనివల్ల docker compose ps లో uptime ప్రతి కొన్ని సెకన్లకు రీసెట్ అవుతున్నట్లు కనిపిస్తుంది. Prepare స్టెప్ రన్ చేస్తే ఈ సమస్య పరిష్కారమవుతుంది.

Rollback చేయడం అంటే పాత tag ని తిరిగి అమర్చి, డేటాబేస్ dump ని restore చేయడం. మీరు నమ్మదగిన రివర్స్ migration మార్గం ఏదీ లేదు, అందుకే స్టెప్ 2 చాలా కీలకం.

మీరు చూడబోయే వైఫల్య పరిస్థితులు మరియు సందేశాలు

Traefik నుంచి 502 Bad Gateway. Router సరిపోలింది, కానీ backend స్పందించలేదు. docker compose ps లో rails, Up గా కనిపిస్తుందో చూడండి. తరువాత docker network inspect proxy అమలు చేసి, container list లో rails container కనిపిస్తుందో నిర్ధారించండి. ఒక container ఏ networkకూ జత కాలేకపోతే Traefik దానికి చేరుకోలేడు. అందువల్ల అభ్యర్థన routerకు సరిపోతుంది, కానీ తరువాత ఎక్కడికీ వెళ్లదు.

Dashboard లోడ్ అవుతుంది, కానీ కొత్త సందేశాలను చూడటానికి refresh చేయాలి. /cable కు websocket కనెక్షన్ చేరడం లేదు, లేదా FRONTEND_URL browser barలోని addressతో సరిపోలడం లేదు. చిరునామాలు సరిపోలకపోతే, పేజీ వేరే originకు websocket తెరవడానికి ప్రయత్నిస్తుంది. దాన్ని browser నిరోధిస్తుంది.

FATAL: password authentication failed for user "postgres". .env లోని password మరియు Postgres data volumeలో ముందే నిల్వ చేసిన password వేర్వేరుగా ఉన్నాయి. నడుస్తున్న containerలో ALTER USER అమలు చేసి దాన్ని సరిచేయండి. ఇప్పటికే initialised అయిన databaseను .env మళ్లీ సవరించడం వల్ల మార్పు ఉండదు.

NOAUTH Authentication required. Redis, --requirepass తో నడుస్తోంది. కానీ application password లేకుండా కనెక్ట్ అయింది. అందువల్ల REDIS_PASSWORD, .env లో లేదు లేదా దాని విలువ చదవబడలేదు. Redis ఆశిస్తున్న passwordను docker compose exec redis sh -c 'redis-cli -a "$REDIS_PASSWORD" ping' తో నేరుగా పరీక్షించండి. అది PONG సమాధానం ఇవ్వాలి. Single quotes ముఖ్యమైనవి. అవి variableను మీ స్వంత shellలో కాకుండా containerలో expand చేస్తాయి. Container .env ను చదువుతుంది. మీ స్వంత shellలో ఆ variable సాధారణంగా ఖాళీగా ఉంటుంది.

Code 137తో Containers నిష్క్రమించడం. అది SIGKILL. తక్కువ సామర్థ్యం ఉన్న serverలో సాధారణంగా ఈ signalను kernel యొక్క out of memory killer పంపుతుంది. అయితే docker kill కూడా అదే signalను పంపుతుంది. కాబట్టి memory సమస్య అని నిర్ధారించకముందు sudo dmesg -T | grep -i "killed process" ను పరిశీలించండి. Memory సమస్య అయితే swap జోడించండి, ప్రతి serviceకు memory limits సెట్ చేయండి లేదా పెద్ద planకు మారండి.

FAQ

self-hosted Chatwoot VPS కు ఎంత RAM అవసరం?

October 2026 నాటికి, upstream కనీసంగా 4 GB RAM మరియు 4 CPU cores కోరుతోంది. ఈ పరిమాణం రోజుకు గరిష్ఠంగా 10,000 conversations వరకు సరిపోతుంది. 20,000 వరకు conversations కోసం 8 GB RAM మరియు 8 cores అవసరం. కనీసం 1 GB swap కూడా కేటాయించండి. Upgrade సమయంలో migrations అమలు చేయడానికి రెండో Rails process ప్రారంభమవుతుంది. చిన్న VPS లలో memory కొరత ఏర్పడేది సాధారణంగా ఈ దశలోనే. 2 GB VPS boot అయి, కొంతమంది agents కోసం పనిచేయవచ్చు. కానీ load సమయంలో Sidekiq ఒక్కటే 1 GB కంటే ఎక్కువ memory వినియోగించవచ్చు. అందువల్ల రద్దీ సమయాల్లో మరియు upgrades సమయంలో containers exit code 137 తో నిలిపివేయబడవచ్చని భావించండి.

Chatwoot password reset emails ఎందుకు ఎప్పుడూ అందడం లేదు?

ఎందుకంటే SMTP_ADDRESS సెట్ చేయలేదు. అందువల్ల Chatwoot sendmail delivery కు fallback అవుతుంది. upstream ఉద్దేశించిన విధంగా దీనికి host పై Postfix server ఇన్‌స్టాల్ అయి ఉండాలి. ఈ Docker setup లో అది లేదు. Job Sidekiq లో అమలవుతుంది. కాబట్టి delivery error Sidekiq log లో నమోదవుతుంది, అయితే browser విజయ సందేశాన్ని చూపిస్తూనే ఉంటుంది. .env లో SMTP_ADDRESS, SMTP_PORT, SMTP_USERNAME, SMTP_PASSWORD మరియు MAILER_SENDER_EMAIL సెట్ చేయండి. తరువాత rails మరియు sidekiq services ను restart చేసి, మీరు reset ను trigger చేస్తున్నప్పుడు docker compose logs -f sidekiq ను monitor చేయండి.

Chatwoot ను restore చేయడానికి ఏమేమి backup చేయాలి?

Postgres database, storage_data Docker volume, .env file మరియు compose files ను backup చేయాలి. Database ఒక్కటే సరిపోదు. Uploaded files volume లో ఉంటాయి, అయితే Postgres వాటికి సంబంధించిన references ను మాత్రమే ఉంచుతుంది. అందువల్ల database-only restore చేస్తే attachments పనిచేయని conversations మాత్రమే లభిస్తాయి. .env కూడా ముఖ్యమే. వేరే SECRET_KEY_BASE ఉపయోగిస్తే ప్రతి user sign out అవుతారు. వేరే ACTIVE_RECORD_ENCRYPTION_* keys ఉంటే encrypted columns చదవలేరు.

Database పాడవకుండా Chatwoot ను ఎలా upgrade చేయాలి?

ముందుగా backup తీసుకోండి. తరువాత compose file లో image tag మార్చి, docker compose pull, docker compose down, docker compose run --rm rails bundle exec rails db:chatwoot_prepare మరియు docker compose up -d అమలు చేయండి. ముందుగా image ను pull చేయండి, ఎందుకంటే migrations కొత్త image నుంచే అమలు కావాలి. పాత code కొత్త schema పై పనిచేయకుండా ముందుగా stack ను stop చేయండి. పాత install అయితే ఒక్కసారి ఒక minor version చొప్పున upgrade చేయండి. Migrations base schema లో విలీనం అయిన తరువాత అవి తొలగించబడతాయి.

pgvector బదులుగా standard postgres image ఉపయోగించవచ్చా?

లేదు. Chatwoot schema vector extension ను enable చేస్తుంది. అందువల్ల stock postgres image లో db:chatwoot_prepare సమయంలో ERROR: extension "vector" is not available తో failure ఏర్పడుతుంది, ఎందుకంటే ఆ image లో extension control file ఉండదు. upstream compose file లోని pgvector/pgvector:pg16 ను అలాగే ఉంచండి. లేదా మీ Postgres major version కోసం pgvector ను ship చేసే మరో image ను ఉపయోగించండి.