Docker ఉపయోగించి VPSలో Chatwootను హోస్ట్ చేయడం ఎలా?

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

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 నాటికి, అప్‌స్ట్రీమ్ అవసరాల పేజీ కనీస అవసరాలుగా 4 GB RAM మరియు 4 CPU కోర్లను సూచిస్తోంది, ఇది రోజుకు 10,000 సంభాషణల వరకు నిర్వహించగలదని పేర్కొంది. 8 GB RAM మరియు 8 కోర్లతో రోజుకు 20,000 సంభాషణల వరకు నిర్వహించవచ్చని తెలిపింది. కనీసం 1 GB swap ఉండాలని కూడా ఇది కోరుతోంది; అప్‌గ్రేడ్ సమయంలో మెమరీ అయిపోకుండా ఉండటమే దీనికి కారణం. ఫైల్ అప్‌లోడ్‌లను పరిగణనలోకి తీసుకోకముందే, Postgres కోసం 5 GB నుండి 10 GB డిస్క్ స్థలాన్ని కేటాయించుకోండి.

ఇక అసలు విషయానికి వస్తే, 2 GB VPS లో Chatwoot బూట్ అవుతుంది, ఇద్దరు ఏజెంట్లు మరియు తక్కువ సంభాషణలు ఉన్నప్పుడు ఇది బాగానే పనిచేస్తుంది. కానీ ఇది రెండు సందర్భాల్లో విఫలమవుతుంది. మొదటిది Sidekiq, ఇది బిజీగా ఉన్న సర్వర్‌లో 1 GB కంటే ఎక్కువ మెమరీని తీసుకుంటుందని అప్‌స్ట్రీమ్ పేర్కొంది. కాబట్టి, Rails, Postgres మరియు Redis తమ వాటాను తీసుకున్న తర్వాత, అకస్మాత్తుగా వచ్చే ఇమెయిల్‌లు లేదా రిపోర్ట్ జాబ్‌లు సర్వర్‌ను మెమరీ పరిమితి దాటించేలా చేస్తాయి. రెండవది అప్‌గ్రేడ్ ప్రక్రియ, ఎందుకంటే db:chatwoot_prepare మైగ్రేషన్లను అమలు చేయడానికి కొత్త Rails ప్రాసెస్‌ను బూట్ చేస్తుంది. ఈ ఇమేజ్‌లో Rails బూట్ అవ్వడానికి ఎటువంటి పని చేయకముందే వందల మెగాబైట్ల మెమరీ అవసరమవుతుంది.

దీనికి ముందుగా ఎటువంటి హెచ్చరిక రాదు. కెర్నల్ యొక్క out of memory killer అతిపెద్ద ప్రాసెస్‌కు SIGKILL పంపుతుంది, Docker కంటైనర్ ఆగిపోయినట్లు గుర్తిస్తుంది, మరియు restart: always దానిని మళ్ళీ ప్రారంభిస్తుంది. అప్పుడు docker compose ps కంటైనర్ పదేపదే Exited (137) స్థితికి చేరుకుంటుందని చూపిస్తుంది, ఇక్కడ 137 అంటే సిగ్నల్ 9 ద్వారా కిల్ చేయబడిందని అర్థం. కెర్నల్ ఎంచుకున్న ప్రాసెస్ పేరును తెలుసుకోవడానికి sudo dmesg -T | grep -i "killed process" తో దీనిని నిర్ధారించుకోండి.

ఒకవేళ 4 GB మీ బడ్జెట్‌లో లేకపోతే, 2 GB VPS తో పాటు 2 GB swap ఉపయోగించండి. దీనివల్ల సర్వీస్ పూర్తిగా ఆగిపోవడానికి బదులుగా, లోడ్ పెరిగినప్పుడు రెస్పాన్స్ టైమ్ తగ్గుతుందని గుర్తించండి. ఏది ఏమైనా, ప్రతి సర్వీస్‌కు కఠినమైన మెమరీ పరిమితిని విధించడం మంచిది, తద్వారా వర్కర్ ప్రాసెస్ డేటాబేస్‌ను పడగొట్టకుండా ఉంటుంది. దీని కోసం Docker Compose లో మెమరీ పరిమితులు చూడండి.

