VPS वर Docker वापरून Supabase self-host कसे करावे

तुम्ही काय तयार करणार आहात

Supabase चे self-hosting म्हणजे अधिकृत Docker Compose stack तुमच्या स्वतःच्या server वर चालवणे. यात Postgres, त्याच्यासमोरील REST API, auth service, file storage, realtime websockets आणि Studio dashboard यांचा समावेश असतो. तुम्ही एक repository clone करता, एक .env file संपादित करता आणि सुमारे चौदा containers सुरू करता. हे containers मिळून तुम्ही नियंत्रित करत असलेल्या Supabase project प्रमाणे कार्य करतात.

Install प्रक्रिया लहान आहे. अडचणी निर्माण करणारा भाग म्हणजे .env file. त्यामध्ये repository मध्ये प्रकाशित केलेली demo secrets असतात. त्या default values सह सुरू केलेला stack ज्याला त्या आढळतात अशा कोणत्याही व्यक्तीसाठी खुला असतो. या मार्गदर्शकामध्ये बदलणे आवश्यक असलेल्या secrets, प्रत्येक service चा उपयोग, stack ला प्रत्यक्षात किती memory आवश्यक आहे आणि database हटविल्याशिवाय तो कसा update करायचा हे स्पष्ट केले आहे.

Compose तुमच्यासाठी नवीन असल्यास, प्रथम VPS वरील Docker Compose ची मूलभूत माहिती वाचा. खालील सर्व माहितीमध्ये docker compose version आधीच version दाखवत आहे असे गृहीत धरले आहे.

स्टॅकमध्ये प्रत्यक्षात काय समाविष्ट आहे

Supabase हा एकच प्रोग्राम नाही. Compose फाइल एका नेटवर्कवर स्वतंत्र सेवांचा संच सुरू करते. कोणती सेवा काय करते हे समजल्यास कंटेनरच्या नावांची मोठी यादी डीबग करणे सोपे होते.

• db हे Supabase extensions लोड केलेले PostgreSQL आहे. इतर प्रत्येक सेवा याच्याशी संवाद साधते. हा कंटेनर अस्वस्थ असल्यास इतर सर्व सेवाही अयशस्वी होतात.
• kong हे API gateway आहे. ते port 8000 वर ऐकते आणि /rest/v1/, /auth/v1/ आणि /storage/v1/ योग्य backend कडे पाठवते. तुम्ही बाहेरून उपलब्ध करून द्यावा असा हा एकमेव कंटेनर आहे.
• 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 द्वारे stream करते.
• studio आणि meta हे dashboard आणि त्यामागील admin API आहेत.
• analytics (Logflare) आणि vector logs गोळा करतात, तर supavisor हे Postgres connection pooler आहे.

म्हणूनच खाली दिलेली resource numbers अशी आहेत. तुम्ही केवळ database चालवत नाही. तुम्ही database सोबत डझनभर सहाय्यक सेवाही चालवत आहात.

आकारमान: 8 GB RAM चे नियोजन करा

जुलै 2026 पर्यंतच्या स्थितीनुसार, नव्याने स्थापित केलेल्या प्रणालीत तुमचा स्वतःचा डेटा किंवा नेटवर्क ट्रॅफिक नसताना हा स्टॅक साधारण 2.5 ते 3 GB resident memory वापरतो. Analytics service आणि Studio Node.js process हे स्वतंत्रपणे सर्वाधिक memory वापरणारे दोन घटक आहेत. 2 GB चा server containers सुरू करतो; त्यानंतर kernel out of memory killer त्यांपैकी एक container बंद करतो, सामान्यतः analytics किंवा db. याचे लक्षण म्हणजे container exit code 137 सह पुन्हा पुन्हा सुरू होत राहतो.

ज्या कामावर तुम्ही अवलंबून आहात त्यासाठी 8 GB RAM आणि 4 vCPU द्या. तुम्ही एकट्याने वापरणाऱ्या development instance साठी 4 GB पुरेसे आहे; मात्र त्याच वेळी heavy query आणि Studio session चालू असल्यास कार्यप्रदर्शन मंद राहील. Disk देखील महत्त्वाची आहे, कारण Postgres, storage volume आणि log data हे सर्व project directory अंतर्गत साठवले जातात. सुरुवातीला 40 GB द्या आणि त्यावर लक्ष ठेवा.

स्थापित करा: अधिकृत repository क्लोन करा

समर्थित पद्धतीत मुख्य repository मधील docker directory तुमच्या स्वतःच्या project directory मध्ये कॉपी केली जाते. हे विभाजन महत्त्वाचे आहे, कारण नंतरचा 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 अनेक gigabytes images डाउनलोड करते. प्रत्येक service ला Pulled म्हणून चिन्हांकित केल्यानंतरच ते पूर्ण झाले पाहिजे. येथे manifest unknown error आल्यास upstream मधील pinned image tag काढून टाकला आहे. अशा वेळी tags हाताने संपादित करू नका; repository ची नवीन प्रत pull करा.

पहिल्या प्रारंभापूर्वी बदलणे आवश्यक असलेली गुप्त मूल्ये

