Jinsi ya Kujihostia Supabase kwenye VPS kwa Docker

Unachokijenga

Kujihostia Supabase kunamaanisha kuendesha stack rasmi ya Docker Compose kwenye seva yako mwenyewe: Postgres, API ya REST iliyo mbele yake, huduma ya uthibitishaji, hifadhi ya faili, websockets za wakati halisi, na dashibodi ya Studio. Unakloni repository moja, unahariri faili moja ya .env, kisha unaanzisha takriban kontena kumi na nne ambazo kwa pamoja hufanya kazi kama mradi wa Supabase unaoudhibiti.

Usakinishaji ni mfupi. Tatizo hutokea kwenye faili ya .env. Faili hiyo inakuja na siri za majaribio zilizochapishwa kwenye repository, na stack iliyoanzishwa kwa mipangilio hiyo chaguomsingi huwa wazi kwa mtu yeyote anayeipata. Mwongozo huu unaeleza siri unazopaswa kubadilisha, kazi ya kila huduma, kiasi halisi cha kumbukumbu ambacho stack inahitaji, na jinsi ya kuisasisha bila kufuta database yako.

Ikiwa Compose bado ni mpya kwako, soma Misingi ya Docker Compose kwenye VPS kwanza. Kila kitu hapa kinachukulia kuwa docker compose version tayari inaonyesha toleo.

Stacki ina nini hasa

Supabase si programu moja. Faili ya Compose huanzisha seti ya huduma tofauti kwenye mtandao mmoja. Kujua kazi ya kila huduma hufanya majina mengi ya kontena yawe rahisi kuyatatua.

• db ni PostgreSQL yenye viendelezi vya Supabase vilivyopakiwa. Kila huduma nyingine huwasiliana nayo. Kontena hii ikiwa na hitilafu, huduma nyingine zote pia hushindwa.
• kong ni lango la API. Husikiliza kwenye port 8000 na kuelekeza /rest/v1/, /auth/v1/ na /storage/v1/ kwa backend inayofaa. Hili ndilo kontena pekee unalopaswa kuweka wazi kwa mtandao wa nje.
• rest ni PostgREST. Husoma schema yako ya Postgres na kuiwasilisha kama REST API. Kwa hiyo, jedwali jipya huwa endpoint mpya bila kuandika msimbo.
• auth ni GoTrue. Hutengeneza tokeni za JSON web (JWT) zinazowatambulisha watumiaji wako.
• storage na imgproxy hushughulikia upakiaji wa faili na kubadilisha ukubwa wa picha.
• realtime hutiririsha mabadiliko ya hifadhidata kupitia websockets.
• studio na meta ni dashibodi na admin API inayoiendesha.
• analytics (Logflare) na vector hukusanya logi, na supavisor ni pooler ya miunganisho ya Postgres.

Orodha hii inaeleza kwa nini namba za rasilimali zilizo hapa chini ziko hivyo. Hauendeshi hifadhidata pekee. Unaendesha hifadhidata pamoja na huduma kadhaa za usaidizi.

Ukubwa: panga kwa RAM ya 8 GB

Stack hutumia takribani GB 2.5 hadi 3 za memory inayokaa kwenye RAM baada ya usakinishaji mpya, kufikia Julai 2026, kabla ya kuongeza data au traffic yako. Huduma ya analytics na mchakato wa Studio Node.js ndizo zinazotumia kiasi kikubwa zaidi cha memory. Server yenye GB 2 itaanzisha containers, kisha kernel out of memory killer itaondoa moja, kwa kawaida analytics au db. Dalili yake ni container inayokwama kuanza upya ikiwa na exit code 137.

Ipe RAM ya GB 8 na vCPU 4 kwa kitu chochote unachokitegemea. GB 4 inatosha kwa instance ya maendeleo ya mtu mmoja ikiwa unakubali kwamba query nzito na session ya Studio kwa wakati mmoja vitakuwa polepole. Disk pia ni muhimu, kwa sababu Postgres, storage volume na log data zote huhifadhiwa chini ya project directory. Anza na GB 40 na ifuatilie.

Sakinisha: kloni hazina rasmi

Njia inayotumika hunakili saraka ya docker kutoka kwenye hazina kuu hadi kwenye saraka ya mradi uliyochagua. Utenganishaji huo ni muhimu, kwa sababu unazuia git pull ya baadaye kubadilisha .env yako.

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 hupakua gigabaiti kadhaa za picha. Inapaswa kumalizika huku kila huduma ikiwa na hali ya Pulled. Hitilafu ya manifest unknown hapa inamaanisha kuwa lebo ya picha iliyowekwa imeondolewa kwenye chanzo cha juu, na suluhisho ni kuvuta nakala mpya zaidi ya hazina badala ya kuhariri lebo wewe mwenyewe.

Siri unazopaswa kubadilisha kabla ya kuwasha kwa mara ya kwanza

