คู่มือโฮสต์เว็บ Static (Hugo/Jekyll) ฟรีบน DigitalOcean 2026

A practical guide to hosting free static sites built with Hugo or Jekyll on DigitalOcean App Platform, covering GitHub deployment, custom domains, SSL, and the free tier's real limits.

เว็บไซต์แบบ Static เช่นบล็อกที่สร้างด้วย Hugo หรือ Jekyll ไม่จำเป็นต้องมีเซิร์ฟเวอร์ประมวลผลตลอดเวลา และ DigitalOcean App Platform เปิดให้โฮสต์เว็บลักษณะนี้ได้ฟรีสูงสุด 3 apps ต่อบัญชี พร้อม SSL อัตโนมัติ บทความนี้อธิบายขั้นตอนตั้งแต่เตรียมโปรเจกต์ เชื่อมต่อ GitHub ไปจนถึงข้อจำกัดที่ควรรู้ก่อนใช้งานจริง

Static Site คืออะไร เหมาะกับใคร

เว็บไซต์แบบ Static คือเว็บที่ไฟล์ HTML, CSS และ JavaScript ถูกสร้างไว้ล่วงหน้าทั้งหมดตั้งแต่ขั้นตอน build ต่างจากเว็บแบบ Dynamic อย่าง WordPress หรือแอปที่เขียนด้วย PHP/Node.js ที่ต้องมีเซิร์ฟเวอร์ประมวลผลและดึงข้อมูลจากฐานข้อมูลทุกครั้งที่มีคนเข้าชม เครื่องมือสร้างเว็บ Static ที่ได้รับความนิยม ได้แก่ Hugo (เขียนด้วย Go เน้นความเร็วในการ build) และ Jekyll (เขียนด้วย Ruby ผูกกับ GitHub Pages มานาน) รวมถึงตัวอื่นอย่าง Eleventy, Astro หรือการ export หน้าเว็บจาก Next.js แบบ Static Export หลักการทำงานคือ นักพัฒนาจะเขียนเนื้อหาด้วยไฟล์ Markdown ผสมกับ Template แล้วรันคำสั่ง build เช่น hugo --minify สำหรับ Hugo หรือ bundle exec jekyll build สำหรับ Jekyll เพื่อแปลงไฟล์ทั้งหมดออกมาเป็นโฟลเดอร์ HTML ที่พร้อมเสิร์ฟตรงจาก Web Server หรือ CDN ได้เลย ไม่ต้องมี Runtime ภาษาโปรแกรมมิ่งทำงานอยู่เบื้องหลังขณะเสิร์ฟเว็บ ทำให้โหลดเร็ว ปลอดภัยกว่า (ไม่มีฐานข้อมูลให้โดนโจมตี) และโฮสต์ได้ในต้นทุนต่ำมากหรือฟรี เว็บที่เหมาะกับสถาปัตยกรรมนี้คือ บล็อกส่วนตัว เว็บเอกสารทางเทคนิค (Documentation) เว็บพอร์ตโฟลิโอ หน้า Landing Page ของสินค้า เว็บของทีมโอเพนซอร์ส หรือเว็บบริษัทขนาดเล็กที่เนื้อหาไม่เปลี่ยนบ่อย เพราะทุกครั้งที่ต้องการอัปเดตเนื้อหา นักพัฒนาต้องแก้ไฟล์ Markdown แล้ว build ใหม่ ซึ่งเหมาะกับทีมที่คุ้นเคยกับ Git workflow อยู่แล้ว ในทางกลับกัน เว็บที่ไม่เหมาะกับ Static Site ได้แก่ ระบบที่ต้องมีการประมวลผลแบบ Real-time เช่น ระบบตะกร้าสินค้าที่เช็คสต๊อกสด ระบบสมาชิกที่ต้อง Login แสดงข้อมูลเฉพาะบุคคล หรือแอปที่ต้องเขียนข้อมูลกลับเข้าฐานข้อมูลบ่อยๆ กรณีเหล่านี้ต้องใช้สถาปัตยกรรมแบบ Dynamic หรืออย่างน้อยต้องมี Backend API แยกต่างหากมารองรับ ซึ่งบน DigitalOcean สามารถใช้ App Platform แบบ Service หรือ Droplet แยกได้