स्टॅक सुरू करण्यापूर्वी हे करा; सुरू केल्यानंतर करू नका. यापैकी काही मूल्ये पहिल्या बूटवेळी डेटामध्ये लिहिली जातात. त्यामुळे नंतर ती बदलण्यासाठी डेटाबेस रीसेट करावा लागतो.

रिपॉझिटरीमध्ये असा जनरेटर दिलेला आहे, जो प्रत्येक मूल्य योग्य प्रकारे तयार करतो. यात तुमच्या नवीन JWT secret ने स्वाक्षरी कराव्या लागणाऱ्या दोन 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 मध्ये उपलब्ध असते.

ही script दोन मूल्ये सेट करत नाहीत. ती तुम्ही .env मध्ये हाताने संपादित करणे आवश्यक आहे:

• POSTGRES_PASSWORD. येथे फक्त अक्षरे आणि अंक वापरा. येथील विरामचिन्हांमुळे अनेक services strings जोडून तयार करत असलेल्या 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 मनाने का तयार करता येत नाहीत, हे समजून घ्या. दोन्ही JWTs वर JWT_SECRET ने स्वाक्षरी केलेली असते. Gateway प्रत्येक request वर त्या स्वाक्षरीची पडताळणी करतो. त्यामुळे तुमच्या secret शी जुळत नसलेली key {"message":"Invalid authentication credentials"} सह नाकारली जाते. Self-hosting मधील ही सर्वात सामान्य त्रुटी आहे: operator ने JWT_SECRET बदलले, पण demo keys तशाच ठेवल्या. ही तिन्ही मूल्ये नेहमी एकत्र तयार करा.

SERVICE_ROLE_KEY कडे root password प्रमाणे पाहा. यामुळे row level security पूर्णपणे वगळली जाते. ते server side code मध्येच असावे; इतर कुठेही नसावे.

SITE_URL आणि API_EXTERNAL_URL अशी address सेट करा, जिथे तुमचे users प्रत्यक्षात पोहोचतील; उदाहरणार्थ https://supabase.example.com. Auth या मूल्यांवरून email confirmation आणि OAuth callback links तयार करते. त्यामुळे ती http://localhost:8000 वरच ठेवल्यास तुमच्या प्रत्येक user ला त्याच्याच machine वर पाठवले जाईल.

आता तुमच्याकडे असलेली मूल्ये तपासा:

sh run.sh secrets

ते सुरू करा आणि ते निरोगी असल्याची खात्री करा

sh run.sh start
docker compose ps

run.sh start हे docker compose up -d --wait ला आवरते, त्यामुळे आरोग्य तपासण्या यशस्वी होईपर्यंत ते परत येत नाही. प्रत्येक सेवेसाठी running (healthy) किंवा running दिसले पाहिजे. पहिल्यांदा सुरू होण्यास दोन ते चार मिनिटे लागतात, कारण इतर कोणतेही कनेक्शन होण्यापूर्वी Postgres त्याच्या प्रारंभिकीकरण स्क्रिप्ट चालवते.

एखादा container पुन्हा सुरू होत असल्यास, सेवेनावानुसार त्याचे logs वाचा:

docker compose logs db
docker compose logs auth

त्यानंतर Studio port 8000 वर उपलब्ध असेल आणि तुम्ही सेट केलेले dashboard username आणि password विचारेल.

port 8000 सार्वजनिक इंटरनेटवर ठेवू नका

port 8000 वरील Kong साधा HTTP वापरतो. प्रत्येक API key आणि प्रत्येक वापरकर्त्याचा password नेटवर्कवर स्पष्ट मजकूराच्या स्वरूपात पाठवला जातो. Studio credentials मध्ये basic authentication वापरले जाते. हे encryption नसून base64 encoding आहे.

त्याच्या समोर reverse proxy ठेवा आणि तेथे TLS (transport layer security) समाप्त करा. Kong ला loopback address शी bind करा, जेणेकरून इतर कोणतीही सेवा त्याच्यापर्यंत पोहोचू शकणार नाही. docker-compose.yml मध्ये kong port mapping चे रूपांतर 127.0.0.1:8000:8000 मध्ये होते आणि proxy त्याकडे request forward करतो. अनेक Compose apps समोर Traefik मध्ये certificate-संबंधित माहिती दिली आहे.

उर्वरित ports देखील firewall मध्ये बंद करा. Docker स्वतःचे iptables rules लिहून ports publish करते. त्यामुळे साध्या ufw configuration ला हे rules दिसत नाहीत. हा सापळा Docker containers तुमचे ufw rules का दुर्लक्षित करतात येथे स्पष्ट केला आहे.

निर्देशिकेऐवजी डेटाबेसचा बॅकअप घ्या

