วิธีใช้ Supabase CLI: คู่มือพัฒนาฉบับสมบูรณ์ (2026)

สรุปสั้นๆ (TL;DR)

Supabase CLI รันสแต็ก Supabase เต็มรูปแบบบนเครื่องของคุณโดยใช้ Docker: PostgreSQL, การยืนยันตัวตน, ที่เก็บข้อมูล และฟังก์ชัน Edge ติดตั้งด้วย brew install supabase/tap/supabase, รัน supabase init และ supabase start เพื่อเปิดสภาพแวดล้อมในเครื่อง จากนั้นใช้ supabase db push และ supabase functions deploy เพื่อนำขึ้นสู่ Production นี่คือวิธีที่เร็วที่สุดในการสร้างและทดสอบแบ็กเอนด์ Supabase โดยไม่ต้องพึ่งคลาวด์

บทนำ

73% ของข้อผิดพลาดแบ็กเอนด์ถูกพบใน Production เพราะนักพัฒนาข้ามการทดสอบบนเครื่อง ด้วย Supabase CLI ปัญหานี้จึงไม่เป็นข้ออ้างอีกต่อไป คุณจะได้รับสภาพแวดล้อมที่เทียบเท่า Production เต็มรูปแบบทำงานบนเครื่องของคุณภายใน 5 นาที

นี่คือปัญหาที่แท้จริง: นักพัฒนาส่วนใหญ่ไม่ว่าจะทดสอบโดยตรงใน Production (เสี่ยง) หรือใช้เวลาหลายชั่วโมงในการกำหนดค่าสภาพแวดล้อมบนเครื่องที่ไม่ตรงกับระบบคลาวด์ (น่าหงุดหงิด) Supabase CLI แก้ปัญหาทั้งสองนี้ มันมอบสแต็กในเครื่องที่ใช้ Docker ซึ่งจำลอง Production ได้อย่างแม่นยำ ดังนั้นสิ่งที่ทำงานได้บนเครื่อง ก็จะทำงานได้ใน Production

💡

หากคุณกำลังสร้าง API บน Supabase คุณจะต้องมีเครื่องมือสำหรับออกแบบ ทดสอบ และจัดทำเอกสารสำหรับเอนด์พอยต์เหล่านั้น Apidog เชื่อมต่อโดยตรงกับ REST และ GraphQL API ของ Supabase ทำให้คุณสามารถทดสอบแบ็กเอนด์ได้ในขณะที่คุณสร้างมันบนเครื่อง

ปุ่ม

ทดสอบ Supabase API ของคุณด้วย Apidog - ฟรี

เมื่อจบคู่มือนี้ คุณจะสามารถ:

ตั้งค่าสภาพแวดล้อม Supabase ในเครื่องได้อย่างสมบูรณ์ในไม่กี่นาที
จัดการการเปลี่ยนแปลง Schema ของฐานข้อมูลด้วย Migrations ที่มีการควบคุมเวอร์ชัน
สร้างและทดสอบฟังก์ชัน Edge บนเครื่องก่อนนำไปใช้งานจริง
นำขึ้นสู่ Production ด้วยคำสั่งเดียว

ทำไมการพัฒนา Supabase บนเครื่องถึงมีปัญหาหากไม่มี CLI

หากคุณเคยพยายามสร้างแอป Supabase โดยไม่มี CLI คุณจะรู้ถึงความยุ่งยาก นี่คือสามสถานการณ์ที่เกิดขึ้นตลอดเวลา

กับดัก "ทดสอบใน Production" คุณทำการเปลี่ยนแปลง Schema โดยตรงในแดชบอร์ด Supabase มันทำงานได้ คุณพุชฟรอนต์เอนด์ของคุณ สามวันต่อมา เพื่อนร่วมทีมดึง repo และแอปของพวกเขาเสียเพราะฐานข้อมูลของพวกเขาไม่มีคอลัมน์ใหม่