A static website is one where HTML, CSS, and JavaScript files are pre-built entirely at the build stage, unlike dynamic sites like WordPress or apps written in PHP/Node.js that require a server to process requests and fetch data from a database every time someone visits. Popular static site generators include Hugo (written in Go and focused on fast builds) and Jekyll (written in Ruby and long integrated with GitHub Pages), plus others like Eleventy, Astro, or static exports from Next.js. The workflow is that developers write content in Markdown files mixed with templates, then run build commands like hugo --minify for Hugo or bundle exec jekyll build for Jekyll to convert everything into an HTML folder ready to serve directly from a web server or CDN. No programming runtime needs to run in the background while serving the site, making it faster, more secure (no database to attack), and cheap or free to host. Sites suited to this architecture include personal blogs, technical documentation sites, portfolio websites, product landing pages, open-source team sites, or small business sites where content doesn't change often. Each time you need to update content, developers must edit the Markdown files and rebuild, which works well for teams already familiar with Git workflows. Conversely, sites unsuitable for static hosting include systems needing real-time processing—shopping carts with live stock checks, member systems requiring login with personalized data, or apps that frequently write data back to a database. These need dynamic architecture or at least a separate backend API, which on DigitalOcean can be handled with App Platform Services or separate Droplets.

1. Static Site: ไฟล์ HTML/CSS/JS ถูก build ไว้ล่วงหน้า ไม่มี Runtime ประมวลผลขณะเสิร์ฟ
2. Hugo ใช้ภาษา Go เน้นความเร็วในการ build; Jekyll ใช้ Ruby ผูกกับ GitHub Pages มานาน
3. เหมาะกับบล็อก เอกสารเทคนิค พอร์ตโฟลิโอ และ Landing Page ที่เนื้อหาไม่เปลี่ยนบ่อย
4. ไม่เหมาะกับระบบที่ต้องมี Database แบบ Real-time หรือระบบสมาชิก Login

App Platform Free Tier: 3 apps static site ฟรี

จากการรีวิวหลายรอบ digitalOcean App Platform เป็นบริการ PaaS (Platform-as-a-Service) ที่ให้ผู้ใช้เชื่อมต่อ Repository จาก GitHub, GitLab หรือ Docker Registry แล้วปล่อยให้ระบบ build และ deploy ให้อัตโนมัติ โดยเฉพาะสำหรับเว็บ Static Site แผนฟรีของ App Platform ให้สร้างได้สูงสุด 3 apps ต่อบัญชี และแต่ละ app จะได้โควตา Bandwidth ฟรี 1 GiB ต่อเดือน ซึ่งเพียงพอสำหรับบล็อกหรือเว็บพอร์ตโฟลิโอที่มีผู้เข้าชมไม่มาก สิ่งสำคัญที่ต้องเข้าใจคือแผนฟรีนี้ใช้ได้เฉพาะประเภท Static Site เท่านั้น หากต้องการรันแอปที่มี Backend ประมวลผล (เช่น Node.js server, Python API) จะต้องเลือกแผนแบบ Container ซึ่งเริ่มต้นที่ $5 ต่อเดือนสำหรับสเปก Shared 1 vCPU/512 MiB RAM รองรับ Transfer 50 GiB ต่อเดือน ไล่ระดับขึ้นไปตามขนาดที่ต้องการ แต่สำหรับ Static Site อย่างเว็บที่ build ด้วย Hugo หรือ Jekyll ไม่จำเป็นต้องจ่ายเลยตราบใดที่ไม่เกินโควตา ข้อดีของการใช้ App Platform แทนการโฮสต์ Static Site บน Droplet เองคือไม่ต้องดูแล Web Server (Nginx/Apache) เอง ไม่ต้องต่ออายุใบรับรอง SSL เอง และระบบ build/deploy อัตโนมัติทุกครั้งที่ push โค้ดขึ้น Git repository ต่างจาก Droplet ที่ต้องติดตั้งและดูแล Stack เองทั้งหมด แม้จะยืดหยุ่นกว่าแต่ก็มีค่าใช้จ่ายขั้นต่ำที่ต้องเดินเครื่องตลอดเวลา (Droplet เล็กสุดเริ่มที่ $4 ต่อเดือน สำหรับ 512 MiB RAM) ควรสังเกตด้วยว่าโควตา 3 apps ฟรีนี้นับรวมทุกเว็บ Static ในบัญชีเดียวกัน หากมีโปรเจกต์เกิน 3 เว็บ จะต้องอัปเกรดเป็นแผนเสียเงินสำหรับเว็บที่เกินโควตา หรือรวมหลายเว็บย่อยไว้ใน repository เดียวแล้วจัดการ routing เองก็เป็นอีกทางเลือกหนึ่ง หมายเหตุ: ข้อมูล ณ กรกฎาคม 2026 — ตรวจสอบราคาและโควตาล่าสุดที่เว็บผู้ให้บริการ เนื่องจากแผนราคาอาจมีการปรับเปลี่ยนได้

