Cara Pasang Supabase Sendiri pada VPS dengan Docker

Perkara yang anda bina

Pengehosan sendiri Supabase bermaksud menjalankan timbunan Docker Compose rasmi pada pelayan anda sendiri: Postgres, API REST di hadapannya, perkhidmatan pengesahan, storan fail, websocket masa nyata dan papan pemuka Studio. Anda mengklon satu repositori, mengedit satu fail .env dan memulakan kira-kira empat belas kontena yang bersama-sama berfungsi seperti projek Supabase yang anda kawal.

Pemasangannya ringkas. Masalah biasanya berpunca daripada fail .env. Fail itu disertakan dengan rahsia demo yang diterbitkan dalam repositori, dan timbunan yang dimulakan dengan nilai lalai tersebut terbuka kepada sesiapa yang menemuinya. Panduan ini menerangkan rahsia yang mesti anda gantikan, fungsi setiap perkhidmatan, jumlah memori sebenar yang diperlukan oleh timbunan dan cara mengemas kininya tanpa memadam pangkalan data anda.

Jika Compose masih baharu bagi anda, baca Asas Docker Compose pada VPS terlebih dahulu. Semua langkah di bawah menganggap docker compose version sudah memaparkan versi.

Kandungan sebenar timbunan

Supabase bukan satu program. Fail Compose memulakan sekumpulan perkhidmatan berasingan pada satu rangkaian. Dengan mengetahui fungsi setiap perkhidmatan, anda boleh menyahpepijatnya dengan lebih mudah.

• db ialah PostgreSQL dengan sambungan Supabase yang dimuatkan. Semua perkhidmatan lain berkomunikasi dengannya. Jika kontena ini tidak sihat, semua perkhidmatan lain turut gagal.
• kong ialah get laluan API. Ia mendengar pada port 8000 dan menghala /rest/v1/, /auth/v1/ dan /storage/v1/ kepada backend yang betul. Inilah satu-satunya kontena yang patut anda dedahkan.
• rest ialah PostgREST. Ia membaca skema Postgres anda dan menyediakannya sebagai API REST. Oleh itu, jadual baharu menjadi endpoint baharu tanpa memerlukan kod.
• auth ialah GoTrue. Ia mengeluarkan JSON web token (JWT) yang mengenal pasti pengguna anda.
• storage dan imgproxy mengendalikan muat naik fail serta penskalaan semula imej.
• realtime menstrim perubahan pangkalan data melalui websocket.
• studio dan meta ialah papan pemuka serta API pentadbir di belakangnya.
• analytics (Logflare) dan vector mengumpulkan log, manakala supavisor ialah pooler sambungan Postgres.

Senarai itu menjelaskan sebab nombor sumber di bawah adalah sedemikian. Anda bukan hanya menjalankan pangkalan data. Anda menjalankan pangkalan data bersama sedozen perkhidmatan sokongan.

Saiz: rancang untuk 8 GB RAM

Stack menggunakan kira-kira 2.5 hingga 3 GB memori pemastautin semasa melahu selepas pemasangan baharu, setakat Julai 2026, sebelum data atau trafik anda sendiri ditambah. Perkhidmatan analitik dan proses Studio Node.js ialah dua pengguna sumber tunggal terbesar. Pelayan 2 GB akan memulakan bekas, kemudian satu bekas akan dihentikan oleh pembunuh kehabisan memori kernel, biasanya analytics atau db. Tandanya ialah bekas yang terus dimulakan semula dengan kod keluar 137.

Sediakan 8 GB RAM dan 4 vCPU untuk apa-apa perkhidmatan yang anda harapkan beroperasi dengan baik. 4 GB memadai untuk tika pembangunan seorang pengguna jika anda menerima bahawa pertanyaan berat dan sesi Studio yang berjalan serentak akan menjadi perlahan. Ruang cakera juga penting kerana Postgres, volum storan dan data log semuanya berada di bawah direktori projek. Mulakan dengan 40 GB dan pantau penggunaannya.

Pemasangan: klon repositori rasmi

Kaedah yang disokong menyalin direktori docker daripada repositori utama ke dalam direktori projek anda sendiri. Pengasingan ini penting kerana git pull yang seterusnya tidak dapat 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 perkhidmatan ditandai sebagai Pulled. Ralat manifest unknown di sini bermaksud tag imej yang dipin telah dialih keluar daripada repositori huluan. Penyelesaiannya ialah mengambil salinan repositori yang lebih baharu, bukan mengedit tag secara manual.