ఫైల్ అప్‌లోడ్‌లు మీరు నియంత్రించలేని విధంగా పెరిగే అంశం. కస్టమర్ అటాచ్ చేసే ప్రతి స్క్రీన్‌షాట్ స్టోరేజ్ వాల్యూమ్‌లో నిల్వ చేయబడుతుంది. కాబట్టి, డేటాబేస్ వల్ల డిస్క్ నిండిందని భావించే ముందు docker system df -v ను పర్యవేక్షించండి.

Compose ఫైల్‌ను పొందండి మరియు ఒక వెర్షన్ ట్యాగ్‌ను పిన్ చేయండి

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 కమాండ్ ఆ రోజు ఉదయం విడుదలైన వెర్షన్‌ను మీకు అందిస్తుంది. ఇది మీరు చదవని మార్పులతో కూడిన మేజర్ వెర్షన్ కావచ్చు. Chatwoot మైగ్రేషన్లను ఆచరణలో వెనక్కి తీసుకోలేము, కాబట్టి పొరపాటున వెర్షన్ మారితే, దానిని సరిచేయడానికి బ్యాకప్ నుండి పునరుద్ధరించడం తప్ప వేరే మార్గం లేదు. కాబట్టి ఒక ట్యాగ్‌ను పిన్ చేసి, అవసరమైనప్పుడు మాత్రమే దానిని మార్చండి. ఆగస్టు 2026 నాటికి v4.16.2 ప్రస్తుత విడుదలగా ఉంది; మీరు ఈరోజు పిన్ చేయాల్సిన ట్యాగ్ కోసం releases page ను తనిఖీ చేయండి.

base సర్వీస్ అనేది ఒక YAML యాంకర్, దీనిని rails మరియు sidekiq రెండూ ఉపయోగిస్తాయి. కాబట్టి ఒక చోట ట్యాగ్‌ను మార్చితే అది రెండింటికీ వర్తిస్తుంది. మీరు ఫైల్‌లో ఉన్నప్పుడే, పైన ఉన్న version: '3' లైన్‌ను తొలగించండి. ఆధునిక Compose దీనిని పట్టించుకోదు మరియు ప్రతి కమాండ్ రన్ చేసినప్పుడు 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 లేకపోతే పాస్‌వర్డ్ రీసెట్‌లు మరియు ఈమెయిల్ సంభాషణలు ఎందుకు విఫలమవుతాయి

SMTP (Simple Mail Transfer Protocol) సెట్టింగ్‌లు లేని Chatwoot కేవలం ఈమెయిల్‌లను పంపలేని సపోర్ట్ డెస్క్ మాత్రమే కాదు, ఇది నోటిఫికేషన్ల కంటే ఎక్కువ సమస్యలను కలిగిస్తుంది. పాస్‌వర్డ్ రీసెట్‌లు పనిచేయవు, కాబట్టి లాక్ అవుట్ అయిన అడ్మిన్ తిరిగి లాగిన్ అవ్వలేరు. ఏజెంట్ ఆహ్వానాలు (invitations) కూడా పనిచేయవు, ఎందుకంటే ఆహ్వానం అనేది ఒక ఈమెయిల్. ఈమెయిల్ సంభాషణలో కస్టమర్‌కు సమాధానం ఇవ్వడం సాధ్యం కాదు, దీనివల్ల సంభాషణ ఒకే వైపున ఆగిపోతుంది. చాలా మంది ఈ దశను విస్మరిస్తారు, ఆపై అత్యవసర సమయంలో ఇబ్బందులను ఎదుర్కొంటారు.

