VPS-ல் Docker மூலம் Supabase-ஐ நிறுவுவது எப்படி?

நீங்கள் உருவாக்குவது என்ன

Supabase-ஐ self-host செய்வது என்பது, அதன் அதிகாரப்பூர்வ Docker Compose stack-ஐ உங்கள் சொந்த server-ல் இயக்குவதாகும்: இதில் Postgres, அதற்கு முன்னால் ஒரு REST API, ஒரு auth service, file storage, realtime websockets மற்றும் Studio dashboard ஆகியவை அடங்கும். நீங்கள் ஒரு repository-ஐ clone செய்து, ஒரு .env கோப்பைத் திருத்தி, சுமார் பதினான்கு containers-ஐத் தொடங்க வேண்டும்; இவை அனைத்தும் சேர்ந்து நீங்கள் கட்டுப்படுத்தும் ஒரு Supabase project போலச் செயல்படும்.

இதன் நிறுவல் எளிதானது. இதில் தவறு நடக்க வாய்ப்புள்ள பகுதி .env கோப்புதான். இது repository-ல் பகிரங்கமாக உள்ள demo secrets-உடன் வருகிறது; அந்த default மதிப்புகளுடன் stack-ஐத் தொடங்கினால், அதைத் தேடிக் கண்டறியும் எவருக்கும் உங்கள் server திறந்திருக்கும். நீங்கள் மாற்ற வேண்டிய secrets, ஒவ்வொரு service-ன் நோக்கம், stack-க்குத் தேவையான உண்மையான memory அளவு மற்றும் உங்கள் database-ஐ அழிக்காமல் அதை எப்படி update செய்வது என்பது குறித்து இந்த வழிகாட்டி விளக்குகிறது.

Compose உங்களுக்குப் புதியது என்றால், முதலில் Docker Compose basics on a VPS என்பதைப் படிக்கவும். கீழே உள்ள அனைத்தும் docker compose version ஏற்கனவே ஒரு version-ஐக் காட்டுகிறது என்ற அடிப்படையில் எழுதப்பட்டுள்ளன.

இந்த stack-ல் உண்மையில் என்ன உள்ளது

Supabase என்பது ஒரே ஒரு நிரல் அல்ல. Compose கோப்பு ஒரு network-ல் தனித்தனி சேவைகளைத் தொடங்குகிறது. எது எந்தச் சேவை என்று தெரிந்துகொள்வது, குழப்பமான container பெயர்களைப் புரிந்துகொண்டு பிழைத்திருத்தம் (debug) செய்ய உதவும்.

• db என்பது Supabase extensions ஏற்றப்பட்ட PostgreSQL ஆகும். மற்ற அனைத்துச் சேவைகளும் இதனுடன் தான் தொடர்பு கொள்கின்றன. இந்த container சரியாகச் செயல்படவில்லை என்றால், மற்ற அனைத்தும் தோல்வியடையும்.
• kong என்பது API gateway ஆகும். இது port 8000-ல் இயங்கி, /rest/v1/, /auth/v1/ மற்றும் /storage/v1/ ஆகியவற்றைச் சரியான backend-க்கு அனுப்புகிறது. நீங்கள் வெளியில் திறக்க வேண்டிய ஒரே container இது மட்டுமே.
• rest என்பது PostgREST ஆகும். இது உங்கள் Postgres schema-வைப் படித்து, அதை REST API-ஆக மாற்றுகிறது. எனவே, புதிய code எழுதாமலேயே ஒரு புதிய table-ஐ புதிய endpoint-ஆகப் பயன்படுத்தலாம்.
• auth என்பது GoTrue ஆகும். இது உங்கள் பயனர்களை அடையாளம் காணும் 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 மற்றும் அதனுடன் தொடர்புடைய ஒரு டஜன் துணைச் சேவைகளை இயக்குகிறீர்கள்.

அளவு நிர்ணயம்: 8 GB RAM-க்கு திட்டமிடுங்கள்