• Free Tier: สร้างได้สูงสุด 3 apps ประเภท Static Site ต่อบัญชี
• แต่ละ app ได้โควตา Bandwidth ฟรี 1 GiB ต่อเดือน
• แผนแบบ Container (มี Backend) เริ่มต้นที่ $5/เดือน สำหรับ Shared 1vCPU/512MiB/50GiB transfer
• ไม่ต้องดูแล Web Server หรือต่ออายุ SSL เอง ต่างจากโฮสต์บน Droplet

Deploy เว็บ Hugo/Jekyll จาก GitHub

ขั้นตอนการ deploy เว็บ Static เข้า App Platform เริ่มจากการเตรียม Repository บน GitHub ให้มีไฟล์ config ที่ถูกต้อง สำหรับ Hugo ต้องมีไฟล์ config.toml หรือ hugo.toml อยู่ที่ root และสำหรับ Jekyll ต้องมี Gemfile กับ _config.yml ครบถ้วน จากนั้น push โค้ดขึ้น GitHub ให้เรียบร้อยก่อน ในหน้า DigitalOcean Control Panel เลือก Create → Apps แล้วเลือกแหล่งที่มาเป็น GitHub จากนั้นระบบจะขอสิทธิ์เข้าถึง Repository ผ่าน GitHub App เลือก Repository และ Branch ที่ต้องการ (มักเป็น main) App Platform จะพยายามตรวจจับประเภทโปรเจกต์อัตโนมัติ แต่สำหรับ Static Site Generator อย่าง Hugo ควรเลือกประเภท Static Site ด้วยตนเองและระบุคำสั่ง Build กับโฟลเดอร์ Output ให้ถูกต้อง สำหรับ Hugo คำสั่ง Build ที่ใช้บ่อยคือ hugo --minify และโฟลเดอร์ Output คือ public ส่วน Jekyll ใช้คำสั่ง bundle exec jekyll build โดย Output จะอยู่ที่โฟลเดอร์ _site ควรระบุ Environment Variable กำหนดเวอร์ชัน เช่น HUGO_VERSION=0.128.0 เพื่อป้องกันปัญหาเวอร์ชัน Hugo บนระบบ build ไม่ตรงกับที่ใช้พัฒนาในเครื่อง ซึ่งอาจทำให้ layout หรือ shortcode บางตัวพังได้ หลังตั้งค่าครบ กด Next เพื่อดูสรุปแผนราคา (Static Site จะขึ้นเป็น Free อัตโนมัติถ้ายังไม่เกินโควตา) แล้วกด Create Resources ระบบจะเริ่ม Clone โค้ด รันคำสั่ง Build และ deploy ให้อัตโนมัติ ใช้เวลาไม่กี่นาทีขึ้นกับขนาดเว็บ เมื่อเสร็จจะได้ URL ชั่วคราวรูปแบบ your-app-xxxxx.ondigitalocean.app สำหรับทดสอบก่อนผูกโดเมนจริง จุดที่มีประโยชน์มากคือ App Platform จะเชื่อมกับ GitHub แบบ Continuous Deployment ทันที หมายความว่าทุกครั้งที่มีการ push commit ใหม่เข้า Branch ที่เลือกไว้ ระบบจะ build และ deploy เวอร์ชันใหม่ให้อัตโนมัติโดยไม่ต้องสั่งเองซ้ำ เหมาะกับ Workflow เขียนบทความแล้ว push ขึ้นได้ทันที

• เตรียม Repository ให้มี config.toml (Hugo) หรือ Gemfile + _config.yml (Jekyll) ครบ
• Build command: hugo --minify (Output: public/) หรือ bundle exec jekyll build (Output: _site/)
• ตั้ง Environment Variable กำหนดเวอร์ชัน เช่น HUGO_VERSION ป้องกันปัญหาเวอร์ชันไม่ตรงกัน

