VPSలో Dockerతో Supabase self-hosting ఎలా చేయాలి

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

Supabase ను self-hosting చేయడం అంటే అధికారిక 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 వల్ల వస్తాయి. ఆ file లో repository లో ప్రచురించబడిన demo secrets ఉంటాయి. ఆ defaults తో ప్రారంభించిన stack ను దాన్ని కనుగొన్న ఎవరైనా access చేయగలరు. ఈ guide లో మీరు మార్చాల్సిన secrets, ప్రతి service ఉపయోగం, stack కు వాస్తవంగా ఎంత memory అవసరం, అలాగే database ను తొలగించకుండా stack ను ఎలా update చేయాలో వివరిస్తుంది.

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

స్టాక్‌లో వాస్తవంగా ఏమి ఉంది

Supabase ఒక్క ప్రోగ్రామ్ కాదు. Compose ఫైల్ ఒకే networkలో వేర్వేరు services సమూహాన్ని ప్రారంభిస్తుంది. ఏ service ఏ పని చేస్తుందో తెలుసుకుంటే, container పేర్ల గందరగోళాన్ని debug చేయడం సులభమవుతుంది.

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

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

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

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

మీరు ఆధారపడే ఏ deployment కైనా 8 GB RAM మరియు 4 vCPU కేటాయించండి. heavy query మరియు Studio session ఒకేసారి నడిచినప్పుడు నెమ్మదిగా పనిచేయడాన్ని అంగీకరిస్తే, ఒంటరి development instance కు 4 GB సరిపోతుంది. Disk కూడా ముఖ్యమే, ఎందుకంటే Postgres, storage volume మరియు log data అన్నీ project directory కింద ఉంటాయి. 40 GB తో ప్రారంభించి, వినియోగాన్ని monitor చేయండి. plan ఎంచుకునే ముందు services సంఖ్యను లెక్కించడం, మీరు self-host చేసే ఏ వ్యవస్థకైనా పాటించదగిన మంచి అలవాటు. ఎందుకంటే PhotoPrism మరియు Immich కు quick start pages సూచించే పరిమాణం కంటే చాలా ఎక్కువ RAM అవసరం ఉంటుంది.

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

మద్దతు ఉన్న విధానంలో ప్రధాన repository నుంచి docker directory ను మీ స్వంత project directory లోకి copy చేయాలి. ఈ వేర్పాటు ముఖ్యం. తరువాత జరిగే git pull మీ .env ను overwrite చేయదు.

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 అనేక gigabytes images ను download చేస్తుంది. ప్రతి service Pulled గా గుర్తించబడినప్పుడు ఇది పూర్తవుతుంది. ఇక్కడ manifest unknown error కనిపిస్తే, upstream నుంచి pinned image tag తొలగించబడిందని అర్థం. Tags ను చేతితో edit చేయకుండా repository యొక్క కొత్త copy ను pull చేయడం పరిష్కారం.

మొదటి start‌కు ముందు మార్చాల్సిన secrets

Stack‌ను start చేయడానికి ముందు ఇది చేయండి. తర్వాత చేయవద్దు. ఈ విలువల్లో కొన్ని మొదటి 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. అక్షరాలు మరియు digits మాత్రమే ఉపయోగించండి. ఇక్కడ 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. Gateway ప్రతి requestపై ఆ 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లో మాత్రమే ఉంచాలి. మరెక్కడా ఉంచకూడదు.

SITE_URL మరియు API_EXTERNAL_URLలను users వాస్తవంగా చేరుకునే addressకు సెట్ చేయండి. ఉదాహరణకు 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 ను చుట్టి ఉంచుతుంది. అందువల్ల health checks విజయవంతం అయ్యే వరకు అది తిరిగి స్పందించదు. ప్రతి service కోసం running (healthy) లేదా running కనిపించాలి. మొదటి boot కు రెండు నుంచి నాలుగు నిమిషాలు పడుతుంది. కారణం, మరే ఇతర service connect కావడానికి ముందు Postgres తన ప్రారంభీకరణ scripts ను అమలు చేస్తుంది.

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

docker compose logs db
docker compose logs auth

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

బయటి internet కు port 8000 ను అందుబాటులో ఉంచవద్దు

Kong లోని port 8000 plain HTTP ను ఉపయోగిస్తుంది. ప్రతి API key మరియు ప్రతి user password network మీద clear text రూపంలో ప్రయాణిస్తాయి. Studio credentials basic authentication ను ఉపయోగిస్తాయి. ఇది encryption కాకుండా base64 encoding మాత్రమే.

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

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

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

Postgres data ./volumes/db/data వద్ద bind mount లో ఉంటుంది. Container నడుస్తున్నప్పుడు ఆ directory ని copy చేస్తే consistent copy లభించదు. కారణం, Postgres writes ను buffer చేస్తుంది. Disk లోని files checkpoint సమయంలో మాత్రమే consistent గా ఉంటాయి. ఆ copy ని restore చేయడం సాధారణంగా పనిచేస్తుంది. అయితే చివరి transactions లో కొన్ని నిశ్శబ్దంగా కోల్పోయే అవకాశం ఉంది. Backup విషయంలో ఇది అత్యంత ప్రమాదకరమైన failure mode.

దానికి బదులుగా dump తీసుకోండి. pg_dumpall container లోనే run అయి 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 image versions ను docker-compose.yml లో నిర్దిష్టంగా ఉంచుతుంది. కాబట్టి మీరు మార్చే వరకు ఏదీ స్వయంచాలకంగా మారదు. మీరు స్వయంగా నిర్మించే ఏ stack లోనైనా ఈ pinning పద్ధతిని అనుసరించడం మంచిది. అందుకే self-hosted RustDesk relay మారుతూ ఉండే tag ను అనుసరించకుండా, తన రెండు server images కు నిర్దిష్ట versions ను ఉపయోగిస్తుంది. Upgrade అనేది దానికి సమయం కేటాయించగల ఉదయం మీరు నిర్ణయించి చేసే పని కావాలి. ప్రతి సారి ముందుగా dump తీసుకోండి.

docker compose pull
sh run.sh recreate

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

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

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

sh reset.sh

FAQ

నా API calls కు "Invalid authentication credentials" ఎందుకు వస్తున్నాయి?

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

నేను 2 GB VPS పై self-hosted Supabase ను నడపవచ్చా?

నమ్మదగిన విధంగా నడపడం సాధ్యం కాదు. July 2026 నాటికి ఈ stack idle స్థితిలోనే దాదాపు 3 GB memory ఉపయోగిస్తుంది. ఇది సుమారు fourteen services ను నడుపుతుంది. అందువల్ల 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 ఒకే location లోని మీ ఒక్క server పై మాత్రమే 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 లోని link లు localhost కు ఎందుకు వెళ్లాయి?

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