สภาพแวดล้อมไม่ตรงกัน คุณตั้งค่าอินสแตนซ์ PostgreSQL บนเครื่อง สร้าง Supabase schema ของคุณขึ้นมาใหม่ด้วยตนเอง และใช้เวลาสองชั่วโมงในการดีบักว่าทำไม RLS (Row Level Security) policies ถึงทำงานแตกต่างกันในเครื่อง พวกมันไม่ได้ทำงานแตกต่างกัน คุณพลาด policy ไป

ปัญหา "ทำงานได้บนเครื่องของฉัน" Edge Function ของคุณทำงานใน Supabase dashboard editor แต่ล้มเหลวใน Production เพราะคุณทดสอบด้วยค่าที่ฮาร์ดโค้ดไว้แทนที่จะใช้ตัวแปรสภาพแวดล้อมจริง

นี่ไม่ใช่กรณีพิเศษ Schema drift (การเปลี่ยนแปลง Schema โดยที่ฐานข้อมูลในเครื่องและระยะไกลไม่ตรงกัน) คือปัญหาอันดับ 1 ที่รายงานสำหรับทีมที่ใช้ Supabase CLI แก้ปัญหาทั้งสามนี้:

Migrations ช่วยให้การเปลี่ยนแปลง Schema ถูกควบคุมเวอร์ชันและทำซ้ำได้
สแต็ก Docker บนเครื่องจำลอง Production ได้อย่างแม่นยำ ด้วย PostgreSQL เวอร์ชันเดียวกัน และเอ็นจิน RLS เดียวกัน
การให้บริการฟังก์ชันในเครื่องทดสอบ Edge Functions ด้วยตัวแปรสภาพแวดล้อมจริง

Supabase CLI ทำงานอย่างไร

สแต็กในเครื่อง

เมื่อคุณรัน supabase start, CLI จะเริ่มสแต็ก Docker Compose พร้อมบริการเหล่านี้:

บริการ	พอร์ต	วัตถุประสงค์
PostgreSQL	54322	ฐานข้อมูลของคุณ
PostgREST	54321	REST API ที่สร้างขึ้นโดยอัตโนมัติ
GoTrue	54321/auth	บริการยืนยันตัวตน
Realtime	54321/realtime	การสมัครสมาชิก WebSocket
Storage	54321/storage	ที่เก็บไฟล์
Studio	54323	แดชบอร์ดแบบกราฟิก
Inbucket	54324	การทดสอบอีเมล (ดักจับอีเมลทั้งหมดในเครื่อง)
Edge Runtime	54321/functions	ตัวรันฟังก์ชันที่ใช้ Deno

นี่คือสแต็กเดียวกับที่รันใน Supabase Cloud อยู่บนเครื่องของคุณ

การติดตั้ง

macOS:

brew install supabase/tap/supabase

Windows (Scoop):

scoop bucket add supabase https://github.com/supabase/scoop-bucket.git
scoop install supabase

Linux / npm:

npm install -g supabase

ตรวจสอบว่าทำงานได้หรือไม่:

supabase --version
# supabase 1.x.x

supabase start

การตั้งค่าโปรเจกต์

mkdir my-project && cd my-project
supabase init

นี่จะสร้าง:

supabase/
├── config.toml       # พอร์ต, การตั้งค่าการยืนยันตัวตน, การกำหนดค่าที่เก็บข้อมูล
├── seed.sql          # ข้อมูลสำหรับการพัฒนาที่โหลดทุกครั้งที่รีเซ็ตฐานข้อมูล
└── migrations/       # ประวัติเวอร์ชัน Schema

การเริ่มต้นสแต็กในเครื่อง

supabase start

การรันครั้งแรกจะดาวน์โหลดอิมเมจ Docker ประมาณ 1GB หลังจากนั้น การเริ่มต้นใช้เวลาประมาณ 10 วินาที

API URL: http://localhost:54321
DB URL:  postgresql://postgres:postgres@localhost:54322/postgres
Studio:  http://localhost:54323
anon key: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