Fanya hivi kabla ya kuwasha stack, si baada yake. Baadhi ya thamani hizi huandikwa kwenye data wakati wa kuwasha kwa mara ya kwanza, hivyo kuzibadilisha baadaye kunamaanisha kuweka upya database.

Hifadhi ya msimbo inasafirisha generator inayozalisha kila thamani kwa usahihi, ikiwemo API keys mbili zinazopaswa kusainiwa kwa JWT secret yako mpya.

sh utils/generate-keys.sh --update-env

Script hiyo huandika thamani mpya za JWT_SECRET, ANON_KEY, SERVICE_ROLE_KEY, SECRET_KEY_BASE, REALTIME_DB_ENC_KEY, VAULT_ENC_KEY, PG_META_CRYPTO_KEY na tokens za Logflare kwenye .env. Inahitaji openssl, ambayo hupatikana kwenye image yoyote ya kawaida ya Ubuntu.

Thamani mbili haizibadilishi, na ni lazima uzihariri mwenyewe katika .env:

• POSTGRES_PASSWORD. Tumia herufi na tarakimu pekee. Alama za uakifishaji hapa huvunja connection strings ambazo services kadhaa huunda kwa kuunganisha strings. Hitilafu hiyo huonekana kama hitilafu ya uthibitishaji badala ya hitilafu ya uchanganuzi, hivyo huwafanya watu kutafuta tatizo mahali pasipofaa.
• DASHBOARD_USERNAME na DASHBOARD_PASSWORD. Hizi ni credentials za basic authentication za Studio. Password chaguo-msingi inayosafirishwa ni this_password_is_insecure_and_should_be_updated kihalisi.

Elewa kwa nini ANON_KEY na SERVICE_ROLE_KEY haziwezi kubuniwa kiholela. Zote ni JWTs zilizosainiwa kwa JWT_SECRET. Gateway huthibitisha sahihi hiyo kwenye kila ombi, hivyo key isiyolingana na secret yako hukataliwa kwa {"message":"Invalid authentication credentials"}. Hili ndilo tatizo linalotokea mara nyingi zaidi katika self-hosting: operator alibadilisha JWT_SECRET lakini akaacha demo keys. Zalisha zote tatu pamoja, kila mara.

Chukulia SERVICE_ROLE_KEY kama root password. Hupita kabisa row level security. Inapaswa kuwekwa kwenye server side code pekee, na si mahali pengine.

Weka SITE_URL na API_EXTERNAL_URL ziwe anwani ambayo watumiaji wako watafikia, kwa mfano https://supabase.example.com. Auth huunda links za uthibitishaji wa barua pepe na callbacks za OAuth kutokana na thamani hizo, hivyo kuziacha zikiwa http://localhost:8000 huwapeleka watumiaji wako wote kwenye mashine zao wenyewe.

Kisha kagua ulicho nacho:

sh run.sh secrets

Iwashe na uthibitishe kuwa iko katika hali nzuri

sh run.sh start
docker compose ps

run.sh start husubiri docker compose up -d --wait ikamilike, hivyo hairudi hadi ukaguzi wa hali upite. Kila huduma inapaswa kuonyesha running (healthy) au running. Kuanzisha mara ya kwanza huchukua dakika mbili hadi nne kwa sababu Postgres huendesha hati zake za uanzishaji kabla ya kitu kingine kuunganishwa.

Ikiwa kontena inaanza upya, soma kumbukumbu zake kwa kutumia jina la huduma:

docker compose logs db
docker compose logs auth

Studio inapatikana kwenye port 8000, kisha itaomba jina la mtumiaji na nenosiri la dashibodi uliloweka.

Usiiweke port 8000 kwenye intaneti ya umma

Kong kwenye port 8000 hutumia HTTP isiyo na usimbaji fiche. Kila API key na kila nenosiri la mtumiaji hupitia mtandao kwa maandishi wazi. Kitambulisho cha Studio hutumia basic authentication, ambayo ni usimbaji wa base64 badala ya usimbaji fiche.

Weka reverse proxy mbele yake. Malizia TLS (usalama wa safu ya usafirishaji) hapo. Kisha funga Kong kwenye anwani ya loopback ili hakuna kitu kingine kiweze kuifikia. Kwenye docker-compose.yml, upangaji wa port kong unakuwa 127.0.0.1:8000:8000, na proxy hupeleka maombi kwenye hapo. Traefik mbele ya programu kadhaa za Compose inaeleza upande wa vyeti.

Funga pia milango mingine kwenye firewall. Docker huchapisha milango kwa kuandika sheria zake za iptables, ambazo usanidi rahisi wa ufw hauzizingatii. Mtego huo umeelezwa katika kwa nini kontena za Docker hupuuza sheria zako za ufw.

Hifadhi nakala ya hifadhidata, si ya saraka