ஜூலை 2026 நிலவரப்படி, உங்கள் தரவு அல்லது traffic வருவதற்கு முன்பே, புதிய நிறுவலின் போது இந்த stack தோராயமாக 2.5 முதல் 3 GB resident memory-ஐப் பயன்படுத்துகிறது. இதில் analytics service மற்றும் Studio Node.js process ஆகிய இரண்டும் அதிகப்படியான நினைவகத்தை எடுத்துக்கொள்கின்றன. 2 GB RAM கொண்ட server-ல் containers தொடங்கும், ஆனால் kernel-ன் out of memory killer மூலம் ஏதேனும் ஒன்று நிறுத்தப்படும். இது பொதுவாக analytics அல்லது db ஆக இருக்கும். இதன் அறிகுறி, container தொடர்ந்து restart ஆகிக்கொண்டே இருப்பது மற்றும் exit code 137-ஐக் காட்டுவது ஆகும்.

நீங்கள் நம்பிப் பயன்படுத்தும் எதற்கும் 8 GB RAM மற்றும் 4 vCPU வழங்குங்கள். ஒரு தனிப்பட்ட மேம்பாட்டு (development) சூழலுக்கு 4 GB போதுமானது; ஆனால் ஒரே நேரத்தில் ஒரு கனமான query மற்றும் Studio session-ஐ இயக்கும்போது வேகம் குறைவாக இருக்கும் என்பதை நினைவில் கொள்ளுங்கள். வட்டு (disk) இடமும் முக்கியமானது, ஏனெனில் Postgres, storage volume மற்றும் log தரவுகள் அனைத்தும் project directory-க்கு உள்ளேயே சேமிக்கப்படுகின்றன. 40 GB-ல் தொடங்கி, அதன் பயன்பாட்டைக் கண்காணித்து வாருங்கள். நீங்கள் self-host செய்யும் எதற்கும், திட்டத்தைத் தேர்ந்தெடுப்பதற்கு முன் சேவைகளின் தேவையை கணக்கிடுவது நல்ல பழக்கம். ஏனெனில் PhotoPrism and Immich போன்ற சேவைகளின் குறைந்தபட்ச RAM தேவை, அவற்றின் quick start பக்கங்களில் குறிப்பிடப்பட்டுள்ளதை விட மிக அதிகம்.

நிறுவுதல்: அதிகாரப்பூர்வ களஞ்சியத்தை (repository) clone செய்தல்