ตั้งค่า Custom Domain + SSL ฟรี

หลังจากเว็บ deploy สำเร็จบน URL ชั่วคราวของ DigitalOcean แล้ว ขั้นตอนถัดไปคือผูกโดเมนของตัวเองเข้ากับ App โดยเข้าไปที่แท็บ Settings ของ App แล้วเลือก Domains จากนั้นกด Add Domain แล้วกรอกชื่อโดเมน เช่น www.example.com หรือโดเมนแบบ Apex อย่าง example.com ระบบจะแสดงค่า DNS Record ที่ต้องไปตั้งค่าที่ผู้ให้บริการโดเมน (Registrar) หรือ DNS Provider ของตัวเอง โดยทั่วไปหากใช้โดเมนย่อยแบบ www ให้เพิ่ม CNAME Record ชี้ไปยัง URL ของ App Platform ส่วนโดเมน Apex ที่ไม่มี Subdomain มักต้องใช้ A Record ชี้ไปยัง IP ที่ App Platform กำหนดให้ หรือถ้าใช้ DigitalOcean DNS จัดการโดเมนอยู่แล้ว ระบบจะตั้งค่าให้อัตโนมัติเมื่อเลือกโดเมนที่อยู่ในบัญชีเดียวกัน เมื่อ DNS ชี้มาถูกต้องและ Propagate เรียบร้อย (อาจใช้เวลาไม่กี่นาทีถึงไม่กี่ชั่วโมงขึ้นกับค่า TTL เดิม) App Platform จะออกใบรับรอง SSL ให้อัตโนมัติผ่าน Let's Encrypt โดยไม่มีค่าใช้จ่ายเพิ่มเติม และจะต่ออายุใบรับรองให้เองก่อนหมดอายุ ผู้ใช้ไม่ต้องตั้ง Cron Job หรือรัน Certbot เองเหมือนตอนโฮสต์บน Droplet ควรผูกทั้งโดเมน Apex และ www แล้วตั้งค่าใน App Platform ให้ Redirect จากรูปแบบหนึ่งไปยังอีกรูปแบบที่ต้องการใช้เป็นหลัก (Canonical) เพื่อป้องกันปัญหา SEO เรื่องเนื้อหาซ้ำ (Duplicate Content) จากการเข้าถึงเว็บได้สองที่อยู่พร้อมกัน นอกจากนี้หากมีการย้ายโดเมนมาจากผู้ให้บริการเดิม ควรปรับ TTL ของ DNS Record ให้ต่ำลงล่วงหน้าก่อนวันย้ายจริง เพื่อให้การเปลี่ยนแปลงมีผลเร็วขึ้นและลดช่วงเวลาที่เว็บเข้าถึงไม่ได้

1. เพิ่มโดเมนที่แท็บ Settings → Domains แล้วตั้งค่า CNAME/A Record ตามที่ระบบแจ้ง
2. SSL ออกให้อัตโนมัติผ่าน Let's Encrypt ฟรี และต่ออายุให้เองก่อนหมดอายุ
3. ควรตั้ง Redirect ระหว่างโดเมน Apex กับ www ให้เหลือ Canonical เดียว

ข้อจำกัดของ Free Tier

