Cara Self-host Supabase di VPS Menggunakan Docker

Apa yang anda sedang bina

Self-hosting Supabase bermaksud menjalankan stack Docker Compose rasmi pada pelayan anda sendiri: Postgres, API REST di hadapannya, servis pengesahan, storan fail, websocket masa nyata, dan papan pemuka Studio. Anda mengklon satu repositori, menyunting satu fail .env, dan memulakan kira-kira empat belas kontena yang secara keseluruhannya berfungsi seperti projek Supabase di bawah kawalan anda.

Proses pemasangan adalah singkat. Bahagian yang sering bermasalah ialah fail .env. Ia dibekalkan dengan rahsia demo yang diterbitkan dalam repositori, dan stack yang dimulakan dengan tetapan lalai tersebut terbuka kepada sesiapa sahaja yang menemuinya. Panduan ini merangkumi rahsia yang mesti anda gantikan, kegunaan setiap servis, jumlah memori yang sebenarnya diperlukan oleh stack ini, dan cara mengemas kininya tanpa memadamkan pangkalan data anda.

Jika Compose merupakan perkara baharu bagi anda, baca Asas Docker Compose pada VPS terlebih dahulu. Segala maklumat di bawah mengandaikan docker compose version sudah memaparkan versi.

Kandungan sebenar stack tersebut

Supabase bukanlah satu program tunggal. Fail Compose memulakan set servis berasingan pada satu rangkaian, dan memahami fungsi setiap satu akan membantu anda menyahpepijat senarai nama kontena yang panjang.

• db ialah PostgreSQL dengan sambungan Supabase dimuatkan. Setiap servis lain berhubung dengannya. Jika kontena ini tidak sihat, semua servis lain turut gagal.
• kong ialah API gateway. Ia mendengar pada port 8000 dan menghalakan /rest/v1/, /auth/v1/ serta /storage/v1/ ke backend yang betul. Ia adalah satu-satunya kontena yang perlu anda dedahkan.
• rest ialah PostgREST. Ia membaca skema Postgres anda dan menyediakannya sebagai REST API, supaya jadual baharu menjadi endpoint baharu tanpa perlu menulis kod.
• auth ialah GoTrue. Ia mengeluarkan JSON web tokens (JWT) yang mengenal pasti pengguna anda.
• storage dan imgproxy mengendalikan muat naik fail dan pengubahan saiz imej.
• realtime menstrim perubahan pangkalan data melalui websockets.
• studio dan meta ialah papan pemuka dan API pentadbir di sebaliknya.
• analytics (Logflare) dan vector mengumpul log, dan supavisor ialah Postgres connection pooler.

Senarai itulah sebabnya angka sumber di bawah ditetapkan sedemikian. Anda bukan sekadar menjalankan pangkalan data. Anda menjalankan pangkalan data berserta sedozen servis sokongan.

Saiz: rancang untuk 8 GB RAM

Stak ini menggunakan kira-kira 2.5 hingga 3 GB memori residen semasa melahu pada pemasangan baharu, setakat Julai 2026, sebelum data atau trafik anda sendiri diambil kira. Servis analitik dan proses Studio Node.js merupakan dua pengguna memori terbesar. Pelayan 2 GB akan memulakan kontena tetapi kemudian kehilangan satu daripadanya akibat kernel out of memory killer, biasanya analytics atau db, dan simptomnya ialah kontena tersekat dalam gelung but semula dengan kod keluar 137.

Sediakan 8 GB RAM dan 4 vCPU untuk sebarang sistem yang anda harapkan. 4 GB memadai untuk instans pembangunan solo jika anda menerima hakikat bahawa pertanyaan berat dan sesi Studio yang dijalankan serentak akan menjadi perlahan. Storan cakera juga penting, kerana Postgres, volum storan dan data log semuanya berada di bawah direktori projek. Mulakan dengan 40 GB dan pantau penggunaannya. Mengira jumlah servis sebelum memilih pelan adalah tabiat yang wajar diamalkan untuk sebarang perisian yang anda hos sendiri, memandangkan PhotoPrism dan Immich mempunyai keperluan RAM minimum yang jauh lebih tinggi daripada apa yang tersirat dalam halaman permulaan pantas mereka.

Pemasangan: klon repositori rasmi

Laluan yang disokong menyalin direktori docker daripada repositori utama ke dalam direktori projek anda sendiri. Pemisahan ini penting kerana ia bermaksud git pull yang akan datang tidak boleh menulis ganti .env anda.

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 memuat turun beberapa gigabait imej. Proses ini sepatutnya berakhir dengan setiap servis ditandakan sebagai Pulled. Ralat manifest unknown di sini bermaksud tag imej yang dipinkan telah dialih keluar di bahagian hulu (upstream), dan penyelesaiannya adalah dengan menarik salinan repositori yang lebih baharu dan bukannya menyunting tag secara manual.

Rahsia yang mesti anda tukar sebelum permulaan pertama

