Docker తో VPSలో Supabase స్వయంగా హోస్ట్ చేయడం

మీరు నిర్మించేది

Supabase ను స్వయంగా హోస్ట్ చేయడం అంటే అధికారిక Docker Compose stack ను మీ స్వంత server లో నడపడం. ఇందులో Postgres, దాని ముందు పనిచేసే REST API, auth service, file storage, realtime websockets మరియు Studio dashboard ఉంటాయి. మీరు ఒక repository ను clone చేసి, ఒక .env file ను సవరించి, కలిసి మీరు నియంత్రించే Supabase project లా పనిచేసే సుమారు fourteen containers ను ప్రారంభిస్తారు.

Installation ప్రక్రియ చిన్నదే. సమస్యలు సాధారణంగా .env file వల్ల వస్తాయి. అందులో repository లో బహిరంగంగా ప్రచురించిన demo secrets ఉంటాయి. ఆ default లతో ప్రారంభించిన stack ను దాన్ని కనుగొన్న ఎవరైనా ఉపయోగించగలరు. ఈ guide లో తప్పనిసరిగా మార్చాల్సిన secrets, ప్రతి service ఉపయోగం, stack కు వాస్తవంగా అవసరమైన memory పరిమాణం మరియు database ను తొలగించకుండా దాన్ని update చేసే విధానం వివరించబడతాయి.

Compose మీకు కొత్తదైతే, ముందుగా VPS లో Docker Compose ప్రాథమికాలు చదవండి. దిగువ సూచనలన్నీ docker compose version ఇప్పటికే version ను ప్రదర్శిస్తుందని భావిస్తాయి.

స్టాక్‌లో వాస్తవంగా ఉన్నవి

Supabase ఒకే ప్రోగ్రామ్ కాదు. Compose ఫైల్ ఒకే నెట్‌వర్క్‌లో వేర్వేరు సేవల సమూహాన్ని ప్రారంభిస్తుంది. ప్రతి సేవ ఏది అని తెలుసుకుంటే, అనేక container పేర్లను సులభంగా డీబగ్ చేయవచ్చు.

• db అనేది Supabase extensions లోడ్ చేయబడిన PostgreSQL. మిగతా ప్రతి సేవ దీనితో కమ్యూనికేట్ చేస్తుంది. ఈ container ఆరోగ్యంగా లేకపోతే, మిగతావన్నీ కూడా విఫలమవుతాయి.
• kong అనేది API gateway. ఇది port 8000 పై listening చేస్తుంది మరియు /rest/v1/, /auth/v1/, /storage/v1/ అభ్యర్థనలను సరైన backend కు పంపిస్తుంది. మీరు ఎప్పుడూ బయటకు expose చేయవలసిన ఏకైక container ఇదే.
• rest అనేది PostgREST. ఇది మీ Postgres schema ను చదివి REST API గా అందిస్తుంది. అందువల్ల కొత్త table కు ఎలాంటి code లేకుండానే కొత్త endpoint ఏర్పడుతుంది.
• auth అనేది GoTrue. ఇది మీ users ను గుర్తించే JSON web tokens (JWT) ను జారీ చేస్తుంది.
• storage మరియు imgproxy file uploads మరియు image resizing ను నిర్వహిస్తాయి.
• realtime database మార్పులను websockets ద్వారా ప్రసారం చేస్తుంది.
• studio మరియు meta dashboard ను, దాని వెనుక పనిచేసే admin API ను అందిస్తాయి.
• analytics (Logflare) మరియు vector logs ను సేకరిస్తాయి. supavisor అనేది Postgres connection pooler.

దిగువన ఉన్న resource సంఖ్యలు అలా ఉండటానికి ఇదే కారణం. మీరు కేవలం database ను నడపడం లేదు. మీరు database తో పాటు support services గా పనిచేసే డజను సేవలను కూడా నడుపుతున్నారు.

పరిమాణం: 8 GB RAM కోసం ప్రణాళిక రూపొందించండి

2026 జూలై నాటికి, కొత్తగా install చేసినప్పుడు ఈ stack సుమారు 2.5 నుండి 3 GB resident memoryని ఉపయోగిస్తుంది. ఇందులో మీ స్వంత data లేదా network traffic చేర్చబడలేదు. Analytics service మరియు Studio Node.js process ఒక్కొక్కటిగా అత్యధిక memoryని ఉపయోగించే రెండు భాగాలు. 2 GB server containersను ప్రారంభించిన తర్వాత, వాటిలో ఒకదాన్ని kernel out of memory killer ద్వారా నిలిపివేస్తుంది. సాధారణంగా ఇది analytics లేదా db అవుతుంది. Container exit code 137తో నిరంతరం restart అవుతుండటం దీని లక్షణం.