แม้ App Platform Free Tier จะสะดวกและไม่มีค่าใช้จ่าย แต่ก็มีข้อจำกัดที่ควรรู้ก่อนใช้งานจริงเพื่อไม่ให้เว็บล่มกลางคันโดยไม่ทันตั้งตัว ข้อจำกัดแรกคือโควตา Bandwidth 1 GiB ต่อเดือนต่อ App ซึ่งถือว่าน้อยมากหากเว็บมีรูปภาพขนาดใหญ่หรือมีผู้เข้าชมจำนวนมาก เมื่อ Transfer เกินโควตาที่กำหนด จำเป็นต้องอัปเกรดเป็นแผนเสียเงินเพื่อให้เว็บยังใช้งานได้ต่อ ดังนั้นเว็บที่คาดว่าจะมี Traffic สูงควรพิจารณาใช้ Spaces CDN หรือ Cloudflare วางไว้ด้านหน้าเพื่อลดภาระ Bandwidth ที่ตี App Platform โดยตรง ข้อจำกัดที่สองคือจำนวน App สูงสุด 3 apps ต่อบัญชีสำหรับ Static Site ประเภทฟรี หากมีหลายโปรเจกต์มากกว่านั้น ต้องเลือกอัปเกรดบางโปรเจกต์เป็นแผนเสียเงิน หรือรวมหลายเว็บไว้ใน Repository เดียวกันแล้วจัดการ Path Routing เอง ข้อจำกัดที่สามคือ Static Site บน App Platform ไม่รองรับการประมวลผลฝั่ง Server เช่น API Endpoint, Server-side Rendering หรือ Database Connection หากต้องการฟีเจอร์เหล่านี้เพิ่มเติม (เช่น ฟอร์มติดต่อที่ต้องส่งอีเมล หรือระบบค้นหาที่ต้อง Query ฐานข้อมูล) จะต้องแยกไปใช้บริการภายนอกอย่าง Formspree สำหรับฟอร์ม หรือสร้าง Component แบบ Service/Function แยกต่างหากใน App เดียวกัน ซึ่งจะทำให้ App นั้นไม่ใช่ Static Site ฟรีอีกต่อไป ข้อจำกัดสุดท้ายที่มักถูกมองข้ามคือ Build Time และทรัพยากรระหว่าง Build อาจถูกจำกัดในแผนฟรี หากเว็บมีเนื้อหาจำนวนมาก (เช่น บล็อกหลายพันบทความ) เวลา Build อาจนานขึ้นตามสัดส่วน ควรทดสอบเวลา Build จริงก่อนวางใจว่าจะ deploy ผ่านทุกครั้งโดยไม่มีปัญหา และควรตรวจสอบหน้า Billing เป็นระยะเพื่อดูปริมาณ Bandwidth ที่ใช้ไปแล้วเทียบกับโควตา

• Bandwidth ฟรีจำกัดที่ 1 GiB/เดือน/app เว็บที่มีรูปเยอะหรือ Traffic สูงอาจไม่พอ
• จำนวน App ฟรีจำกัดที่ 3 apps ต่อบัญชี
• ไม่รองรับ Backend/API/Database — ต้องแยกใช้บริการภายนอกหรืออัปเกรดแผน

เมื่อไหร่ควรใช้ฟีเจอร์นี้ (Use Case จริง)

App Platform Free Tier สำหรับ Static Site เหมาะกับสถานการณ์ที่มีรูปแบบ Traffic และเนื้อหาค่อนข้างแน่นอน ตัวอย่างการใช้งานจริงที่เหมาะสม ได้แก่ เว็บพอร์ตโฟลิโอส่วนตัวของนักพัฒนาหรือนักออกแบบ ที่มีผู้เข้าชมไม่มากในแต่ละเดือน และต้องการที่อยู่ URL พร้อม SSL แบบมืออาชีพโดยไม่มีค่าใช้จ่าย เอกสารทางเทคนิค (Documentation Site) ของโปรเจกต์โอเพนซอร์สขนาดเล็กถึงกลาง ที่สร้างด้วย Hugo หรือ Jekyll และอัปเดตตามรอบการพัฒนา ซึ่งการ deploy อัตโนมัติผ่าน GitHub ช่วยลดขั้นตอนดูแลได้มาก หน้า Landing Page สำหรับทดสอบไอเดียผลิตภัณฑ์ (MVP) หรือแคมเปญการตลาดระยะสั้น ที่ต้องการเปิดใช้งานเร็วโดยไม่ต้องตั้งเซิร์ฟเวอร์เอง บล็อกส่วนตัวหรือบล็อกทีมขนาดเล็กที่เขียนเนื้อหาเป็นระยะ ไม่ใช่เว็บข่าวที่อัปเดตตลอดเวลาและมีผู้อ่านจำนวนมาก และเว็บสำหรับ Workshop, Hackathon หรือโปรเจกต์ทดลองที่ต้องการพื้นที่โฮสต์ชั่วคราวโดยไม่อยากผูกมัดค่าใช้จ่ายรายเดือน ในทางกลับกัน หากเว็บเริ่มมีผู้เข้าชมจำนวนมากอย่างสม่ำเสมอ มีทีมงานหลายคนต้องการ Preview Environment แยกต่อ Branch จำนวนมาก หรือเป็นเว็บธุรกิจที่ Downtime ส่งผลกระทบโดยตรงต่อรายได้ ควรพิจารณาอัปเกรดเป็นแผนเสียเงินตั้งแต่ต้น หรือเลือกใช้ Droplet ร่วมกับ Nginx และ Cloudflare เพื่อควบคุม Bandwidth และ Caching ได้ละเอียดกว่า ซึ่งให้ความยืดหยุ่นสูงกว่าแต่ต้องแลกกับภาระดูแลระบบเองที่มากขึ้น