Rahsia yang mesti anda ubah sebelum permulaan pertama

Lakukan ini sebelum anda memulakan tindanan, bukan selepasnya. Beberapa nilai ini ditulis ke dalam data semasa but pertama. Oleh itu, menukarnya kemudian memerlukan anda menetapkan semula pangkalan data.

Repositori ini menyediakan 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 itu 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. Skrip ini memerlukan openssl, yang tersedia dalam mana-mana imej Ubuntu biasa.

Terdapat dua nilai yang tidak ditetapkan oleh skrip itu dan mesti anda edit secara manual dalam .env:

• POSTGRES_PASSWORD. Gunakan huruf dan digit sahaja. Tanda baca di sini merosakkan rentetan sambungan yang dibina oleh beberapa perkhidmatan dengan mencantumkan rentetan. Kegagalan itu kelihatan seperti ralat pengesahan, bukannya ralat penghuraian. Keadaan ini menyebabkan anda mencari punca di tempat yang salah.
• DASHBOARD_USERNAME dan DASHBOARD_PASSWORD. Ini ialah kelayakan pengesahan asas untuk Studio. Kata laluan lalai yang disediakan ialah this_password_is_insecure_and_should_be_updated secara literal.

Fahami sebab ANON_KEY dan SERVICE_ROLE_KEY tidak boleh direka secara sembarangan. Kedua-duanya ialah JWT yang ditandatangani dengan JWT_SECRET. Gateway mengesahkan tandatangan itu pada setiap permintaan. Oleh itu, kunci yang tidak sepadan dengan rahsia anda akan ditolak dengan {"message":"Invalid authentication credentials"}. Ini ialah kegagalan pengehosan sendiri yang paling biasa: operator menukar JWT_SECRET tetapi mengekalkan kunci demo. Jana ketiga-tiganya bersama-sama setiap kali.

Anggap SERVICE_ROLE_KEY seperti kata laluan root. Nilai ini memintas keselamatan peringkat baris sepenuhnya. Nilai ini hanya boleh digunakan dalam kod sebelah pelayan dan tidak boleh digunakan di tempat lain.

Tetapkan SITE_URL dan API_EXTERNAL_URL kepada alamat yang benar-benar akan dicapai oleh pengguna anda, contohnya https://supabase.example.com. Auth membina pautan pengesahan e-mel dan panggilan balik OAuth berdasarkan nilai tersebut. Oleh itu, jika anda membiarkannya pada http://localhost:8000, semua pengguna anda akan dihantar ke mesin mereka sendiri.

Kemudian semak nilai yang telah anda tetapkan:

sh run.sh secrets

Mulakan dan sahkan keadaannya sihat

sh run.sh start
docker compose ps

run.sh start membungkus docker compose up -d --wait, jadi perintah ini tidak kembali sehingga pemeriksaan kesihatan lulus. Setiap perkhidmatan sepatutnya memaparkan running (healthy) atau running. Permulaan pertama mengambil masa dua hingga empat minit kerana Postgres menjalankan skrip pemulaan sebelum perkara lain boleh bersambung.

Jika bekas dimulakan semula, baca lognya mengikut nama perkhidmatan:

docker compose logs db
docker compose logs auth

Studio tersedia pada port 8000, dan akan meminta nama pengguna serta kata laluan papan pemuka yang anda tetapkan.

Jangan dedahkan port 8000 kepada internet awam

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

Letakkan proksi terbalik di hadapannya dan tamatkan TLS (keselamatan lapisan pengangkutan) di situ. Ikat Kong pada alamat gelung balik supaya tiada komponen lain dapat mengaksesnya. Dalam docker-compose.yml, pemetaan port kong menjadi 127.0.0.1:8000:8000, dan proksi memajukan permintaan kepadanya. Traefik di hadapan beberapa aplikasi Compose menerangkan aspek sijil.

Tutup port yang selebihnya pada tembok api juga. Docker menerbitkan port dengan menulis peraturan iptables sendiri yang tidak dapat dilihat oleh konfigurasi ufw yang naif. Perangkap itu diterangkan dalam sebab bekas Docker mengabaikan peraturan ufw anda.

Sandarkan pangkalan data, bukan direktori