คัดลอก anon key ลงในไฟล์ .env.local ของคุณ คุณจะต้องใช้มันสำหรับฟรอนต์เอนด์ของคุณ

การจัดการฐานข้อมูลด้วย Migrations

Migrations คือหัวใจสำคัญของเวิร์กโฟลว์ CLI การเปลี่ยนแปลง Schema ทุกครั้งจะกลายเป็นไฟล์ SQL ที่มีการควบคุมเวอร์ชันและติดตามใน Git ไม่มีอีกแล้วคำถาม "ใครเปลี่ยนฐานข้อมูลเมื่อไหร่"

การสร้าง Migration แรกของคุณ

supabase migration new create_posts_table
# สร้าง: supabase/migrations/20260324120000_create_posts_table.sql

แก้ไขไฟล์:

-- สร้างตาราง posts พร้อม RLS ตั้งแต่เริ่มต้น
CREATE TABLE posts (
  id          UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  user_id     UUID REFERENCES auth.users(id) ON DELETE CASCADE NOT NULL,
  title       TEXT NOT NULL,
  content     TEXT,
  published   BOOLEAN DEFAULT false,
  created_at  TIMESTAMPTZ DEFAULT NOW(),
  updated_at  TIMESTAMPTZ DEFAULT NOW()
);

-- เปิดใช้งาน Row Level Security
ALTER TABLE posts ENABLE ROW LEVEL SECURITY;

-- ใครๆ ก็สามารถอ่านโพสต์ที่เผยแพร่ได้
CREATE POLICY "Anyone can read published posts"
  ON posts FOR SELECT
  USING (published = true);

-- ผู้ใช้จัดการโพสต์ของตนเอง
CREATE POLICY "Users manage own posts"
  ON posts FOR ALL
  USING (auth.uid() = user_id);

-- อัปเดต updated_at โดยอัตโนมัติทุกครั้งที่มีการเปลี่ยนแปลง
CREATE OR REPLACE FUNCTION update_updated_at()
RETURNS TRIGGER AS $$
BEGIN
  NEW.updated_at = NOW();
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER posts_updated_at
  BEFORE UPDATE ON posts
  FOR EACH ROW EXECUTE FUNCTION update_updated_at();

นำไปใช้:

supabase migration up

การสร้าง TypeScript types

หลังจากทุกการเปลี่ยนแปลง Schema ให้สร้าง types ของคุณใหม่:

supabase gen types typescript --local > src/types/database.ts

ฟรอนต์เอนด์ของคุณจะได้รับความปลอดภัยของประเภทข้อมูลอย่างสมบูรณ์:

import { Database } from '@/types/database'

type Post = Database['public']['Tables']['posts']['Row']
type NewPost = Database['public']['Tables']['posts']['Insert']

// ตอนนี้ editor ของคุณจะจับข้อผิดพลาดของประเภทข้อมูลก่อนรันไทม์
const createPost = async (post: NewPost) => {
  const { data, error } = await supabase
    .from('posts')
    .insert(post)
    .select()
    .single()
  return data
}

การใส่ข้อมูลสำหรับการพัฒนา

แก้ไข supabase/seed.sql:

-- ผู้ใช้ทดสอบ (ข้ามการยืนยันตัวตนสำหรับการพัฒนาในเครื่อง)
INSERT INTO auth.users (id, email) VALUES
  ('00000000-0000-0000-0000-000000000001', 'alice@example.com'),
  ('00000000-0000-0000-0000-000000000002', 'bob@example.com');

-- โพสต์ทดสอบ
INSERT INTO posts (user_id, title, content, published) VALUES
  ('00000000-0000-0000-0000-000000000001', 'เริ่มต้นใช้งาน Supabase', 'นี่คือสิ่งที่ฉันได้เรียนรู้...', true),
  ('00000000-0000-0000-0000-000000000002', 'ฉบับร่าง: รูปแบบการออกแบบ API', 'อยู่ระหว่างการดำเนินการ...', false);

รีเซ็ตและใส่ข้อมูลใหม่ได้ตลอดเวลา:

supabase db reset

นี่จะลบทุกอย่าง, รัน migrations ทั้งหมดอีกครั้ง และโหลดข้อมูล seed ของคุณ รันมันทุกเช้าเพื่อเริ่มต้นใหม่

การทดสอบ Supabase API ด้วย Apidog

เมื่อ Supabase ในเครื่องของคุณทำงานอยู่ คุณจะมี REST API ที่ทำงานได้อย่างสมบูรณ์ที่ http://localhost:54321 Supabase สร้างเอนด์พอยต์สำหรับทุกตารางโดยอัตโนมัติผ่าน PostgREST การทดสอบด้วย curl ด้วยตนเองจะน่าเบื่ออย่างรวดเร็ว โดยเฉพาะอย่างยิ่งเมื่อคุณต้องการทดสอบ RLS policies ด้วยโทเค็นผู้ใช้ที่แตกต่างกัน

Apidog เชื่อมต่อโดยตรงกับอินสแตนซ์ Supabase ในเครื่องของคุณ คุณสามารถ:

บันทึกคำขอเป็นคอลเล็กชันที่นำกลับมาใช้ใหม่ได้
ทดสอบเอนด์พอยต์เดียวกันในฐานะผู้ใช้ที่แตกต่างกันโดยการสลับสภาพแวดล้อม
เพิ่มการยืนยัน ("การตอบสนองมีโพสต์อย่างน้อย 1 โพสต์") และรันเป็นชุดทดสอบ
แชร์เอกสาร API กับทีมของคุณโดยอัตโนมัติ

การตั้งค่า Apidog กับ Supabase ในเครื่อง:

สร้างโปรเจกต์ใหม่ใน Apidog
ตั้งค่า Base URL: http://localhost:54321
เพิ่มตัวแปรสภาพแวดล้อม: anon_key = your-local-anon-key
เพิ่มส่วนหัว Authorization: Bearer {{anon_key}}

การทดสอบเอนด์พอยต์ posts:

GET http://localhost:54321/rest/v1/posts?published=eq.true
Authorization: Bearer {{anon_key}}
apikey: {{anon_key}}

บันทึกสิ่งนี้เป็นคำขอ เพิ่มการยืนยันว่าการตอบสนองมีโพสต์อย่างน้อยหนึ่งโพสต์ และรันมันทุกครั้งที่คุณเปลี่ยน RLS policies ของคุณ คุณจะพบ policies ที่เสียหายก่อนที่จะถึง Production

เริ่มทดสอบ Supabase API ของคุณด้วย Apidog

ฟังก์ชัน Edge: สร้างและทดสอบบนเครื่อง

ฟังก์ชัน Edge รันบน Deno ที่ Edge ใกล้กับผู้ใช้ของคุณ เหมาะสำหรับ webhooks, background jobs และเอนด์พอยต์ API ที่ต้องการตรรกะฝั่งเซิร์ฟเวอร์

สร้างฟังก์ชัน

supabase functions new send-welcome-email

นี่จะสร้าง supabase/functions/send-welcome-email/index.ts:

import { serve } from 'https://deno.land/std@0.168.0/http/server.ts'
import { createClient } from 'https://esm.sh/@supabase/supabase-js@2'

serve(async (req) => {
  const { user_id } = await req.json()

  // Service role ข้าม RLS - ใช้ด้วยความระมัดระวัง
  const supabase = createClient(
    Deno.env.get('SUPABASE_URL')!,
    Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')!
  )

  const { data: profile } = await supabase
    .from('profiles')
    .select('email, full_name')
    .eq('id', user_id)
    .single()

  // ตรรกะการส่งอีเมลของคุณที่นี่
  console.log(`กำลังส่งอีเมลต้อนรับไปยัง ${profile?.email}`)

  return new Response(
    JSON.stringify({ success: true }),
    { headers: { 'Content-Type': 'application/json' } }
  )
})

ทดสอบบนเครื่องด้วย Hot Reload

supabase functions serve