దీని వెనుక ఉన్న విధానం సరళమైనది. SMTP సెట్టింగ్‌లు లేనప్పుడు, ActionMailer డిఫాల్ట్‌గా localhost లోని పోర్ట్ 25కి మెయిల్‌ను పంపడానికి ప్రయత్నిస్తుంది. Rails కంటైనర్ లోపల ఎటువంటి మెయిల్ సర్వర్ ఉండదు, కాబట్టి డెలివరీ జాబ్ Errno::ECONNREFUSED: Connection refused - connect(2) for "localhost" port 25 ఎర్రర్‌ను చూపిస్తుంది. మెయిల్ బ్యాక్‌గ్రౌండ్ జాబ్ ద్వారా పంపబడుతుంది, కాబట్టి ఆ ఎర్రర్ Sidekiq లాగ్‌లో కనిపిస్తుంది కానీ Rails లాగ్‌లో కనిపించదు. అదే సమయంలో, "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 తో పోర్ట్ 587ని ఉపయోగించండి. ఇది కనెక్షన్‌ను ప్లెయిన్ టెక్స్ట్‌తో ప్రారంభించి, అథెంటికేషన్‌కు ముందు ఎన్‌క్రిప్టెడ్ మోడ్‌లోకి మారుస్తుంది. చాలా VPS ప్రొవైడర్లు స్పామ్‌ను నిరోధించడానికి అవుట్‌బౌండ్ పోర్ట్ 25ని బ్లాక్ చేస్తాయి, కాబట్టి పోర్ట్ 587 ద్వారా రిలేను ఉపయోగించడం మాత్రమే కనెక్ట్ అవ్వడానికి ఏకైక మార్గం. SMTP_DOMAIN అనేది SMTP సంభాషణ సమయంలో మీ సర్వర్ ప్రకటించే డొమైన్, కొన్ని రిలేలు ఈ డొమైన్ సరిపోలకపోతే కనెక్షన్‌ను తిరస్కరిస్తాయి.

సెట్టింగ్‌లను వర్తింపజేసి, వర్కర్‌ను గమనించండి:

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

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

రెండు రకాల తిరస్కరణలు సాధారణం, వీటిలో ఏదీ Chatwoot బగ్ కాదు. 535 Authentication failed అంటే ఆ రిలే కోసం యూజర్‌నేమ్ లేదా పాస్‌వర్డ్ తప్పుగా ఉందని అర్థం. చాలా ప్రొవైడర్లు అకౌంట్ పాస్‌వర్డ్‌కు బదులుగా అప్లికేషన్ పాస్‌వర్డ్‌ను కోరుకుంటాయి. 550 Sender address rejected అంటే MAILER_SENDER_EMAIL అనేది రిలే పంపడానికి అనుమతించని అడ్రస్ అని అర్థం, కాబట్టి అది మీరు వెరిఫై చేసిన మెయిల్‌బాక్స్ లేదా డొమైన్ అయి ఉండాలి.

సంభాషణలోకి ఈమెయిల్‌లను స్వీకరించడం అనేది ఒక ప్రత్యేకమైన పని. దీనికి MAILER_INBOUND_EMAIL_DOMAIN మరియు RAILS_INBOUND_EMAIL_SERVICE, అలాగే ఇన్‌కమింగ్ మెసేజ్‌లను Chatwootకు అందించే మెయిల్ సర్వర్ అవసరం. రిలేను అద్దెకు తీసుకోవడం సులభమైన మార్గం. ఒకవేళ మీరు సొంతంగా మెయిల్ పాత్‌ను నిర్వహించాలనుకుంటే, Mailcowతో సొంత మెయిల్ సర్వర్‌ను నడపడం అనే గైడ్ మీకు అవసరమైన బాధ్యతల గురించి వివరిస్తుంది.

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

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. రూటర్ అభ్యర్థనను గుర్తించింది కానీ బ్యాకెండ్ స్పందించలేదు. docker compose psని తనిఖీ చేస్తే rails అనేది Upగా కనిపిస్తుంది, అప్పుడు docker network inspect proxyని రన్ చేసి, rails కంటైనర్ దాని కంటైనర్ జాబితాలో ఉందో లేదో నిర్ధారించుకోండి. కంటైనర్ రన్ అవ్వకపోతే అది Traefikకి కనిపించదు, కాబట్టి అభ్యర్థన రూటర్‌కు చేరినా ఎక్కడికీ వెళ్లదు.