మీరు ఆధారపడే ఏ workloadకైనా 8 GB RAM మరియు 4 vCPU కేటాయించండి. Heavy query మరియు అదే సమయంలో Studio session నడుస్తే నెమ్మదిగా పనిచేయడాన్ని అంగీకరిస్తే, ఒంటరి development instanceకు 4 GB సరిపోతుంది. Disk కూడా ముఖ్యమే. ఎందుకంటే Postgres, storage volume మరియు log data అన్నీ project directory కింద ఉంటాయి. 40 GBతో ప్రారంభించి, దాన్ని monitor చేయండి.

ఇన్‌స్టాల్: అధికారిక రిపాజిటరీని clone చేయండి

మద్దతు ఉన్న విధానంలో ప్రధాన రిపాజిటరీ నుంచి docker డైరెక్టరీని మీ స్వంత ప్రాజెక్ట్ డైరెక్టరీలోకి కాపీ చేస్తారు. ఈ వేర్పాటు ముఖ్యమైనది, ఎందుకంటే తర్వాత జరిగే git pull మీ .env ను ఓవర్‌రైట్ చేయదు.

git clone --depth 1 https://github.com/supabase/supabase
mkdir supabase-project
cp -rf supabase/docker/* supabase-project
cp supabase/docker/.env.example supabase-project/.env
cd supabase-project
docker compose pull

docker compose pull అనేక గిగాబైట్ల imageలను డౌన్‌లోడ్ చేస్తుంది. ప్రతి service Pulled గా గుర్తించబడినప్పుడు ఇది పూర్తవుతుంది. ఇక్కడ manifest unknown లోపం కనిపిస్తే, upstreamలో నిర్దేశించిన image tag తొలగించబడిందని అర్థం. దీనికి పరిష్కారం tagలను చేతితో సవరించడం కాదు; రిపాజిటరీ యొక్క కొత్త కాపీని pull చేయాలి.

మొదటి ప్రారంభానికి ముందు మార్చాల్సిన రహస్య విలువలు

Stack ను ప్రారంభించే ముందు దీన్ని చేయండి. ప్రారంభించిన తర్వాత చేయకండి. వీటిలో కొన్ని విలువలు మొదటి boot సమయంలో data లో వ్రాయబడతాయి. అందువల్ల తర్వాత వాటిని మార్చాలంటే database ను reset చేయాలి.

Repository లో అన్ని విలువలను సరిగ్గా రూపొందించే generator ఉంది. మీ కొత్త JWT secret తో sign చేయాల్సిన రెండు API keys కూడా ఇందులో ఉంటాయి.

sh utils/generate-keys.sh --update-env

ఆ script JWT_SECRET, ANON_KEY, SERVICE_ROLE_KEY, SECRET_KEY_BASE, REALTIME_DB_ENC_KEY, VAULT_ENC_KEY, PG_META_CRYPTO_KEY మరియు Logflare tokens కోసం కొత్త విలువలను .env లో వ్రాస్తుంది. దీనికి openssl అవసరం. ఇది సాధారణ Ubuntu image లో ఉంటుంది.

ఇది సెట్ చేయని రెండు విలువలను మీరు .env లో చేతితో సవరించాలి:

• POSTGRES_PASSWORD. అక్షరాలు మరియు అంకెలను మాత్రమే ఉపయోగించండి. ఇక్కడ punctuation ఉపయోగిస్తే, strings ను కలిపి నిర్మించే అనేక services యొక్క connection strings దెబ్బతింటాయి. ఈ వైఫల్యం parsing error గా కాకుండా authentication error గా కనిపిస్తుంది. దాంతో సమస్యను తప్పు ప్రదేశంలో వెతకడం ప్రారంభిస్తారు.
• DASHBOARD_USERNAME మరియు DASHBOARD_PASSWORD. ఇవి Studio కోసం basic authentication credentials. అందించిన default password అక్షరాలా this_password_is_insecure_and_should_be_updated.

ANON_KEY మరియు SERVICE_ROLE_KEY ను స్వయంగా రూపొందించలేమని అర్థం చేసుకోండి. రెండూ JWT_SECRET తో sign చేసిన JWTs. ప్రతి request పై gateway ఆ signature ను verify చేస్తుంది. అందువల్ల మీ secret కు సరిపోని key ను {"message":"Invalid authentication credentials"} తో reject చేస్తుంది. Self-hosting లో ఇది అత్యంత సాధారణ వైఫల్యం. Operator JWT_SECRET ను మార్చి, demo keys ను అలాగే ఉంచుతారు. ఈ మూడు విలువలను ఎల్లప్పుడూ కలిసి generate చేయండి.

SERVICE_ROLE_KEY ను root password లాగా పరిగణించండి. ఇది row level security ను పూర్తిగా bypass చేస్తుంది. దీన్ని server side code లో మాత్రమే ఉంచాలి.

మీ users వాస్తవంగా చేరుకునే address కు SITE_URL మరియు API_EXTERNAL_URL ను సెట్ చేయండి. ఉదాహరణకు https://supabase.example.com. Auth ఈ విలువల ఆధారంగా email confirmation మరియు OAuth callback links ను నిర్మిస్తుంది. అందువల్ల వాటిని http://localhost:8000 గా ఉంచితే, మీ users అందరినీ వారి స్వంత machine కు పంపుతుంది.

తర్వాత మీ వద్ద ఉన్న విలువలను తనిఖీ చేయండి:

sh run.sh secrets

దీన్ని ప్రారంభించి, ఆరోగ్యంగా ఉందని నిర్ధారించండి

sh run.sh start
docker compose ps

run.sh start, docker compose up -d --wait ను చుట్టి అమలు చేస్తుంది. అందువల్ల ఆరోగ్య తనిఖీలు విజయవంతం అయ్యే వరకు ఇది తిరిగి ఫలితాన్ని ఇవ్వదు. ప్రతి service running (healthy) లేదా running ను చూపాలి. మొదటి ప్రారంభానికి రెండు నుంచి నాలుగు నిమిషాలు పడుతుంది. ఎందుకంటే మరేదైనా కనెక్ట్ కావడానికి ముందు Postgres తన ప్రారంభీకరణ scripts ను అమలు చేస్తుంది.

ఏదైనా container మళ్లీ ప్రారంభమవుతుంటే, service name ఉపయోగించి దాని logs ను చదవండి:

docker compose logs db
docker compose logs auth

తర్వాత Studio port 8000 పై అందుబాటులో ఉంటుంది. మీరు సెట్ చేసిన dashboard username మరియు password ను అది అడుగుతుంది.

port 8000ను పబ్లిక్ ఇంటర్నెట్‌కు అందుబాటులో ఉంచవద్దు

Kong 8000 పోర్ట్‌లో plain HTTPను ఉపయోగిస్తుంది. ప్రతి API key మరియు ప్రతి user password నెట్‌వర్క్‌లో స్పష్ట పాఠ్యంగా ప్రసారం అవుతాయి. Studio credentials encryptionకు బదులుగా base64 encodingను ఉపయోగించే basic authenticationను ఉపయోగిస్తాయి.

దాని ముందు reverse proxyని ఉంచి, అక్కడే TLS (transport layer security)ను ముగించండి. Kongను loopback addressకు bind చేయండి, తద్వారా మరే ఇతర సేవ దాన్ని చేరుకోలదు. docker-compose.ymlలో kong port mapping 127.0.0.1:8000:8000గా మారుతుంది. Proxy దానికి requestsను forward చేస్తుంది. Certificate సంబంధిత వివరాల కోసం అనేక Compose apps ముందు Traefik చూడండి.

మిగిలిన పోర్ట్‌లను కూడా firewallలో మూసివేయండి. Docker తన స్వంత iptables rulesను రాయడం ద్వారా portsను publish చేస్తుంది. Naive ufw configuration ఈ rulesను చూడదు. ఈ సమస్యను Docker containers మీ ufw rulesను ఎందుకు పట్టించుకోవులో వివరించారు.

డైరెక్టరీని కాదు, databaseను backup చేయండి

Postgres data, ./volumes/db/dataలోని bind mountలో ఉంటుంది. container నడుస్తున్నప్పుడు ఆ డైరెక్టరీని copy చేస్తే, మీకు అసంపూర్ణ copy లభిస్తుంది. కారణం, Postgres writeలను buffer చేస్తుంది మరియు diskలోని files checkpoint సమయంలో మాత్రమే consistentగా ఉంటాయి. దాన్ని restore చేయడం సాధారణంగా పనిచేస్తుంది. అయితే కొన్నిసార్లు చివరి transactions నిశ్శబ్దంగా కోల్పోతాయి. backupకు ఇది అత్యంత ప్రమాదకరమైన failure mode.

దానికి బదులుగా dump తీసుకోండి. pg_dumpall containerలోనే నడిచి consistent snapshotను సృష్టిస్తుంది:

docker exec -t supabase-db pg_dumpall -U postgres > supabase-$(date +%F).sql

దాన్ని నమ్మే ముందు file ఖాళీగా లేదని నిర్ధారించండి. తర్వాత ఆ dumpsను schedule ప్రకారం server వెలుపలికి పంపండి. ఇందుకోసమే resticతో encrypted offsite backups ఉపయోగిస్తారు. అదే సమయంలో మీ .envను కూడా backup చేయండి. JWT_SECRET కోల్పోతే జారీ చేసిన ప్రతి token invalid అవుతుంది మరియు నిల్వ చేసిన encrypted secretలు చదవలేరు.

Uploaded files ./volumes/storageలో ఉంటాయి. అవి సాధారణ files కాబట్టి, plain copy సరిపోతుంది.

డేటాను కోల్పోకుండా నవీకరించడం

Supabase ఇమేజ్ వెర్షన్‌లను docker-compose.yml లో స్థిరపరుస్తుంది. కాబట్టి మీరు మార్చే వరకు ఏదీ మారదు. ప్రతి సారి ముందుగా dump తీసుకోండి.

docker compose pull
sh run.sh recreate

recreate stack ను ఆపి, కొత్త ఇమేజ్‌లతో మళ్లీ ప్రారంభిస్తుంది. మీ డేటా భద్రంగా ఉంటుంది, ఎందుకంటే అది containers లో కాకుండా host లోని bind mounts లో ఉంటుంది. major version jump చేయడానికి ముందు repository లోని CHANGELOG.md ను చదవండి. Postgres major upgrades స్వయంచాలకంగా జరగవు. వాటికి dump మరియు restore అవసరం.

Compose file లోని మార్పులను కూడా పొందడానికి upstream repository ను మళ్లీ clone చేసి, దాని docker directory ని మీ project పైకి copy చేయండి. .env ను overwrite చేయకుండా జాగ్రత్తపడండి.

Database సహా ప్రతిదాన్ని తొలగించే పూర్తి reset ప్రత్యేక script ద్వారా జరుగుతుంది. అది confirmation అడుగుతుంది:

sh reset.sh

FAQ

నా API కాల్‌లు "Invalid authentication credentials"ను ఎందుకు చూపిస్తున్నాయి?

మీ ANON_KEY లేదా SERVICE_ROLE_KEY, ప్రస్తుతం .envలో ఉన్న JWT_SECRETతో sign చేయబడలేదు. gateway ప్రతి requestలో signatureను ధృవీకరిస్తుంది. సరిపోలకపోతే requestను తిరస్కరిస్తుంది. sh utils/generate-keys.sh --update-envతో ఈ మూడింటినీ కలిసి మళ్లీ generate చేయండి. ఆ తర్వాత sh run.sh recreateను run చేయండి, తద్వారా services కొత్త విలువలను చదువుతాయి.

2 GB VPSలో self-hosted Supabaseను run చేయవచ్చా?

నమ్మకంగా run చేయలేరు. July 2026 నాటికి ఈ stack idle స్థితిలోనే దాదాపు 3 GB memory ఉపయోగిస్తుంది. ఇది సుమారు fourteen servicesను run చేస్తుంది. అందువల్ల 2 GB serverలో out of memory killer containersను ఆపేస్తుంది. docker compose psలో exit code 137 కనిపిస్తుంది. Production కోసం 8 GB ఉపయోగించండి. Solo development కోసం 4 GBను కనిష్ఠ పరిమితిగా పరిగణించండి.

self-hosted Supabaseలో edge functions ఉంటాయా?

ఉంటాయి. Compose fileలో Deno ఆధారిత functions runtime ఉంటుంది. ./volumes/functions కింద ఉంచిన ఏదైనా codeను అది serve చేస్తుంది. Hosted platformలోని global deployment network ఇందులో ఉండదు. కాబట్టి మీ functions ఒకే serverలో, ఒకే locationలో run అవుతాయి.

Postgres databaseకు నేరుగా ఎలా connect అవ్వాలి?

Serverపైనే interactive shell కోసం docker exec -it supabase-db psql -U postgresను ఉపయోగించండి. External client కోసం port 5432లో Supavisor ద్వారా connect అవ్వండి. postgres.<POOLER_TENANT_ID> userను మరియు మీ POSTGRES_PASSWORDను ఉపయోగించండి. ఆ portను internetకు open చేయవద్దు. VPN లేదా SSH tunnel ద్వారా చేరుకోండి.

నా auth confirmation emails localhostకు link కావడానికి కారణం ఏమిటి?

.envలోని SITE_URL మరియు API_EXTERNAL_URL default విలువలుగానే ఉన్నాయి. Auth service ప్రతి confirmation మరియు password reset linkను ఈ రెండు విలువల ఆధారంగా రూపొందిస్తుంది. అందువల్ల దానికి అందించిన addressనే అది పంపుతుంది. రెండింటినీ మీ నిజమైన public URLకు set చేయండి. ఆ తర్వాత stackను మళ్లీ create చేయండి.