• เว็บพอร์ตโฟลิโอ, เอกสารเทคนิคโอเพนซอร์ส, Landing Page ทดสอบไอเดีย
• บล็อกส่วนตัวหรือทีมขนาดเล็กที่อัปเดตเป็นระยะ ไม่ใช่เว็บข่าวปริมาณเข้าชมสูง
• โปรเจกต์ Workshop/Hackathon ที่ต้องการโฮสต์ชั่วคราวไม่ผูกมัดค่าใช้จ่าย

ข้อผิดพลาดที่พบบ่อยและวิธีแก้ไข

ปัญหาที่พบบ่อยที่สุดเมื่อ deploy Static Site บน App Platform คือระบุโฟลเดอร์ Output ผิด เช่น ตั้งเป็น public/ ทั้งที่โปรเจกต์ตั้งค่า Output ไว้เป็นชื่ออื่น หรือกลับกันสำหรับ Jekyll ที่ Output จริงคือ _site แต่ไปตั้งเป็น public ตามความเคยชินจาก Hugo ผลคือ Build สำเร็จแต่หน้าเว็บขึ้น 404 หรือแสดงหน้าว่าง วิธีแก้คือตรวจสอบโฟลเดอร์ Output จริงจากการรัน Build คำสั่งเดียวกันในเครื่องตัวเองก่อน ปัญหาที่สองคือ Baseurl หรือ Path ไม่ตรงกัน โดยเฉพาะ Hugo ที่กำหนดค่า baseURL ใน config.toml ไว้เป็นค่าที่ต่างจาก URL จริงบน App Platform ทำให้ไฟล์ CSS, JavaScript หรือรูปภาพโหลดไม่ขึ้นเพราะ Path อ้างอิงผิด ควรตั้งค่า baseURL ให้ตรงกับโดเมนจริงที่จะใช้ หรือปล่อยว่างแล้วใช้ Relative URL แทนหากต้องการทดสอบหลาย Environment ปัญหาที่สามคือ Jekyll Theme หรือ Gem บางตัวไม่ถูกติดตั้งเพราะไม่ได้ระบุไว้ใน Gemfile ให้ครบ ทำให้ Build ล้มเหลวบนระบบ Cloud ทั้งที่รันได้ปกติในเครื่อง Local ซึ่งมักเกิดจาก Local มี Gem ติดตั้งไว้อยู่แล้วนอกเหนือจากที่ระบุใน Gemfile วิธีแก้คือรัน bundle install และ bundle exec jekyll build ในสภาพแวดล้อมที่สะอาด (เช่น Docker Container ว่างเปล่า) ก่อน push เพื่อยืนยันว่า Dependency ครบจริง ปัญหาที่สี่คือลืมตั้งค่า Environment Variable กำหนดเวอร์ชันของ Hugo หรือ Ruby ทำให้ App Platform ใช้เวอร์ชัน Default ที่อาจต่างจากที่พัฒนาในเครื่อง ส่งผลให้ Syntax หรือ Shortcode บางตัวที่รองรับเฉพาะเวอร์ชันใหม่ทำงานผิดพลาด ควร Pin เวอร์ชันให้ตรงกันทั้งสองฝั่งเสมอ ปัญหาสุดท้ายคือ DNS Propagate ช้าหลังผูกโดเมน ทำให้ผู้ใช้บางคนยังเห็นเว็บเก่าหรือ SSL Error ชั่วคราว ซึ่งเป็นเรื่องปกติของระบบ DNS ทั่วโลก ควรรอให้ครบอย่างน้อย 24 ชั่วโมงก่อนสรุปว่ามีปัญหา และตรวจสอบค่า DNS ด้วยเครื่องมืออย่าง dig หรือ nslookup เพื่อยืนยันว่า Record ที่ตั้งไว้ถูกต้องจริง