Lakukan ini sebelum anda memulakan stack, bukan selepasnya. Beberapa nilai ini ditulis ke dalam data semasa but pertama, jadi menukarnya kemudian bermakna anda perlu menetapkan semula pangkalan data.

Repositori ini membekalkan penjana yang menghasilkan setiap nilai dengan betul, termasuk dua kunci API yang mesti ditandatangani dengan rahsia JWT baharu anda.

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

Skrip tersebut menulis nilai baharu untuk JWT_SECRET, ANON_KEY, SERVICE_ROLE_KEY, SECRET_KEY_BASE, REALTIME_DB_ENC_KEY, VAULT_ENC_KEY, PG_META_CRYPTO_KEY dan token Logflare ke dalam .env. Ia memerlukan openssl, yang tersedia pada mana-mana imej Ubuntu biasa.

Dua nilai yang tidak ditetapkan oleh skrip tersebut, dan perlu anda edit secara manual dalam .env ialah:

• POSTGRES_PASSWORD. Gunakan huruf dan angka sahaja. Tanda baca di sini akan merosakkan rentetan sambungan yang dibina oleh beberapa servis dengan mencantumkan rentetan, dan kegagalan tersebut kelihatan seperti ralat pengesahan dan bukannya ralat penghuraian, yang menyebabkan pengguna mencari punca di tempat yang salah.
• DASHBOARD_USERNAME dan DASHBOARD_PASSWORD. Ini adalah kelayakan pengesahan asas untuk Studio. Kata laluan lalai yang dibekalkan ialah this_password_is_insecure_and_should_be_updated.

Fahami mengapa ANON_KEY dan SERVICE_ROLE_KEY tidak boleh direka sendiri. Kedua-duanya adalah JWT yang ditandatangani dengan JWT_SECRET. Gateway akan mengesahkan tandatangan tersebut pada setiap permintaan, jadi kunci yang tidak sepadan dengan rahsia anda akan ditolak dengan {"message":"Invalid authentication credentials"}. Ini adalah kegagalan self-hosting yang paling biasa: pengendali menukar JWT_SECRET tetapi mengekalkan kunci demo. Sentiasa jana ketiga-tiganya bersama-sama.

Anggap SERVICE_ROLE_KEY seperti kata laluan root. Ia memintas keselamatan peringkat baris (row level security) sepenuhnya. Ia hanya boleh diletakkan dalam kod bahagian pelayan dan tidak boleh diletakkan di tempat lain.

Tetapkan SITE_URL dan API_EXTERNAL_URL kepada alamat yang akan diakses oleh pengguna anda, contohnya https://supabase.example.com. Auth membina pautan pengesahan e-mel dan pautan panggil balik OAuth daripada nilai tersebut, jadi jika dibiarkan pada http://localhost:8000, ia akan menghantar setiap pengguna anda ke mesin mereka sendiri.

Kemudian semak apa yang anda miliki:

sh run.sh secrets

Mulakan ia dan sahkan ia sihat

sh run.sh start
docker compose ps

run.sh start membungkus docker compose up -d --wait, jadi ia tidak akan kembali sehingga pemeriksaan kesihatan selesai. Setiap servis harus menunjukkan running (healthy) atau running. But pertama mengambil masa dua hingga empat minit kerana Postgres menjalankan skrip permulaannya sebelum perkara lain boleh disambungkan.

Jika kontena sedang dimulakan semula, baca lognya mengikut nama servis:

docker compose logs db
docker compose logs auth

Studio kemudiannya berada pada port 8000, dan ia akan meminta nama pengguna serta kata laluan papan pemuka yang telah anda tetapkan.

Jangan dedahkan port 8000 kepada internet awam

Kong pada port 8000 menggunakan HTTP biasa. Setiap kunci API dan kata laluan pengguna dihantar melalui rangkaian dalam teks jelas, dan kelayakan Studio menggunakan pengesahan asas (basic authentication), iaitu pengekodan base64 dan bukannya penyulitan.

Letakkan reverse proxy di hadapannya, tamatkan TLS (transport layer security) di situ, dan ikat (bind) Kong kepada alamat loopback supaya tiada peranti lain boleh mencapainya. Dalam docker-compose.yml, pemetaan port kong menjadi 127.0.0.1:8000:8000, dan proksi akan menghantar permintaan ke port tersebut. Traefik di hadapan beberapa aplikasi Compose merangkumi bahagian sijil.

Tutup port lain pada firewall juga, kerana Docker menerbitkan port dengan menulis peraturan iptables sendiri yang tidak dikesan oleh konfigurasi ufw biasa. Perangkap tersebut dijelaskan dalam mengapa kontena Docker mengabaikan peraturan ufw anda.

Sandarkan pangkalan data, bukan direktori