Postgres चा डेटा ./volumes/db/data येथील bind mount मध्ये साठवला जातो. कंटेनर चालू असताना ही निर्देशिका कॉपी केल्यास अपूर्ण कॉपी मिळते, कारण Postgres लेखन बफर करतो आणि डिस्कवरील फाइल्स केवळ checkpoint वेळी सुसंगत असतात. ती पुनर्स्थापित केल्यास प्रक्रिया सहसा यशस्वी होते; परंतु शेवटचे transactions कधीकधी शांतपणे गमावले जातात. बॅकअपसाठी ही सर्वांत वाईट प्रकारची अपयशस्थिती आहे.

त्याऐवजी dump घ्या. pg_dumpall कंटेनरमध्ये चालते आणि सुसंगत snapshot तयार करते:

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

त्यावर विश्वास ठेवण्यापूर्वी फाइल रिकामी नाही याची तपासणी करा. त्यानंतर ठरावीक वेळापत्रकानुसार हे dump सर्व्हरबाहेर पाठवा. यासाठी restic सह encrypted offsite backups वापरता येतात. त्याच वेळी तुमच्या .env चा बॅकअप घ्या. JWT_SECRET गमावल्यास जारी केलेले प्रत्येक token अवैध ठरते आणि साठवलेले प्रत्येक encrypted secret वाचता येत नाही.

अपलोड केलेल्या फाइल्स ./volumes/storage मध्ये असतात. त्या सामान्य फाइल्स असल्यामुळे साधी कॉपी पुरेशी आहे.

डेटा न गमावता अद्यतन करा

Supabase docker-compose.yml मध्ये image आवृत्त्या निश्चित ठेवते. त्यामुळे तुम्ही स्वतः अद्यतन करेपर्यंत काहीही बदलत नाही. प्रत्येक वेळी प्रथम dump घ्या.

docker compose pull
sh run.sh recreate

recreate stack थांबवते आणि नवीन images वापरून तो पुन्हा सुरू करते. तुमचा डेटा सुरक्षित राहतो, कारण तो containers मध्ये नसून host वरील bind mounts मध्ये साठवला जातो. मोठ्या आवृत्तीवर जाण्यापूर्वी repository मधील CHANGELOG.md वाचा. Postgres ची major upgrade स्वयंचलित नसते. त्यासाठी dump आणि restore आवश्यक असतात.

Compose file मधील बदल लागू करण्यासाठी upstream repository पुन्हा clone करा आणि त्यातील docker directory तुमच्या project वर copy करा. .env वर overwrite होणार नाही याची काळजी घ्या.

Database सह सर्वकाही नष्ट करणारा पूर्ण reset स्वतंत्र script द्वारे केला जातो. हा script पुष्टी मागतो:

sh reset.sh

FAQ

माझ्या API कॉल्समधून "Invalid authentication credentials" का परत मिळतात?

तुमच्या ANON_KEY किंवा SERVICE_ROLE_KEY वर सध्या .env मध्ये असलेल्या JWT_SECRET ने स्वाक्षरी केलेली नव्हती. Gateway प्रत्येक विनंतीवरील स्वाक्षरीची पडताळणी करतो आणि जुळत नसल्यास विनंती नाकारतो. sh utils/generate-keys.sh --update-env वापरून तिन्ही मूल्ये एकत्र पुन्हा तयार करा. त्यानंतर sh run.sh recreate चालवा, जेणेकरून services नवीन मूल्ये वाचतील.

2 GB VPS वर self-hosted Supabase चालवता येईल का?

विश्वसनीयपणे नाही. July 2026 नुसार हा stack निष्क्रिय स्थितीत जवळपास 3 GB memory वापरतो, कारण तो सुमारे fourteen services चालवतो. त्यामुळे 2 GB server वरील containers out of memory killer मुळे बंद होतात आणि docker compose ps मध्ये exit code 137 दिसतो. Production साठी 8 GB वापरा. एकट्याने development करण्यासाठी 4 GB ही किमान क्षमता समजा.

self-hosted Supabase मध्ये edge functions समाविष्ट आहेत का?

होय. Compose file मध्ये Deno आधारित functions runtime समाविष्ट आहे. ./volumes/functions अंतर्गत ठेवलेले सर्व functions ते serve करते. Hosted platform चे global deployment network यात समाविष्ट नाही. त्यामुळे तुमची functions एकाच ठिकाणी, तुमच्या एकाच server वर चालतात.

Postgres database शी थेट कसे जोडावे?

स्वतः server वर interactive shell उघडण्यासाठी docker exec -it supabase-db psql -U postgres वापरा. External client साठी, port 5432 वरील Supavisor द्वारे postgres.<POOLER_TENANT_ID> user आणि तुमचे POSTGRES_PASSWORD वापरून connect करा. हा port internet वर उघडू नका. VPN किंवा SSH tunnel द्वारे त्याच्यापर्यंत पोहोचा.

माझ्या auth confirmation emails मध्ये localhost ची link का आली?

.env मधील SITE_URL आणि API_EXTERNAL_URL ही मूल्ये default वरच राहिली होती. Auth service प्रत्येक confirmation आणि password reset link या दोन मूल्यांवरून तयार करते. त्यामुळे तिला दिलेला address ती पाठवते. दोन्ही मूल्ये तुमच्या वास्तविक public URL वर सेट करा आणि stack पुन्हा तयार करा.