ทำเว็บเองไม่ต้องเช่าเซิร์ฟเวอร์แพง! เลือกโฮสต์ฟรีและฐานข้อมูลให้ตรงงาน

* รูปภาพใช้เพื่อประกอบเนื้อหาเท่านั้น อาจไม่ใช่ภาพเหตุการณ์จริงหรือภาพจริงจากเรื่องในบทความ ขอบคุณภาพประกอบจาก https://graphic.in.th

เมื่อก่อนคำว่า “ทำเว็บเอง” มักพ่วงกับค่าเช่าเซิร์ฟเวอร์ ค่าดูแลระบบ และความกังวลว่าจะตั้งค่าอะไรพังหรือไม่ แต่วันนี้คนทำเว็บคนเดียวสามารถแยกชิ้นส่วนระบบไปใช้บริการคลาวด์เฉพาะทางได้ หน้าเว็บอยู่บนโฮสต์แบบส่งไฟล์อัตโนมัติ ส่วนข้อมูลอยู่ในฐานข้อมูลที่มี API และระบบสมาชิกเตรียมไว้แล้ว

สิ่งที่ต้องจำก่อนกดสมัครคือ “ฟรี” ไม่ได้แปลว่าไม่มีเงื่อนไข ค่าโดเมนมักแยกต่างหาก โควตาบางอย่างมีวันหรือมีจำนวน และบริการแต่ละเจ้าถูกออกแบบมาคนละแบบ ถ้าเลือกจากชื่อที่กำลังดังอย่างเดียว เว็บอาจเปิดได้ แต่ไปติดตอนมีคนใช้จริง หรือข้อมูลสำคัญยังไม่มีระบบสำรอง

เริ่มจากวิธีทำเว็บ ไม่ใช่เริ่มจากชื่อโฮสต์

แยกหน้าที่ของระบบ ให้ชัดก่อน จะช่วยลดทั้งค่าใช้จ่ายและความสับสน เว็บที่เป็นหน้าแนะนำร้านหรือพอร์ตโฟลิโออาจไม่ต้องมีฐานข้อมูลเลย แต่เว็บจองคิว ระบบสมาชิก หรือแดชบอร์ดสต๊อกต้องคิดเรื่องข้อมูล สิทธิ์การเข้าถึง และการสำรองตั้งแต่ต้น

• No-code คือประกอบหน้าและแบบฟอร์มด้วยเครื่องมือภาพ เหมาะกับคนที่ต้องการทดสอบไอเดียเร็ว แลกกับการปรับแต่งเชิงลึกและการย้ายระบบที่ทำได้จำกัด

• Low-code คือใช้ส่วนประกอบสำเร็จรูป แล้วเติม workflow, API หรือกฎธุรกิจบางส่วน เหมาะกับร้านค้าและผู้ประกอบการที่อยากได้ระบบเฉพาะตัว แต่ยังไม่อยากดูแลโค้ดทุกบรรทัด

• เขียนเอง ใช้เวลาเรียนรู้มากกว่า แต่ควบคุมหน้าตา โครงสร้างข้อมูล และการเชื่อมบริการได้เต็มที่ เหมาะกับนักพัฒนาอิสระ งานรับจ้าง หรือระบบที่มีโอกาสโต

ทั้งสามแบบไม่ได้แบ่งเป็นฝ่ายถูกกับฝ่ายผิด วิธีที่คุ้มมักเป็นการเริ่มจากหน้าเล็กๆ ก่อน แล้วค่อยเขียนเฉพาะส่วนที่ธุรกิจต้องการจริง เช่น ใช้ตัวสร้างฟอร์มช่วยทำต้นแบบ แต่เขียนกฎป้องกันการจองเวลาซ้ำเอง

พิกัดโฮสต์หน้าเว็บที่ควรลอง

Cloudflare Pages เหมาะกับเว็บ static หรือเว็บที่ build จาก Git แล้วปล่อยขึ้น CDN เพราะคำขอไฟล์ static บนเอกสารทางการระบุว่าใช้ฟรีและไม่จำกัด ส่วน Pages Functions จะนับรวมกับโควตา Workers Free ที่ 100,000 คำขอต่อวัน จึงเหมาะกับ landing page, เว็บเอกสาร, เครื่องมือคำนวณ และ API เล็กๆ ที่ไม่ได้ประมวลผลหนัก

