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

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

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

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

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

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

Supabase हा एकच प्रोग्राम नाही. Compose फाइल एका network वर स्वतंत्र services चा संच सुरू करते. कोणती service काय करते हे समजल्यास container names ची मोठी यादी troubleshoot करणे सोपे होते.

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

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

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

जुलै 2026 पर्यंतच्या ताज्या install वर, तुमचा स्वतःचा data किंवा network traffic नसताना, हा 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 exit code 137 सह पुन्हा पुन्हा सुरू होत राहतो.

तुम्ही अवलंबून असलेल्या कोणत्याही deployment साठी 8 GB RAM आणि 4 vCPU द्या. Solo development instance साठी 4 GB पुरेसे आहे, पण heavy query आणि Studio session एकाच वेळी चालू असताना ते धीमे होईल. Disk देखील महत्त्वाची आहे, कारण Postgres, storage volume आणि log data हे सर्व project directory अंतर्गत साठवले जातात. 40 GB पासून सुरुवात करा आणि त्यावर लक्ष ठेवा. Plan निवडण्यापूर्वी services ची संख्या मोजणे ही सवय कोणतीही self-hosted सेवा चालवताना उपयुक्त ठरते, कारण PhotoPrism आणि Immich यांना त्यांच्या quick start pages मधून सूचित होते त्यापेक्षा प्रत्यक्षात बरीच अधिक RAM आवश्यक असते.

Install: अधिकृत repository clone करा

समर्थित पद्धतीत मुख्य repository मधून docker directory तुमच्या स्वतःच्या project directory मध्ये कॉपी केली जाते. हे विभाजन महत्त्वाचे आहे, कारण त्यामुळे नंतरचे 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 manually edit करू नका; त्याऐवजी repository ची नवीन copy pull करा.

पहिल्यांदा सुरू करण्यापूर्वी बदलायची secrets

Stack सुरू करण्यापूर्वी हे करा; सुरू केल्यानंतर करू नका. यापैकी काही values पहिल्या boot वेळी data मध्ये लिहिल्या जातात. त्यामुळे त्या नंतर बदलण्यासाठी database reset करावा लागतो.

Repository मध्ये असा generator दिलेला आहे की जो प्रत्येक value योग्य पद्धतीने तयार करतो. यामध्ये तुमच्या नवीन 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 आणि .env मधील Logflare tokens साठी नवीन values लिहिते. यासाठी openssl आवश्यक आहे. ते कोणत्याही सामान्य Ubuntu image मध्ये उपलब्ध असते.

ही script दोन values सेट करत नाही. त्या तुम्हाला .env मध्ये manually edit कराव्या लागतील:

• POSTGRES_PASSWORD. येथे फक्त letters आणि digits वापरा. येथे punctuation वापरल्यास अनेक 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 ने sign केलेले आहेत. Gateway प्रत्येक request वर त्या signature ची पडताळणी करतो. त्यामुळे तुमच्या secret शी जुळत नसलेली key {"message":"Invalid authentication credentials"} सह reject केली जाते. Self-hosting मधील ही सर्वात सामान्य समस्या आहे: operator ने JWT_SECRET बदलले, पण demo keys तशाच ठेवल्या. तिन्ही values नेहमी एकत्र generate करा.

SERVICE_ROLE_KEY ला root password प्रमाणे सुरक्षित ठेवा. ते row level security पूर्णपणे bypass करते. ते फक्त server side code मध्ये असावे; इतरत्र कुठेही ठेवू नका.

SITE_URL आणि API_EXTERNAL_URL मध्ये users प्रत्यक्षात ज्या address वर पोहोचतील तो address सेट करा, उदाहरणार्थ https://supabase.example.com. Auth त्या values वरून 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 ला wrap करते, त्यामुळे health checks यशस्वी होईपर्यंत ते परत येत नाही. प्रत्येक सेवेसाठी running (healthy) किंवा running दिसले पाहिजे. पहिल्या boot ला दोन ते चार मिनिटे लागतात, कारण इतर कोणतीही सेवा connect होण्यापूर्वी Postgres आपली initialisation scripts चालवते.

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

docker compose logs db
docker compose logs auth

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

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

Kong वरचा port 8000 plain HTTP वापरतो. प्रत्येक API key आणि प्रत्येक वापरकर्त्याचा 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 अॅप्ससमोर Traefik मध्ये स्पष्ट केला आहे.

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

डेटाबेसचा बॅकअप घ्या, directory चा नाही

Postgres data ./volumes/db/data येथील bind mount मध्ये साठवला जातो. Container चालू असताना ती directory कॉपी केल्यास अपूर्ण कॉपी मिळते, कारण Postgres writes buffer करते आणि disk वरील files फक्त checkpoint वेळी सुसंगत असतात. ती कॉपी restore केल्यास बहुतेक वेळा काम होते; परंतु कधीकधी शेवटचे transactions शांतपणे गमावले जातात. बॅकअपसाठी ही सर्वात धोकादायक failure mode आहे.

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

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

त्या file वर विश्वास ठेवण्यापूर्वी ती रिकामी नाही याची खात्री करा. त्यानंतर ठरावीक वेळापत्रकानुसार हे dumps server बाहेर पाठवा. यासाठी restic सह encrypted offsite backups वापरता येतात. त्याच वेळी तुमच्या .env चा बॅकअप घ्या. JWT_SECRET गमावल्यास जारी केलेले प्रत्येक token invalid होते आणि साठवलेले प्रत्येक encrypted secret वाचता येत नाही.

Uploaded files ./volumes/storage मध्ये असतात. त्या सामान्य files असल्यामुळे त्यांची plain copy घेणे पुरेसे आहे.

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

Supabase docker-compose.yml मध्ये image versions pin करते, त्यामुळे तुम्ही स्वतः version बदलत नाही तोपर्यंत काहीही बदलत नाही. स्वतः assemble केलेल्या कोणत्याही stack मध्ये ही पद्धत वापरणे योग्य आहे. म्हणूनच self-hosted RustDesk relay moving tag अनुसरण्याऐवजी त्याच्या दोन्ही server images pin करते. Upgrade ही प्रक्रिया तुम्ही त्यासाठी वेळ उपलब्ध असलेल्या सकाळी जाणीवपूर्वक निवडलेली असावी. प्रत्येक वेळी सर्वप्रथम dump घ्या.

docker compose pull
sh run.sh recreate

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

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

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

sh reset.sh

FAQ

माझ्या API विनंत्यांमध्ये "अवैध प्रमाणीकरण क्रेडेन्शियल्स" का परत येतात?

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

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

विश्वसनीयपणे नाही. July 2026 पर्यंत हा stack idle अवस्थेत सुमारे 3 GB मेमरी वापरतो, कारण तो सुमारे fourteen services चालवतो. त्यामुळे 2 GB मशीनवरील 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 मधील links localhost कडे का जात होते?

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