VPS-ல் Docker மூலம் Supabase self-host செய்வது எப்படி

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

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

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

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

stack-இல் உண்மையில் உள்ளவை

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

• db என்பது Supabase extensions ஏற்றப்பட்ட PostgreSQL ஆகும். மற்ற எல்லா services-களும் இதனுடன் தொடர்புகொள்கின்றன. இந்த container-ன் health சரியில்லையெனில், மற்ற அனைத்தும் தோல்வியடையும்.
• kong என்பது API gateway ஆகும். இது port 8000-இல் listening செய்கிறது. மேலும் /rest/v1/, /auth/v1/ மற்றும் /storage/v1/ ஆகியவற்றைச் சரியான backend-களுக்கு route செய்கிறது. நீங்கள் வெளிப்படுத்த வேண்டிய ஒரே 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-க்கு திட்டமிடுங்கள்

புதிய install-ல், உங்கள் சொந்த data அல்லது traffic எதுவும் இல்லாத நிலையில், July 2026 நிலவரப்படி இந்த 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 உடன் மீண்டும் மீண்டும் restart ஆகிக் கொண்டிருப்பதே அறிகுறியாகும்.

நீங்கள் சார்ந்திருக்கும் எந்த 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 செய்யுங்கள்.

நிறுவல்: அதிகாரப்பூர்வ 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 செய்வதாகும்.

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

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 பயன்படுத்தினால், பல 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-ஐ ஊகித்து உருவாக்க முடியாததற்கான காரணத்தைப் புரிந்துகொள்ளுங்கள். இரண்டும் JWT_SECRET-உடன் sign செய்யப்பட்ட JWTs. Gateway ஒவ்வொரு request-இலும் அந்த signature-ஐ verify செய்கிறது. எனவே உங்கள் secret-உடன் பொருந்தாத key, {"message":"Invalid authentication credentials"} உடன் reject செய்யப்படும். Self-hosting-இல் இது மிகவும் பொதுவான தோல்வியாகும்: operator JWT_SECRET-ஐ மாற்றிவிட்டு demo keys-ஐ வைத்திருப்பார். மூன்றையும் எப்போதும் ஒன்றாக உருவாக்குங்கள்.

SERVICE_ROLE_KEY-ஐ root password போலக் கருதுங்கள். இது row level security-ஐ முழுமையாகத் தாண்டுகிறது. இது 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 எனக் காட்ட வேண்டும். முதல் தொடக்கத்திற்கு இரண்டு முதல் நான்கு நிமிடங்கள் ஆகும். ஏனெனில், வேறு எதுவும் இணைவதற்கு முன் Postgres அதன் initialization scripts-ஐ இயக்குகிறது.

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

docker compose logs db
docker compose logs auth

அதன்பின் Studio port 8000-ல் இயங்கும். நீங்கள் அமைத்த dashboard username மற்றும் password-ஐ அது கேட்கும்.

port 8000-ஐ public internet-ல் வைக்க வேண்டாம்

Kong, 8000-ல் plain HTTP-ஐ பயன்படுத்துகிறது. ஒவ்வொரு API key-உம் ஒவ்வொரு user password-உம் network வழியாக clear text-ஆக அனுப்பப்படுகின்றன. 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, அந்த mapping-க்கு forward செய்யும். சான்றிதழ் தொடர்பான பகுதியை பல Compose apps-களுக்கு முன் Traefik விளக்குகிறது.

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

கோப்பகத்தை அல்ல, database-ஐ backup செய்யுங்கள்

Postgres தரவு ./volumes/db/data-இல் உள்ள bind mount-ல் சேமிக்கப்படுகிறது. Container இயங்கிக்கொண்டிருக்கும்போது அந்தக் கோப்பகத்தை copy செய்தால், முழுமையற்ற copy கிடைக்கும். காரணம், Postgres write-களை buffer செய்கிறது; disk-ல் உள்ள files checkpoint நேரத்தில் மட்டுமே ஒரே நிலையான நிலையில் இருக்கும். அதை restore செய்வது பொதுவாகச் செயல்படும். ஆனால் சில நேரங்களில் கடைசி transactions அமைதியாக இழக்கப்படும். Backup-க்கு இது மிக மோசமான 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-ஐயும் backup செய்யுங்கள். JWT_SECRET இழந்தால் வழங்கப்பட்ட ஒவ்வொரு token-மும் செல்லாததாகிவிடும்; சேமிக்கப்பட்ட encrypted secret அனைத்தையும் படிக்க முடியாது.

Upload செய்யப்பட்ட files ./volumes/storage-ல் உள்ளன. அவை சாதாரண files என்பதால், அவற்றை வழக்கமான copy மூலம் backup செய்வது போதுமானது.

தரவை இழக்காமல் புதுப்பித்தல்

Supabase image பதிப்புகளை docker-compose.yml இல் நிலைப்படுத்துகிறது. ஆகவே, நீங்கள் அதை மாற்றும் வரை எதுவும் மாறாது. ஒவ்வொரு முறையும் முதலில் dump எடுக்கவும்.

docker compose pull
sh run.sh recreate

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

Compose file-இல் உள்ள மாற்றங்களைப் பெற, upstream repository-ஐ மீண்டும் clone செய்து, அதன் docker directory-ஐ உங்கள் project-க்கு copy செய்யவும். .env-ஐ overwrite செய்யாமல் கவனமாக இருக்கவும்.

தரவுத்தளத்தையும் சேர்த்து அனைத்தையும் அழிக்கும் முழுமையான reset, தனி script மூலம் செய்யப்படுகிறது. அது confirmation கேட்கும்:

sh reset.sh

FAQ

எனது API calls ஏன் "Invalid authentication credentials" எனத் திருப்பி அளிக்கின்றன?

உங்கள் ANON_KEY அல்லது SERVICE_ROLE_KEY, தற்போது .env இல் உள்ள JWT_SECRET கொண்டு sign செய்யப்படவில்லை. Gateway ஒவ்வொரு request-இலும் signature-ஐ சரிபார்த்து, பொருத்தமின்மை இருந்தால் request-ஐ நிராகரிக்கிறது. sh utils/generate-keys.sh --update-env மூலம் இந்த மூன்றையும் ஒன்றாக மீண்டும் உருவாக்கவும். பின்னர் sh run.sh recreate-ஐ இயக்கவும். இதனால் 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 பயன்படுத்தவும். தனிப்பட்ட development-க்கு 4 GB-ஐ குறைந்தபட்ச அளவாகக் கருதவும்.

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

ஆம். Compose file-இல் Deno based functions runtime உள்ளது. ./volumes/functions-ன் கீழ் நீங்கள் வைக்கும் அனைத்தையும் அது serve செய்யும். Hosted platform-இன் global deployment network இதில் இல்லை. எனவே உங்கள் functions ஒரே location-இல் உள்ள உங்கள் ஒரே server-இல் இயங்கும்.

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-க்கு திறக்க வேண்டாம். VPN அல்லது SSH tunnel மூலம் அணுகவும்.

எனது auth confirmation emails ஏன் localhost-க்கு link செய்தன?

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