• ระบุโฟลเดอร์ Output ผิด (public/ ของ Hugo สลับกับ _site/ ของ Jekyll) ทำให้ 404
• baseURL ใน config.toml ไม่ตรงกับโดเมนจริง ทำให้ CSS/JS โหลดไม่ขึ้น
• Gemfile ของ Jekyll ระบุ Gem ไม่ครบ ทำให้ Build ล้มเหลวบน Cloud ทั้งที่รันได้ใน Local

แนวทางปฏิบัติที่ดีที่สุด (Best Practices)

เพื่อให้การโฮสต์ Static Site บน DigitalOcean App Platform มีเสถียรภาพและควบคุมค่าใช้จ่ายได้ดี มีแนวทางที่ควรทำดังนี้ จัดโครงสร้าง Git Branch ให้ชัดเจน เช่นแยก Branch main สำหรับ Production และใช้ Pull Request หรือ Branch แยกสำหรับทดสอบก่อน Merge เพื่อป้องกันเนื้อหาที่ยังไม่พร้อมถูก Deploy ขึ้นเว็บจริงโดยไม่ตั้งใจ ตั้งค่า Build ให้ Minify ไฟล์เสมอ เช่นใช้ hugo --minify แทน hugo เฉยๆ เพื่อลดขนาดไฟล์ HTML/CSS/JS ที่ต้องส่งออกไป ซึ่งช่วยประหยัดโควตา Bandwidth ฟรีที่มีจำกัดอยู่แล้วได้โดยตรง หมั่นตรวจสอบปริมาณ Bandwidth ที่ใช้ไปในหน้า Insights ของ App เป็นระยะ โดยเฉพาะช่วงที่มีการแชร์เนื้อหาในโซเชียลมีเดียแล้วมีคนเข้าชมพุ่งขึ้นกะทันหัน เพื่อประเมินล่วงหน้าว่าจะต้องอัปเกรดแผนหรือไม่ หากคาดว่า Traffic จะสูงขึ้นเรื่อยๆ ควรพิจารณาวาง Cloudflare (แผนฟรี) ไว้ด้านหน้า App Platform เพื่อ Cache เนื้อหาแบบ Static และลด Request ที่ตีเข้ามาโดยตรง ซึ่งช่วยประหยัดทั้ง Bandwidth และเพิ่มความเร็วให้ผู้ใช้ปลายทางด้วย สำรอง Source Code ไว้ใน Git Repository เสมอ ไม่ควรพึ่งพา App Platform เป็นที่เก็บไฟล์เพียงที่เดียว เพราะ Static Site ทั้งเว็บสร้างขึ้นจาก Repository อยู่แล้ว การมี Backup ที่ดีที่สุดคือ Repository ที่สมบูรณ์และ History การ Commit ที่ครบถ้วน ตั้งค่าไฟล์ robots.txt และ sitemap.xml ให้ Generator สร้างให้อัตโนมัติทุกครั้งที่ Build เพื่อประโยชน์ด้าน SEO และควรทดสอบ Build คำสั่งเดียวกับที่ App Platform ใช้ในเครื่อง Local ก่อน Push ทุกครั้งเพื่อจับข้อผิดพลาดได้ก่อนที่จะเสียเวลารอ Build บน Cloud สุดท้าย หากโปรเจกต์เติบโตจนใกล้โควตาแผนฟรีอย่างสม่ำเสมอ ควรวางแผนงบประมาณล่วงหน้าสำหรับอัปเกรดเป็นแผนเสียเงิน แทนที่จะปล่อยให้เว็บหยุดทำงานกะทันหันเมื่อเกินโควตาโดยไม่ทันตั้งตัว

• แยก Git Branch สำหรับ Production และใช้ Pull Request ก่อน Merge เข้า main
• Build ด้วยคำสั่ง Minify เสมอ (hugo --minify) เพื่อประหยัดโควตา Bandwidth
• ตรวจสอบ Bandwidth ที่ใช้ในหน้า Insights เป็นระยะ โดยเฉพาะช่วง Traffic พุ่ง
• วาง Cloudflare แผนฟรีไว้หน้า App Platform เพื่อ Cache และลด Request ตรง

รับ $200 Free Credit →