ஆதரிக்கப்படும் வழிமுறையானது, முதன்மை களஞ்சியத்திலிருந்து docker கோப்பகத்தை (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 பல ஜிகாபைட் அளவிலான படங்களை (images) பதிவிறக்கம் செய்கிறது. இது அனைத்து சேவைகளும் Pulled என குறிக்கப்பட்ட நிலையில் முடிவடைய வேண்டும். இங்கே ஏற்படும் ஒரு manifest unknown பிழை, இணைக்கப்பட்ட (pinned) image tag-ஐ upstream-ல் நீக்கிவிட்டதைக் குறிக்கிறது. இதற்குத் தீர்வாக, tag-களை கைமுறையாகத் திருத்துவதற்குப் பதிலாக, களஞ்சியத்தின் புதிய நகலைப் பதிவிறக்கம் (pull) செய்ய வேண்டும்.

முதல் முறை தொடங்குவதற்கு முன் நீங்கள் மாற்ற வேண்டிய ரகசியங்கள்

stack-ஐத் தொடங்குவதற்கு முன்பே இதைச் செய்யுங்கள், தொடங்கிய பிறகு செய்ய வேண்டாம். இதில் உள்ள பல மதிப்புகள் முதல் முறை boot ஆகும்போது தரவுகளில் எழுதப்படுகின்றன, எனவே அவற்றை மாற்றினால் database-ஐ மீண்டும் அமைக்க வேண்டியிருக்கும்.

இந்த repository-ல் ஒரு generator உள்ளது; இது உங்கள் புதிய 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-லும் இருக்கும்.

அது அமைக்காத இரண்டு மதிப்புகளை, நீங்கள் .env-ல் கைமுறையாகத் திருத்த வேண்டும்:

• POSTGRES_PASSWORD. எழுத்துக்கள் மற்றும் எண்களை மட்டுமே பயன்படுத்தவும். இதில் நிறுத்தற்குறிகளைப் பயன்படுத்தினால், பல services இணைக்கும் connection strings சிதைந்துவிடும். இது parsing error-க்கு பதிலாக authentication error போலத் தோன்றும், இதனால் பயனர்கள் தவறான இடத்தில் காரணத்தைத் தேடுவார்கள்.
• DASHBOARD_USERNAME மற்றும் DASHBOARD_PASSWORD. இவை Studio-க்கான அடிப்படை authentication credentials ஆகும். இதில் உள்ள default password என்பது this_password_is_insecure_and_should_be_updated ஆகும்.

ANON_KEY மற்றும் SERVICE_ROLE_KEY ஆகியவற்றை ஏன் நீங்களாக உருவாக்க முடியாது என்பதைப் புரிந்துகொள்ளுங்கள். இவை இரண்டும் JWT_SECRET-ஆல் கையொப்பமிடப்பட்ட JWT-கள் ஆகும். ஒவ்வொரு கோரிக்கையின் போதும் gateway அந்த கையொப்பத்தைச் சரிபார்க்கும், எனவே உங்கள் secret-உடன் பொருந்தாத key {"message":"Invalid authentication credentials"} பிழையுடன் நிராகரிக்கப்படும். இதுவே self-hosting-ல் நடக்கும் பொதுவான தோல்வியாகும்: பயனர் JWT_SECRET-ஐ மாற்றியிருப்பார், ஆனால் demo keys-ஐ அப்படியே வைத்திருப்பார். மூன்றையும் எப்போதும் ஒன்றாகவே உருவாக்குங்கள்.

SERVICE_ROLE_KEY-ஐ root password போலக் கருதுங்கள். இது row level security-ஐ முழுமையாகத் தவிர்க்கிறது. இது server side code-ல் மட்டுமே இருக்க வேண்டும், வேறு எங்கும் இருக்கக்கூடாது.

SITE_URL மற்றும் API_EXTERNAL_URL ஆகியவற்றை உங்கள் பயனர்கள் உண்மையில் அணுகும் முகவரிக்கு அமைக்கவும், உதாரணமாக https://supabase.example.com. Auth அதன் email confirmation மற்றும் OAuth callback இணைப்புகளை அந்த மதிப்புகளிலிருந்துதான் உருவாக்குகிறது, எனவே அவற்றை http://localhost:8000-லேயே விட்டுவிட்டால், உங்கள் பயனர்கள் அனைவரும் அவர்களின் சொந்த machine-க்கே திருப்பி விடப்படுவார்கள்.

பிறகு உங்களிடம் உள்ளதைச் சரிபார்க்கவும்:

sh run.sh secrets

சேவையைத் தொடங்கி, அது சரியாக இயங்குகிறதா என உறுதிப்படுத்தவும்

sh run.sh start
docker compose ps

run.sh start ஆனது docker compose up -d --wait-ஐ உள்ளடக்கியுள்ளது, எனவே health checks முடிவடையும் வரை இது காத்திருக்கும். ஒவ்வொரு சேவையும் running (healthy) அல்லது running நிலையில் இருக்க வேண்டும். Postgres தனது ஆரம்பக்கட்ட scripts-ஐ முடித்த பின்னரே பிற சேவைகள் அதனுடன் இணைய முடியும் என்பதால், முதல் முறை boot ஆக இரண்டு முதல் நான்கு நிமிடங்கள் வரை ஆகலாம்.

ஒரு container மீண்டும் மீண்டும் restart ஆகிக்கொண்டிருந்தால், அதன் service பெயரைப் பயன்படுத்தி logs-ஐப் பார்க்கவும்:

docker compose logs db
docker compose logs auth

இப்போது Studio ஆனது 8000 port-ல் இயங்கும். நீங்கள் அமைத்த dashboard பயனர் பெயர் மற்றும் கடவுச்சொல்லை உள்ளிடுமாறு அது கேட்கும்.

port 8000-ஐ பொது இணையத்தில் திறக்க வேண்டாம்

Kong, 8000 port-ல் plain HTTP மூலம் இயங்குகிறது. ஒவ்வொரு API key மற்றும் பயனர் கடவுச்சொல்லும் நெட்வொர்க்கில் plain text-ஆகவே செல்லும். Studio credentials-க்கு பயன்படுத்தப்படும் basic authentication என்பது encryption அல்ல, அது வெறும் base64 encoding மட்டுமே.

இதற்கு முன்னால் ஒரு reverse proxy-ஐ அமைக்கவும். அங்கு TLS (transport layer security)-ஐ terminate செய்யவும். Kong-ஐ loopback address-ல் மட்டும் bind செய்யவும், அப்போதுதான் பிற இடங்களிலிருந்து அதை அணுக முடியாது. docker-compose.yml-ல், kong port mapping என்பது 127.0.0.1:8000:8000 என மாறும், proxy அந்த port-க்கு traffic-ஐ அனுப்பும். பல Compose apps-க்கு முன்னால் Traefik-ஐ அமைத்தல் பகுதியில் certificate தொடர்பான விவரங்கள் உள்ளன.

மீதமுள்ள ports-ஐ firewall மூலம் மூடிவிடவும். ஏனெனில், Docker தனது சொந்த iptables விதிகளை எழுதுவதால், சாதாரண ufw configuration-ஆல் அதை கவனிக்க முடியாது. இந்த சிக்கல் Docker containers ஏன் உங்கள் ufw விதிகளைப் புறக்கணிக்கின்றன என்ற பகுதியில் விளக்கப்பட்டுள்ளது.

கோப்பகத்தை (directory) அல்ல, தரவுத்தளத்தை (database) காப்புப்பிரதி எடுக்கவும்

Postgres தரவுகள் ./volumes/db/data என்ற bind mount-ல் சேமிக்கப்படுகின்றன. container இயங்கிக்கொண்டிருக்கும்போது அந்த கோப்பகத்தை நகலெடுத்தால், அது முழுமையற்ற (torn) நகலாகவே இருக்கும். ஏனெனில், Postgres தரவுகளை buffer-ல் வைத்திருக்கும்; checkpoint-ல் மட்டுமே வட்டில் உள்ள கோப்புகள் சீரான நிலையில் (consistent) இருக்கும். இதை மீட்டெடுக்கும்போது பெரும்பாலும் வேலை செய்யும், ஆனால் சில நேரங்களில் கடைசி பரிவர்த்தனைகள் (transactions) இழக்கப்படலாம். இது காப்புப்பிரதி தோல்வியின் மிக மோசமான நிலையாகும்.

அதற்குப் பதிலாக dump எடுக்கவும். pg_dumpall கட்டளையை container-க்குள் இயக்கினால், அது சீரான snapshot-ஐ உருவாக்கும்:

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

கோப்பு காலியாக இல்லை என்பதை உறுதிப்படுத்திய பின்பே அதை நம்பவும். பின்னர், அந்த dump கோப்புகளை ஒரு கால அட்டவணையின்படி server-லிருந்து வெளியேற்றவும். இதற்கு restic மூலம் குறியாக்கம் செய்யப்பட்ட offsite காப்புப்பிரதிகள் பயன்படுத்தப்படுகிறது. அதே நேரத்தில் உங்கள் .env-ஐயும் காப்புப்பிரதி எடுக்கவும். JWT_SECRET-ஐ இழந்தால், வழங்கப்பட்ட அனைத்து token-களும் செல்லாததாகிவிடும் மற்றும் சேமிக்கப்பட்ட அனைத்து குறியாக்கம் செய்யப்பட்ட ரகசியங்களும் படிக்க முடியாததாகிவிடும்.

பதிவேற்றப்பட்ட கோப்புகள் ./volumes/storage-ல் உள்ளன. அவை சாதாரண கோப்புகள் என்பதால், அவற்றை நேரடியாக நகலெடுப்பது போதுமானது.

தரவு இழப்பின்றி மேம்படுத்துதல்

Supabase image versions-ஐ docker-compose.yml-ல் pin செய்கிறது; எனவே நீங்கள் மாற்றும் வரை எந்த version-உம் மாறாது. நீங்கள் கைமுறையாக அமைக்கும் எந்த stack-லுமே இந்த pinning முறையைப் பயன்படுத்துவது நல்லது. அதனால்தான் self-hosted RustDesk relay moving tag-ஐ பின்பற்றாமல், தனது இரண்டு server images-ஐ pin செய்கிறது. Upgrade-ஐ அதற்கென நேரம் ஒதுக்கக்கூடிய ஒரு நாளில் நீங்கள் தேர்ந்தெடுத்து செய்ய வேண்டும். ஒவ்வொரு முறையும் முதலில் dump எடுக்கவும்.

docker compose pull
sh run.sh recreate

recreate, stack-ஐ நிறுத்திவிட்டு புதிய image-களில் அதை மீண்டும் தொடங்கும். உங்கள் தரவு container-களுக்குள் இல்லாமல், host-ல் உள்ள bind mounts-ல் இருப்பதால் அவை அழியாது. ஒரு பெரிய பதிப்பு மாற்றத்திற்கு (major version jump) முன், repository-ல் உள்ள CHANGELOG.md-ஐப் படியுங்கள். ஏனெனில், Postgres major upgrades தானாக நடைபெறாது; அதற்கு dump மற்றும் restore தேவைப்படும்.

Compose கோப்பில் உள்ள மாற்றங்களைப் பெற, upstream repository-ஐ மீண்டும் clone செய்து, அதன் docker கோப்பகத்தை உங்கள் திட்டத்தில் நகலெடுங்கள். அவ்வாறு செய்யும்போது .env மேலெழுதப்படாமல் பார்த்துக்கொள்ளுங்கள்.

தரவுத்தளம் உட்பட அனைத்தையும் அழிக்கும் முழுமையான reset, ஒரு தனி 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-ஐ இயக்கவும். அப்போதுதான் சேவைகள் புதிய மதிப்புகளைப் பெற்றுக்கொள்ளும்.

2 GB VPS-ல் self-hosted Supabase-ஐ இயக்க முடியுமா?

நம்பகத்தன்மையுடன் இயக்க முடியாது. ஜூலை 2026 நிலவரப்படி, இந்த stack சுமார் பதினான்கு சேவைகளை இயக்குவதால், சும்மா இருக்கும்போதே 3 GB நினைவகத்தைப் பயன்படுத்துகிறது. எனவே, 2 GB கொண்ட server-ல் out of memory killer மூலம் containers நிறுத்தப்படும், மேலும் docker compose ps-ல் exit code 137-ஐக் காண்பீர்கள். production பயன்பாட்டிற்கு 8 GB-ஐப் பயன்படுத்தவும், தனிப்பட்ட மேம்பாட்டிற்கு (development) 4 GB-ஐக் குறைந்தபட்ச அளவாகக் கொள்ளவும்.

self-hosted Supabase-ல் edge functions உள்ளதா?

ஆம். Compose கோப்பில் Deno அடிப்படையிலான functions runtime உள்ளது. நீங்கள் ./volumes/functions-ன் கீழ் வைக்கும் எதையும் அது இயக்கும். இதில் hosted platform-ன் உலகளாவிய deployment network கிடையாது, எனவே உங்கள் functions உங்கள் ஒரே server-ல், ஒரே இடத்தில் மட்டுமே இயங்கும்.

Postgres database-உடன் நேரடியாக இணைவது எப்படி?

Server-க்குள்ளேயே interactive shell-ஐப் பெற docker exec -it supabase-db psql -U postgres-ஐப் பயன்படுத்தவும். வெளிப்புற client-லிருந்து இணைக்க, port 5432-ல் Supavisor வழியாக postgres.<POOLER_TENANT_ID> பயனர் மற்றும் உங்கள் POSTGRES_PASSWORD-ஐப் பயன்படுத்தி இணையவும். அந்த port-ஐ இணையத்திற்குத் திறக்க வேண்டாம். VPN அல்லது SSH tunnel வழியாக அதை அணுகவும்.

எனது auth confirmation மின்னஞ்சல்கள் ஏன் localhost-க்கு link ஆகின்றன?

.env-ல் உள்ள SITE_URL மற்றும் API_EXTERNAL_URL ஆகியவை இயல்புநிலை (default) மதிப்புகளிலேயே உள்ளன. Auth service அனைத்து உறுதிப்படுத்தல் மற்றும் கடவுச்சொல் மாற்றும் இணைப்புகளையும் அந்த இரண்டு மதிப்புகளைக் கொண்டே உருவாக்குகிறது. எனவே, அதற்கு வழங்கப்பட்ட முகவரியையே அது அனுப்புகிறது. இரண்டையும் உங்கள் உண்மையான public URL-க்கு மாற்றி, stack-ஐ மீண்டும் உருவாக்கவும்.