డాష్‌బోర్డ్ లోడ్ అవుతుంది కానీ కొత్త సందేశాల కోసం రిఫ్రెష్ చేయాల్సి వస్తోంది. /cableకి వెళ్లే websocket కనెక్ట్ అవ్వడం లేదు, లేదా FRONTEND_URL బ్రౌజర్ బార్‌లోని అడ్రస్‌తో సరిపోలడం లేదు. అడ్రస్ సరిపోలకపోతే, పేజీ వేరే మూలం (origin) వైపు websocketని తెరవడానికి ప్రయత్నిస్తుంది, దీనిని బ్రౌజర్ నిరోధిస్తుంది.

FATAL: password authentication failed for user "postgres". .envలోని పాస్‌వర్డ్ మరియు Postgres డేటా వాల్యూమ్‌లో ఉన్న పాస్‌వర్డ్ వేర్వేరుగా ఉన్నాయి. రన్ అవుతున్న కంటైనర్ లోపల ALTER USERతో దీనిని సరిచేయండి, ఎందుకంటే ఇప్పటికే ఇనిషియలైజ్ అయిన డేటాబేస్‌ను .envని మళ్ళీ ఎడిట్ చేయడం ద్వారా మార్చలేము.

NOAUTH Authentication required. Redis అనేది --requirepassతో రన్ అవుతోంది, కానీ అప్లికేషన్ పాస్‌వర్డ్ లేకుండా కనెక్ట్ అయింది. అంటే .envలో REDIS_PASSWORD లేదు లేదా అది సరిగ్గా అప్లై అవ్వలేదు. దీనిని నేరుగా docker compose exec redis redis-cli -a "$REDIS_PASSWORD" pingతో పరీక్షించండి, ఇది PONG అని సమాధానం ఇవ్వాలి.

కంటైనర్లు 137 కోడ్‌తో నిలిచిపోతున్నాయి. ఇది SIGKILL, తక్కువ సామర్థ్యం ఉన్న సర్వర్‌లో ఇది కెర్నల్ యొక్క out of memory killer వల్ల జరుగుతుంది. swapని జోడించండి, ప్రతి సర్వీస్‌కు మెమరీ పరిమితులను సెట్ చేయండి, లేదా పెద్ద ప్లాన్‌కు మారండి.

FAQ

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

ఆగస్టు 2026 నాటికి, రోజుకు 10,000 సంభాషణల వరకు కనీసం 4 GB RAM మరియు 4 CPU కోర్లు ఉండాలని అప్‌స్ట్రీమ్ సిఫార్సు చేస్తోంది. 20,000 సంభాషణల వరకు 8 GB RAM మరియు 8 కోర్లు అవసరం. కనీసం 1 GB swap ను జోడించండి, ఎందుకంటే అప్‌గ్రేడ్ సమయంలో మైగ్రేషన్లను అమలు చేయడానికి రెండవ Rails ప్రాసెస్ నడుస్తుంది, దీనివల్ల తక్కువ మెమరీ ఉన్న సర్వర్లు క్రాష్ అవుతాయి. 2 GB VPS లో కొద్దిమంది ఏజెంట్లతో Chatwoot నడుస్తుంది, కానీ లోడ్ పెరిగినప్పుడు Sidekiq ఒక్కటే 1 GB కంటే ఎక్కువ మెమరీని తీసుకుంటుంది. కాబట్టి, రద్దీ సమయాల్లో మరియు అప్‌గ్రేడ్ల సమయంలో కంటైనర్లు exit code 137 తో ఆగిపోయే అవకాశం ఉంది.