Data Postgres berada dalam bind mount di ./volumes/db/data. Menyalin direktori tersebut semasa kontena sedang berjalan akan menghasilkan salinan yang tidak konsisten, kerana Postgres menimbal (buffer) penulisan dan fail pada cakera hanya konsisten pada titik pusat pemeriksaan (checkpoint). Memulihkan data tersebut biasanya akan berjaya, namun kadangkala ia akan kehilangan transaksi terakhir secara senyap, yang merupakan mod kegagalan paling buruk bagi sandaran.

Gunakan dump sebaliknya. pg_dumpall berjalan di dalam kontena dan menghasilkan syot kilat (snapshot) yang konsisten:

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

Pastikan fail tersebut tidak kosong sebelum anda mempercayainya. Kemudian, pindahkan fail dump tersebut keluar dari pelayan mengikut jadual, iaitu tujuan bagi sandaran luar tapak yang disulitkan dengan restic. Sandarkan .env anda pada masa yang sama. Kehilangan JWT_SECRET bermakna setiap token yang dikeluarkan menjadi tidak sah dan setiap rahsia yang disulitkan tidak boleh dibaca.

Fail yang dimuat naik berada dalam ./volumes/storage, dan fail tersebut adalah fail biasa, jadi salinan terus adalah memadai.

Kemas kini tanpa kehilangan data

Supabase menetapkan versi image dalam docker-compose.yml, jadi tiada perubahan berlaku sehingga anda mengemas kininya. Amalan menetapkan versi ini wajar digunakan dalam mana-mana stack yang anda bina secara manual. Atas sebab itu, relay RustDesk yang dihoskan sendiri menetapkan versi bagi dua image pelayannya dan tidak mengikuti tag yang berubah-ubah. Naik taraf sepatutnya dilakukan apabila anda memilih masa yang sesuai untuknya. Buat dump terlebih dahulu setiap kali.

docker compose pull
sh run.sh recreate

recreate akan menghentikan stack dan memulakannya semula menggunakan imej baharu. Data anda kekal selamat kerana ia disimpan dalam bind mounts pada hos, bukan di dalam container. Baca CHANGELOG.md dalam repositori sebelum melakukan lonjakan versi utama, memandangkan naik taraf versi utama Postgres tidak berlaku secara automatik dan memerlukan proses dump serta restore.

Untuk mengambil perubahan pada fail Compose itu sendiri, clone semula repositori hulu dan salin direktori docker miliknya ke atas projek anda, dengan berhati-hati agar tidak menimpa .env.

Tetapan semula penuh (full reset), yang memusnahkan segala-galanya termasuk pangkalan data, merupakan skrip berasingan dan ia akan meminta pengesahan:

sh reset.sh

FAQ

Mengapakah panggilan API saya memulangkan "Invalid authentication credentials"?

ANON_KEY atau SERVICE_ROLE_KEY anda tidak ditandatangani dengan JWT_SECRET yang kini berada dalam .env. Gerbang (gateway) mengesahkan tandatangan pada setiap permintaan dan menolak sebarang ketidakpadanan. Jana semula ketiga-tiganya bersama-sama dengan sh utils/generate-keys.sh --update-env, kemudian jalankan sh run.sh recreate supaya servis membaca nilai baharu tersebut.

Bolehkah saya menjalankan Supabase yang dihoskan sendiri pada VPS 2 GB?

Tidak boleh dengan stabil. Stak tersebut melahu pada sekitar 3 GB setakat Julai 2026 kerana ia menjalankan kira-kira empat belas servis, jadi pelayan 2 GB akan kehilangan kontena akibat pembunuh kehabisan memori (out of memory killer) dan anda akan melihat kod keluar 137 dalam docker compose ps. Gunakan 8 GB untuk pengeluaran dan anggap 4 GB sebagai had minimum untuk pembangunan secara solo.

Adakah Supabase yang dihoskan sendiri merangkumi edge functions?

Ya. Fail Compose merangkumi runtime fungsi berasaskan Deno, dan ia melayani apa sahaja yang anda letakkan di bawah ./volumes/functions. Ia tidak merangkumi rangkaian penempatan global platform yang dihoskan, jadi fungsi anda berjalan pada satu pelayan anda, di satu lokasi sahaja.

Bagaimanakah cara untuk menyambung ke pangkalan data Postgres secara terus?

Gunakan docker exec -it supabase-db psql -U postgres untuk shell interaktif pada pelayan itu sendiri. Bagi klien luaran, sambung melalui Supavisor pada port 5432 dengan pengguna postgres.<POOLER_TENANT_ID> dan POSTGRES_PASSWORD anda. Jangan buka port tersebut kepada internet. Capai ia melalui VPN atau terowong SSH.

Mengapakah pautan e-mel pengesahan auth saya menghala ke localhost?

SITE_URL dan API_EXTERNAL_URL dalam .env dibiarkan pada nilai lalai. Servis auth membina setiap pautan pengesahan dan tetapan semula kata laluan daripada dua nilai tersebut, jadi ia menghantar alamat yang diarahkan kepadanya. Tetapkan kedua-duanya kepada URL awam sebenar anda dan cipta semula stak tersebut.