Vercel ใช้งานสะดวกมากสำหรับโปรเจกต์สาย Next.js และ workflow ที่ต้องการ preview ทุกครั้งที่ push โค้ด แผน Hobby มีโควตาหลายรายการ เช่น Edge Requests สูงสุด 1 ล้านคำขอ และ deploy ได้ 100 ครั้งต่อวันตามหน้าข้อมูลแผน แต่มีเงื่อนไขสำคัญว่าแผนนี้จำกัดการใช้งานแบบไม่ใช่เชิงพาณิชย์และเพื่อการใช้งานส่วนตัว ดังนั้นพอร์ตโฟลิโอหรือโปรเจกต์ทดลองใช้ได้ ส่วนเว็บร้านที่รับเงินจริงหรืองานลูกค้าต้องตรวจแผนเชิงพาณิชย์และค่าใช้จ่ายให้ตรงเงื่อนไข

จุดแข็งของโฮสต์กลุ่มนี้คือไม่ต้องเช่าเครื่องทั้งก้อน ผู้ใช้เชื่อม Git repository, กำหนดคำสั่ง build แล้วระบบจัดการ HTTPS, deploy และ cache ให้ แต่ก็ไม่ได้หมายความว่าไม่ต้องดูแลอะไรเลย: ควรแยกคีย์ลับออกจากโค้ด ตั้งค่า environment variables และดู log เมื่อ build หรือ API ผิดพลาด

ฐานข้อมูลฟรี เลือกตามสิ่งที่ต้องใช้

Supabase เหมาะกับคนที่อยากได้มากกว่าฐานข้อมูล เพราะรวม Postgres, ระบบล็อกอิน, ที่เก็บไฟล์, Realtime และ Edge Functions ไว้ในแพลตฟอร์มเดียว แผน Free ให้ฐานข้อมูล 500 MB ต่อโปรเจกต์, file storage 1 GB, ผู้ใช้ที่เข้าสู่ระบบต่อเดือน 50,000 ราย และ Edge Function 500,000 ครั้ง พร้อมสิทธิ์สร้างโปรเจกต์ที่ใช้งานอยู่ได้ 2 โปรเจกต์ จุดที่ต้องรู้คือโปรเจกต์ฟรีจะถูกพักหลังไม่มีการใช้งาน 1 สัปดาห์ ไม่มี automatic backup และไม่มี custom domain ในแผนนี้

Neon เหมาะเมื่อโจทย์คือ PostgreSQL เป็นหลัก ไม่ต้องการ Auth หรือ Storage ที่รวมมาให้ แผน Free ระบุ 100 โปรเจกต์, 100 CU-hours ต่อโปรเจกต์ต่อเดือน, พื้นที่ 0.5 GB ต่อโปรเจกต์ และ egress 5 GB โดย compute ลดลงเป็นศูนย์เมื่อไม่มีการใช้งาน จึงดีสำหรับฐานข้อมูลทดลอง, preview environment และโปรเจกต์ที่เปิดใช้เป็นช่วงๆ แต่ต้องเตรียมบริการส่วนอื่นเอง

ถ้าทำแอปที่ผูกกับบริการ Google อยู่แล้ว Firebase เป็นอีกทางเลือกที่น่าสนใจ แผน Spark ไม่ต้องใส่ข้อมูลการชำระเงินเพื่อเริ่มใช้บริการส่วนใหญ่ และมีโควตาฟรีของ Firestore, Hosting และ Storage แต่โควตาของแต่ละบริการไม่เหมือนกัน เช่น ตัวอย่างในเอกสารระบุ Firestore 50,000 reads และ 20,000 writes ต่อวัน เมื่อใช้เกินโควตาของบริการนั้นบน Spark การใช้งานส่วนนั้นจะถูกหยุดจนกว่าจะขึ้นรอบใหม่ การผูก Cloud Billing ยังทำให้โปรเจกต์เปลี่ยนเป็น Blaze แบบจ่ายตามการใช้ จึงต้องอ่านหน้าบิลให้ละเอียด

สูตรเริ่มต้นสำหรับเว็บจองคิวร้านเล็ก

สมมติอยากทำระบบให้ร้านตัดผม ร้านนวด หรือคลินิกเล็กๆ ลูกค้าเปิดเว็บ เลือกบริการ เลือกช่วงเวลา กรอกเบอร์โทร แล้วร้านเห็นคิวในหน้าจัดการ สูตรเริ่มต้นที่เข้าใจง่ายคือวางหน้าเว็บบน Cloudflare Pages แล้วใช้ Supabase เก็บตารางบริการ ช่วงเวลา ลูกค้า และสถานะการจอง