เซิร์ฟเวอร์ฟังก์ชันจะตรวจสอบการเปลี่ยนแปลงไฟล์และโหลดซ้ำโดยอัตโนมัติ ทดสอบมัน:

curl -X POST http://localhost:54321/functions/v1/send-welcome-email \
  -H "Authorization: Bearer YOUR_ANON_KEY" \
  -H "Content-Type: application/json" \
  -d '{"user_id": "00000000-0000-0000-0000-000000000001"}'

นำขึ้นสู่ Production

# นำฟังก์ชันเดียวขึ้นไป
supabase functions deploy send-welcome-email

# นำฟังก์ชันทั้งหมดขึ้นไป
supabase functions deploy

เทคนิคขั้นสูงและแนวทางที่ได้รับการพิสูจน์แล้ว

การจัดการความลับ

อย่าฮาร์ดโค้ดคีย์ API ในฟังก์ชันของคุณเด็ดขาด ใช้ความลับ:

# ตั้งค่าความลับสำหรับ Production
supabase secrets set RESEND_API_KEY=re_xxx STRIPE_KEY=sk_live_xxx

# แสดงรายการความลับทั้งหมด
supabase secrets list

# ลบความลับ
supabase secrets unset STRIPE_KEY

เข้าถึงในฟังก์ชัน:

const resendKey = Deno.env.get('RESEND_API_KEY')
// ไม่ควรทำ: const resendKey = 're_xxx'

การแยกสาขาฐานข้อมูล

กำลังทำงานกับการเปลี่ยนแปลง Schema ครั้งใหญ่ใช่หรือไม่? สร้างสาขาที่แยกออกมา:

supabase branches create feature-payments
supabase branches switch feature-payments

# ทำการเปลี่ยนแปลง, ทดสอบ, จากนั้นผสาน
supabase branches merge feature-payments

สิ่งนี้ช่วยให้ฐานข้อมูลสำหรับการพัฒนาหลักของคุณสะอาดในขณะที่คุณทดลอง

ข้อผิดพลาดทั่วไปที่ควรหลีกเลี่ยง

การแก้ไขฐานข้อมูลโดยตรงใน Studio ใช้ migrations เสมอ การแก้ไขโดยตรงไม่ถูกติดตามและเพื่อนร่วมทีมของคุณจะไม่มี

การคอมมิตไฟล์ .env ใช้ supabase secrets set สำหรับ Production เพิ่ม .env* ใน .gitignore ของคุณ

การข้าม supabase db reset หลังจากดึงข้อมูล เมื่อคุณดึงการเปลี่ยนแปลงของเพื่อนร่วมทีม migrations ใหม่ของพวกเขาต้องรันในเครื่อง รีเซ็ตเพื่อนำไปใช้

ไม่สร้าง types ใหม่หลังการเปลี่ยนแปลง Schema TypeScript types ของคุณล้าสมัยทันทีที่คุณเพิ่มคอลัมน์ ทำให้การสร้างประเภทข้อมูลเป็นส่วนหนึ่งของเวิร์กโฟลว์การ migration ของคุณ

การนำฟังก์ชันขึ้นไปโดยไม่มีการทดสอบในเครื่อง รัน supabase functions serve และทดสอบด้วยคำขอจริงเสมอก่อนนำไปใช้งาน

การใช้ service role key ในโค้ดฟรอนต์เอนด์ service role key ข้าม RLS มันควรอยู่ใน Edge Functions และโค้ดฝั่งเซิร์ฟเวอร์เท่านั้น ไม่เคยอยู่ในเบราว์เซอร์ของคุณ

เคล็ดลับประสิทธิภาพ

# ข้ามบริการที่คุณไม่ต้องการเพื่อประหยัดหน่วยความจำ
supabase start --exclude-studio --exclude-inbucket

# ตรวจสอบว่าอะไรกำลังใช้ทรัพยากร
docker stats

ทางเลือกและการเปรียบเทียบ