Data Postgres disimpan dalam lekapan bind pada ./volumes/db/data. Menyalin direktori itu semasa kontena sedang berjalan menghasilkan salinan yang tidak lengkap kerana Postgres menimbal penulisan, dan fail pada cakera hanya konsisten semasa checkpoint. Pemulihan biasanya berjaya, tetapi kadangkala transaksi terakhir hilang tanpa disedari. Ini ialah mod kegagalan paling buruk untuk sandaran.

Sebaliknya, hasilkan dump. pg_dumpall dijalankan dalam kontena dan menghasilkan syot kilat yang konsisten:

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

Semak bahawa fail itu tidak kosong sebelum menggunakannya. Kemudian hantar dump itu keluar dari pelayan mengikut jadual. Itulah kegunaan sandaran luar tapak terenkripsi dengan restic. Sandarkan .env pada masa yang sama. Jika JWT_SECRET hilang, setiap token yang telah dikeluarkan menjadi tidak sah dan setiap rahsia terenkripsi yang disimpan tidak boleh dibaca.

Fail yang dimuat naik berada dalam ./volumes/storage. Fail tersebut ialah fail biasa, jadi salinan biasa sudah memadai.

Kemas kini tanpa kehilangan data

Supabase menetapkan versi imej dalam docker-compose.yml, jadi tiada apa-apa yang berubah sehingga anda mengemas kininya. Buat dump terlebih dahulu, setiap kali.

docker compose pull
sh run.sh recreate

recreate menghentikan stack dan memulakannya semula menggunakan imej baharu. Data anda kekal kerana data tersebut berada dalam bind mount pada hos, bukan di dalam bekas. Baca CHANGELOG.md dalam repositori sebelum melakukan lonjakan versi utama, kerana peningkatan versi utama Postgres tidak dilakukan secara automatik dan memerlukan dump serta pemulihan.

Untuk menggunakan perubahan pada fail Compose itu sendiri, clone repositori huluan sekali lagi dan salin direktori docker ke projek anda, sambil memastikan .env tidak ditulis ganti.

Set semula penuh, yang memusnahkan segala-galanya termasuk pangkalan data, menggunakan skrip berasingan dan meminta pengesahan:

sh reset.sh

FAQ

Mengapakah panggilan API saya mengembalikan "Invalid authentication credentials"?

ANON_KEY atau SERVICE_ROLE_KEY anda tidak ditandatangani menggunakan JWT_SECRET yang sedang digunakan dalam .env. Gateway mengesahkan tandatangan bagi setiap permintaan dan menolak ketidakpadanan. Jana semula ketiga-tiganya bersama-sama menggunakan sh utils/generate-keys.sh --update-env, kemudian jalankan sh run.sh recreate supaya perkhidmatan membaca nilai baharu.

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

Tidak dengan boleh dipercayai. Stack menggunakan hampir 3 GB ketika melahu setakat July 2026 kerana menjalankan kira-kira fourteen perkhidmatan. Oleh itu, mesin 2 GB akan kehilangan container apabila out of memory killer bertindak, dan anda akan melihat exit code 137 dalam docker compose ps. Gunakan 8 GB untuk production dan anggap 4 GB sebagai had minimum untuk pembangunan secara solo.

Adakah Supabase yang dihoskan sendiri menyertakan edge functions?

Ya. Fail Compose menyertakan runtime fungsi berasaskan Deno dan menyediakan apa-apa yang anda letakkan di bawah ./volumes/functions. Ia tidak menyertakan rangkaian deployment global platform yang dihoskan. Oleh itu, fungsi anda berjalan pada satu server anda, di satu lokasi.

Bagaimanakah saya menyambung terus ke pangkalan data Postgres?

Gunakan docker exec -it supabase-db psql -U postgres untuk membuka shell interaktif pada server itu sendiri. Bagi client luaran, sambung melalui Supavisor pada port 5432 menggunakan user postgres.<POOLER_TENANT_ID> dan POSTGRES_PASSWORD anda. Jangan buka port itu kepada internet. Aksesnya melalui VPN atau terowong SSH.

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

SITE_URL dan API_EXTERNAL_URL dalam .env masih menggunakan nilai lalai. Perkhidmatan auth membina setiap pautan pengesahan dan tetapan semula kata laluan berdasarkan kedua-dua nilai tersebut. Oleh itu, perkhidmatan itu menghantar alamat yang dikonfigurasikan. Tetapkan kedua-duanya kepada URL awam sebenar anda dan cipta semula stack.