Chatwoot పాస్‌వర్డ్ రీసెట్ ఇమెయిల్‌లు ఎందుకు రావు?

ఎందుకంటే SMTP సెట్టింగ్‌లు కాన్ఫిగర్ చేయబడలేదు. దీనివల్ల ActionMailer ఇమెయిల్‌ను localhost లోని port 25 కి పంపడానికి ప్రయత్నిస్తుంది, కానీ కంటైనర్‌లో మెయిల్ సర్వర్ ఉండదు. బ్రౌజర్‌లో సక్సెస్ మెసేజ్ కనిపించినప్పటికీ, Sidekiq లో ఆ జాబ్ Errno::ECONNREFUSED: Connection refused - connect(2) for "localhost" port 25 తో విఫలమవుతుంది. .env లో SMTP_ADDRESS, SMTP_PORT, SMTP_USERNAME, SMTP_PASSWORD మరియు MAILER_SENDER_EMAIL లను సెట్ చేసి, rails మరియు sidekiq సర్వీసులను రీస్టార్ట్ చేయండి. ఆ తర్వాత రీసెట్ ట్రిగ్గర్ చేసి docker compose logs -f sidekiq ను మానిటర్ చేయండి.

Chatwoot ను రీస్టోర్ చేయడానికి దేనిని బ్యాకప్ తీసుకోవాలి?

Postgres డేటాబేస్, storage_data Docker వాల్యూమ్, .env ఫైల్ మరియు compose ఫైళ్లను బ్యాకప్ తీసుకోవాలి. కేవలం డేటాబేస్ మాత్రమే సరిపోదు, ఎందుకంటే అప్‌లోడ్ చేసిన ఫైళ్లు వాల్యూమ్‌లో ఉంటాయి మరియు డేటాబేస్‌లో వాటికి సంబంధించిన రిఫరెన్స్‌లు మాత్రమే ఉంటాయి. కాబట్టి, కేవలం డేటాబేస్‌ను రీస్టోర్ చేస్తే అటాచ్‌మెంట్లు పనిచేయవు. .env చాలా ముఖ్యం, ఎందుకంటే వేరే SECRET_KEY_BASE ఉంటే వినియోగదారులందరూ లాగ్ అవుట్ అవుతారు, మరియు వేరే ACTIVE_RECORD_ENCRYPTION_* కీలు ఉంటే ఎన్‌క్రిప్ట్ చేసిన కాలమ్స్ చదవడానికి వీలుండదు.

డేటాబేస్‌కు ఇబ్బంది లేకుండా Chatwoot ను ఎలా అప్‌గ్రేడ్ చేయాలి?

ముందుగా బ్యాకప్ తీసుకోండి, మీ compose ఫైల్‌లో image tag ను మార్చండి, ఆపై docker compose pull, docker compose down, docker compose run --rm rails bundle exec rails db:chatwoot_prepare మరియు docker compose up -d కమాండ్లను అమలు చేయండి. ముందుగా కొత్త ఇమేజ్‌ను pull చేయండి, ఎందుకంటే మైగ్రేషన్లు కొత్త ఇమేజ్ నుండే జరగాలి. పాత కోడ్ కొత్త స్కీమాతో పనిచేయదు కాబట్టి, ముందుగా stack ను ఆపండి. పాత ఇన్‌స్టాలేషన్లలో ఒకసారికి ఒక minor వెర్షన్ మాత్రమే అప్‌గ్రేడ్ చేయండి, ఎందుకంటే మైగ్రేషన్లు బేస్ స్కీమాలో కలిసిపోయిన తర్వాత అవి తొలగించబడతాయి.

pgvector కు బదులుగా సాధారణ postgres ఇమేజ్‌ను వాడవచ్చా?

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