คุณสมบัติ	Supabase CLI	Firebase CLI	PlanetScale CLI
ฐานข้อมูลในเครื่อง	PostgreSQL เต็มรูปแบบ	เฉพาะ Emulator	เฉพาะคลาวด์
Migrations	ไฟล์ SQL ใน Git	ไม่มีการรองรับแบบ Native	การแยกสาขา
ฟังก์ชัน Edge	Deno runtime	Cloud Functions	ไม่รวม
การยืนยันตัวตนในเครื่อง	GoTrue เต็มรูปแบบ	Emulator	ไม่รวม
โอเพนซอร์ส	เปิดเต็มที่	กรรมสิทธิ์	กรรมสิทธิ์
การสร้างประเภทข้อมูล	มีมาให้ในตัว	ด้วยตนเอง	ด้วยตนเอง

Emulator ในเครื่องของ Firebase เหมาะสำหรับการสร้างต้นแบบอย่างรวดเร็ว แต่ไม่ได้ให้อินสแตนซ์ PostgreSQL จริงแก่คุณ รูปแบบการแยกสาขาของ PlanetScale นั้นยอดเยี่ยมสำหรับการเปลี่ยนแปลง Schema แต่คุณจะทำงานกับระบบคลาวด์เสมอ Supabase CLI เป็นผู้ชนะสำหรับทีมที่ต้องการประสบการณ์การพัฒนาในเครื่องแบบโอเพนซอร์สเต็มรูปแบบและเป็น PostgreSQL-native

กรณีการใช้งานจริง

แอปพลิเคชัน SaaS ที่มีข้อมูลแบบหลายผู้เช่า สตาร์ทอัพด้านเทคโนโลยีทางการเงินจัดการ 47 migrations ในสามสภาพแวดล้อม (dev, staging, prod) RLS policies ได้รับการทดสอบบนเครื่องด้วยบทบาทผู้ใช้ที่แตกต่างกันก่อนที่โค้ดจะถึง Production ผลลัพธ์: ไม่มีเหตุการณ์ Production ที่เกี่ยวข้องกับ Schema เป็นเวลาหกเดือน

การประมวลผลคำสั่งซื้ออีคอมเมิร์ซ ทีมอีคอมเมิร์ซใช้ Edge Functions สำหรับการประมวลผล Stripe webhook พวกเขาทดสอบ webhook payloads บนเครื่องโดยใช้ supabase functions serve กับเหตุการณ์ทดสอบ Stripe จริง เวลาในการนำขึ้นสู่ระบบลดลงจาก 2 ชั่วโมงเหลือ 15 นาที

แบ็กเอนด์ของแอปมือถือ ทีม React Native สร้าง TypeScript types หลังทุก migration และแชร์เป็นแพ็กเกจ npm ภายใน ฟรอนต์เอนด์และแบ็กเอนด์ซิงค์กันโดยอัตโนมัติ ไม่มีคำถาม "เอนด์พอยต์นี้คืนค่าฟิลด์อะไรบ้าง?" ใน Slack อีกต่อไป

สรุป

นี่คือสิ่งที่คุณสามารถทำได้ตอนนี้:

ตั้งค่าสภาพแวดล้อม Supabase ในเครื่องได้อย่างสมบูรณ์ในไม่กี่นาที
ใช้ migrations เพื่อควบคุมเวอร์ชันของการเปลี่ยนแปลง Schema ทุกครั้ง
ทดสอบฟังก์ชัน Edge บนเครื่องด้วย hot reload
สร้าง TypeScript types โดยอัตโนมัติจาก Schema ของคุณ
นำขึ้นสู่ Production ด้วย supabase db push และ supabase functions deploy
ทดสอบ API ของคุณด้วย Apidog ก่อนนำขึ้นสู่ Production

เวิร์กโฟลว์นี้ให้ผลตอบแทนทันที ทีมของคุณนำส่งได้เร็วขึ้น พบข้อผิดพลาดได้เร็วขึ้น และจะไม่พบปัญหา schema drift อีกต่อไป