ก่อนเขียนหน้าสวย ให้กำหนดกติกาข้อมูลก่อน เช่น หนึ่งช่วงเวลาจองได้กี่คน ใครแก้ไขคิวได้ เมื่อยกเลิกจะคืนเวลาหรือไม่ และ...เห็นข้อมูลส่วนตัวแค่ไหน ถ้าใช้ Supabase ควรออกแบบสิทธิ์ด้วย Row Level Security ไม่เปิดตารางให้คนภายนอกอ่านทั้งหมด และให้เซิร์ฟเวอร์ตรวจซ้ำอีกครั้งก่อนบันทึก เพื่อป้องกันลูกค้าสองคนกดช่วงเดียวกันพอดี ค่าโฮสต์อาจเป็นศูนย์ แต่ค่าข้อความแจ้งเตือน โดเมน หรือบริการชำระเงินอาจมีค่าใช้จ่ายแยก

คำว่า “ฟรี” จบตรงไหน

• โดเมน: ลิงก์เริ่มต้นของแพลตฟอร์มมีให้ แต่ชื่อร้านแบบมืออาชีพมักต้องจดเอง

• โควตาและการพักระบบ: ตรวจจำนวนคำขอ พื้นที่ การส่งข้อมูล และเงื่อนไข sleep หรือ pause เพราะเว็บทดสอบกับเว็บที่ลูกค้าใช้ทุกวันมีความต้องการไม่เหมือนกัน

• ความปลอดภัย: อย่าใส่ secret key ใน JavaScript ฝั่งผู้ใช้ ใช้สิทธิ์แยกตามบทบาท จำกัดข้อมูลที่ API เปิดเผย และเปิดการยืนยันตัวตนที่เหมาะสม

• การกู้คืน: ฐานข้อมูลฟรีอาจไม่มี backup อัตโนมัติ ต้องวางแผน export หรือสำรองเอง และทดลองกู้คืน ไม่ใช่แค่มีไฟล์สำรองแล้วถือว่าปลอดภัย

• ค่าใช้จ่ายพุ่ง: ระบบที่เปิดจ่ายตามการใช้ต้องมีแจ้งเตือน ดู usage และกำหนดขีดจำกัดเท่าที่ทำได้ โดยเฉพาะเมื่อเปิด public API หรือรับไฟล์จากผู้ใช้

วิธีเริ่มที่ปลอดภัยคือทำแผนผังสั้นๆ ว่า “หน้าเว็บอยู่ที่ไหน ข้อมูลอยู่ที่ไหน ใครเรียก API ได้ และถ้าโควตาเต็มจะเกิดอะไรขึ้น” จากนั้นสร้างต้นแบบด้วยข้อมูลปลอมก่อน เมื่อ workflow ทำงานค่อยนำข้อมูลจริงเข้าและค่อยขยับแพ็กเกจตามการใช้งาน ไม่จำเป็นต้องจ่ายค่าเครื่องระดับองค์กรตั้งแต่วันแรก แต่ก็ไม่ควรเอาคำว่าโฮสต์ฟรีไปแทนคำว่าแผนสำรอง ความปลอดภัย และความรับผิดชอบต่อข้อมูลของลูกค้า

ข้อดีของเครื่องมือยุคนี้ไม่ใช่แค่ลดค่าเซิร์ฟเวอร์ แต่คือเปิดโอกาสให้คนหนึ่งคนทดสอบไอเดียได้เร็วขึ้น คุณอาจเริ่มจากเว็บหน้าเดียว ต่อฐานข้อมูลเล็กๆ แล้วค่อยเพิ่มสมาชิก แดชบอร์ด และระบบแจ้งเตือนเมื่อเห็นว่ามีคนใช้จริง

เลือกจากลักษณะงานเป็นหลัก: เว็บเนื้อหาเลือกโฮสต์ static, งานที่ต้องการ Auth และ Storage เลือก backend แบบครบชุด, ฐานข้อมูลอย่างเดียวเลือก PostgreSQL ที่แยกบริการ และถ้าเป็นธุรกิจอย่าลืมตรวจสิทธิ์การใช้งานของแผนฟรีกับนโยบายข้อมูลก่อนเปิดรับลูกค้าจริง ต้นทุนเริ่มต้นอาจต่ำมาก แต่ความน่าเชื่อถือจะเกิดจากการออกแบบระบบให้รู้ขีดจำกัดของตัวเอง