Data ya Postgres iko katika bind mount kwenye ./volumes/db/data. Kunakili saraka hiyo wakati container inaendelea kufanya kazi kunakupa nakala isiyokamilika, kwa sababu Postgres huhifadhi kwa muda mabadiliko ya uandishi kwenye bafa na faili zilizo kwenye diski huwa thabiti tu wakati wa checkpoint. Kuirejesha kwa kawaida hufanya kazi, lakini wakati mwingine hupoteza kimya kimya miamala ya mwisho. Hii ndiyo hali mbaya zaidi inayoweza kutokea kwenye hifadhi nakala.

Badala yake, tengeneza dump. pg_dumpall huendeshwa ndani ya container na hutengeneza snapshot thabiti:

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

Thibitisha kuwa faili si tupu kabla ya kuiamini. Kisha tuma dump hizo nje ya server kwa ratiba maalum. Hilo ndilo lengo la hifadhi nakala zilizosimbwa nje ya server kwa kutumia restic. Hifadhi nakala ya .env kwa wakati huo huo. Kupoteza JWT_SECRET kunamaanisha kuwa kila tokeni iliyotolewa huwa batili na kila siri iliyohifadhiwa kwa usimbaji huwa haisomeki.

Faili zilizopakiwa ziko kwenye ./volumes/storage. Hizo ni faili za kawaida, kwa hiyo kunakili moja kwa moja kunatosha.

Sasisha bila kupoteza data

Supabase huweka matoleo ya image kwenye docker-compose.yml, kwa hiyo hakuna kinachobadilika hadi ubadilishe mwenyewe. Tengeneza dump kwanza, kila mara.

docker compose pull
sh run.sh recreate

recreate husimamisha stack na kuianzisha tena kwa kutumia images mpya. Data yako inabaki kwa sababu iko kwenye bind mounts kwenye host, si ndani ya containers. Soma CHANGELOG.md kwenye repository kabla ya kuruka hadi toleo kuu jipya, kwa sababu masasisho makuu ya Postgres hayafanyiki kiotomatiki na yanahitaji dump na restore.

Ili kutumia mabadiliko ya faili ya Compose yenyewe, clone repository ya upstream tena na unakili directory yake ya docker kwenye mradi wako, ukihakikisha kwamba hauandiki juu ya .env.

Reset kamili, ambayo huharibu kila kitu pamoja na database, ni script tofauti na huomba uthibitisho:

sh reset.sh

FAQ

Kwa nini simu zangu za API zinarudisha "Invalid authentication credentials"?

ANON_KEY au SERVICE_ROLE_KEY yako haikusainiwa kwa kutumia JWT_SECRET iliyo katika .env kwa sasa. Lango huthibitisha sahihi kwenye kila ombi na hukataa tofauti. Tengeneza upya zote tatu pamoja kwa kutumia sh utils/generate-keys.sh --update-env, kisha endesha sh run.sh recreate ili huduma zisome thamani mpya.

Je, ninaweza kuendesha Supabase inayojihifadhi kwenye VPS yenye 2 GB?

Si kwa kutegemewa. Stack hutumia karibu 3 GB ikiwa haifanyi kazi nyingi, kufikia Julai 2026, kwa sababu huendesha takriban huduma kumi na nne. Kwa hiyo, seva yenye 2 GB hupoteza kontena kwa sababu ya out of memory killer, na unaona exit code 137 katika docker compose ps. Tumia 8 GB kwa mazingira ya uzalishaji, na chukulia 4 GB kuwa kiwango cha chini kwa uundaji wa kibinafsi.

Je, Supabase inayojihifadhi inajumuisha edge functions?

Ndiyo. Faili ya Compose inajumuisha runtime ya functions inayotumia Deno, na huhudumia chochote unachoweka chini ya ./volumes/functions. Haijumuishi mtandao wa kimataifa wa deployment wa jukwaa linalohudishwa, kwa hiyo functions zako huendesha kwenye seva yako moja, katika eneo moja.

Ninaunganishaje moja kwa moja kwenye hifadhidata ya Postgres?

Tumia docker exec -it supabase-db psql -U postgres kwa shell shirikishi kwenye seva yenyewe. Kwa client ya nje, unganisha kupitia Supavisor kwenye port 5432 kwa kutumia user postgres.<POOLER_TENANT_ID> na POSTGRES_PASSWORD yako. Usifungue port hiyo kwa intaneti. Ifikie kupitia VPN au SSH tunnel.

Kwa nini barua pepe zangu za uthibitishaji wa auth ziliunganisha kwenye localhost?

SITE_URL na API_EXTERNAL_URL katika .env ziliachwa na thamani zake za msingi. Huduma ya auth hutengeneza kila kiungo cha uthibitishaji na kuweka upya nenosiri kutokana na thamani hizo mbili, kwa hiyo hutuma anwani iliyoelekezwa itume. Weka zote mbili ziwe URL yako halisi ya umma, kisha tengeneza upya stack.