ขั้นตอนต่อไปของคุณ:

ติดตั้ง: brew install supabase/tap/supabase
รัน supabase init ในโปรเจกต์ของคุณ
สร้าง migration แรกของคุณ
ตั้งค่า Apidog เพื่อทดสอบเอนด์พอยต์ในเครื่องของคุณ
นำขึ้นสู่ Production ด้วยความมั่นใจ

ทดสอบ Supabase API ของคุณด้วย Apidog - ฟรี

ปุ่ม

คำถามที่พบบ่อย

ฉันจำเป็นต้องใช้ Docker เพื่อใช้ Supabase CLI หรือไม่?ใช่ Docker Desktop ต้องทำงานอยู่ก่อน supabase start CLI ใช้ Docker Compose เพื่อรันสแต็กเต็มรูปแบบบนเครื่อง หาก Docker ไม่ทำงาน คุณจะได้รับข้อผิดพลาด "Cannot connect to Docker daemon"

ฉันจะซิงค์ฐานข้อมูลในเครื่องของฉันกับ Production ได้อย่างไร?ใช้ supabase db pull เพื่อสร้าง migration จาก remote schema ของคุณ จากนั้น supabase db push เพื่อนำ local migrations ไปใช้กับ Production รัน supabase db reset บนเครื่องหลังจากดึงข้อมูล เพื่อให้แน่ใจว่าสภาพแวดล้อมของคุณตรงกัน

ฉันสามารถใช้ Supabase CLI โดยไม่มีบัญชี Supabase Cloud ได้หรือไม่?ใช่ คุณสามารถใช้ CLI ในเครื่องทั้งหมดสำหรับการพัฒนาโดยไม่มีบัญชีคลาวด์ได้ คุณต้องการเพียง supabase login และ supabase link เมื่อคุณพร้อมที่จะนำขึ้นสู่ Production

ฉันจะจัดการกับข้อขัดแย้งในการ migration ในทีมได้อย่างไร?ดึงการเปลี่ยนแปลง Git ล่าสุดและรัน supabase db reset ก่อนสร้าง migrations ใหม่ ใช้ชื่อ migration ที่สื่อความหมาย และสื่อสารกับทีมของคุณเมื่อทำการเปลี่ยนแปลง Schema ที่อาจก่อให้เกิดปัญหา

ความแตกต่างระหว่าง supabase db push และ supabase migration up คืออะไร?supabase migration up นำ migrations ที่รอดำเนินการไปใช้กับฐานข้อมูลในเครื่องของคุณ supabase db push นำไปใช้กับโปรเจกต์ระยะไกล (Production) ของคุณ ทดสอบในเครื่องก่อนเสมอ

ฉันสามารถใช้ Supabase CLI กับโปรเจกต์ที่มีอยู่ได้หรือไม่?ใช่ รัน supabase link --project-ref YOUR_PROJECT_ID เพื่อเชื่อมโยงกับโปรเจกต์ที่มีอยู่ จากนั้น supabase db pull เพื่อสร้าง migrations จาก remote schema ปัจจุบันของคุณ

ฉันจะทดสอบ RLS policies ในเครื่องได้อย่างไร?ใช้ Supabase Studio ที่ http://localhost:54323 เพื่อสลับระหว่างบทบาทผู้ใช้ หรือทดสอบผ่าน API ด้วยโทเค็น JWT ที่แตกต่างกัน Apidog ทำให้สิ่งนี้ง่ายขึ้น: สร้างสภาพแวดล้อมหลายอันด้วยโทเค็นผู้ใช้ที่แตกต่างกัน และรันคำขอเดียวกันในฐานะผู้ใช้ที่แตกต่างกัน

Supabase CLI ฟรีหรือไม่?ใช่ CLI ฟรีและเป็นโอเพนซอร์ส การพัฒนาในเครื่องไม่มีค่าใช้จ่าย คุณจ่ายค่าทรัพยากร Supabase Cloud เมื่อคุณนำขึ้นสู่ Production เท่านั้น