คู่มือ Deploy Next.js บน DigitalOcean App Platform 2026

A practical guide to deploying Next.js applications on DigitalOcean App Platform, covering build configuration, environment variables, custom domains, and ISR caching considerations.

App Platform ของ DigitalOcean เป็นทางเลือกที่ทำให้ deploy Next.js ได้เร็วโดยไม่ต้องจัดการ server เอง แต่ Next.js มีหลายโหมด render ทั้ง static, SSR และ ISR ซึ่งแต่ละแบบต้องตั้งค่า build/run command และเลือก component type บน App Platform ต่างกัน บทความนี้เจาะเฉพาะรายละเอียดการ deploy Next.js โดยตรง ตั้งแต่ build command, environment variables, ราคาแผนต่าง ๆ ไปจนถึงข้อผิดพลาดที่พบบ่อยและวิธีแก้ไข

App Platform คืออะไร ต่างจาก Droplet ยังไง

App Platform คือบริการ Platform-as-a-Service (PaaS) ของ DigitalOcean ที่ออกแบบมาให้ deploy แอปพลิเคชันจาก source code ได้โดยไม่ต้องจัดการ server เอง ต่างจาก Droplet ซึ่งเป็น Infrastructure-as-a-Service (IaaS) — ผู้ใช้ต้องสร้าง virtual machine เอง ติดตั้ง Node.js, ตั้งค่า process manager อย่าง PM2, วาง Nginx เป็น reverse proxy และขอใบรับรอง SSL ด้วยตัวเอง สำหรับ Next.js โดยเฉพาะ ความแตกต่างนี้สำคัญมาก เพราะ Next.js รองรับหลายโหมด render ได้แก่ static site generation (SSG), server-side rendering (SSR), และ incremental static regeneration (ISR) — แต่ละโหมดต้องการ runtime ที่ต่างกัน เมื่อ push repo ที่มี package.json ระบุ dependency "next" ขึ้น GitHub และเชื่อมกับ App Platform ระบบจะตรวจจับ framework อัตโนมัติผ่าน Cloud Native Buildpacks แล้วเสนอ component type ให้เหมาะสม ถ้าแอปมีเฉพาะหน้า static ล้วน ๆ (ไม่มี API route หรือ SSR) สามารถ deploy เป็น "Static Site" component ซึ่งอยู่ใน free tier ได้ แต่ถ้าแอปมี API route, getServerSideProps, หรือ ISR ที่ต้อง revalidate on-demand จำเป็นต้องใช้ "Service" (Web Service) component ซึ่งรัน process Node.js ค้างไว้ตลอดเวลาเพื่อรอรับ request — component ประเภทนี้เป็น paid เท่านั้น ไม่มี free tier ข้อดีของ App Platform คือไม่ต้อง patch OS เอง ไม่ต้องตั้งค่า firewall เอง เพราะ DO จัดการ TLS termination, load balancing และ auto-restart เมื่อ process crash ให้อัตโนมัติ แลกกับความยืดหยุ่นที่น้อยกว่า Droplet เช่น ไม่สามารถ SSH เข้าไปแก้ config ระดับ OS หรือติดตั้ง custom Nginx module ได้ สำหรับทีมที่ต้องการ deploy Next.js เร็ว โฟกัสที่โค้ดมากกว่า infrastructure และไม่ได้มี traffic สูงมากจนต้อง fine-tune ทุกชั้นของ stack เอง App Platform จึงเหมาะสมกว่า Droplet อย่างชัดเจน

App Platform is DigitalOcean's Platform-as-a-Service (PaaS) offering designed to deploy applications from source code without managing servers yourself. It differs fundamentally from Droplets, which are Infrastructure-as-a-Service (IaaS) — users must create a virtual machine, install Node.js, configure a process manager like PM2, set up Nginx as a reverse proxy, and request SSL certificates manually. For Next.js specifically, this distinction matters significantly because Next.js supports multiple rendering modes: static site generation (SSG), server-side rendering (SSR), and incremental static regeneration (ISR) — each requiring different runtime environments. When you push a repository with a package.json specifying the "next" dependency to GitHub and connect it to App Platform, the system automatically detects the framework via Cloud Native Buildpacks and suggests an appropriate component type. If your app contains only static pages (no API routes or SSR), you can deploy it as a "Static Site" component, which qualifies for the free tier. However, if your app has API routes, getServerSideProps, or ISR with on-demand revalidation, you must use a "Service" (Web Service) component that keeps a Node.js process running continuously to handle requests — this component type is always paid; there is no free tier. App Platform's advantages include no need to patch the OS yourself, no firewall configuration required, because DigitalOcean handles TLS termination, load balancing, and automatic restarts when processes crash. In exchange, you have less flexibility than Droplets — you cannot SSH in to tweak OS-level configs or install custom Nginx modules. For teams wanting to deploy Next.js quickly, focus on code over infrastructure, and don't have extremely high traffic requiring deep stack tuning, App Platform is clearly the better choice than Droplets.

• App Platform = PaaS (managed), Droplet = IaaS (จัดการเอง)
• Static Site component รองรับ SSG/static export เท่านั้น อยู่ใน free tier ได้
• Web Service component จำเป็นสำหรับ SSR/API route/ISR — paid เท่านั้น

เชื่อม GitHub Repo กับ App Platform

ที่พบบ่อยในทางปฏิบัติ — การเชื่อม Next.js project กับ App Platform เริ่มจากหน้า cloud.digitalocean.com/apps แล้วกด Create App จากนั้นเลือก source เป็น GitHub (รองรับ GitLab และ Docker Hub ด้วย แต่ workflow ที่พบบ่อยที่สุดสำหรับ Next.js คือ GitHub) หากยังไม่เคยเชื่อมบัญชีมาก่อน ระบบจะพาไปติดตั้ง DigitalOcean GitHub App ซึ่งต้อง authorize สิทธิ์เข้าถึง repository ที่ต้องการ deploy โดยเลือกได้ทั้งแบบ "All repositories" หรือเจาะจงเฉพาะ repo เดียวเพื่อความปลอดภัย หลัง authorize แล้ว เลือก repository และ branch ที่จะ deploy (ปกติคือ main หรือ production) ถ้าโปรเจกต์เป็น monorepo ที่มี Next.js app อยู่ใน subfolder เช่น apps/web ต้องระบุ Source Directory ให้ตรงตำแหน่ง ไม่เช่นนั้น buildpack จะหา package.json ไม่เจอที่ root แล้ว build fail ขั้นตอนถัดมา App Platform จะสแกน repo เพื่อ detect framework — เมื่อเจอ next ใน dependencies ของ package.json ระบบจะเสนอ component type และ default build/run command ให้อัตโนมัติ ผู้ใช้ตรวจสอบและแก้ไขได้ก่อนกด deploy จริง มีตัวเลือกสำคัญคือ Autodeploy — ถ้าเปิดไว้ ทุกครั้งที่ push commit ใหม่ขึ้น branch ที่เลือก App Platform จะ trigger build และ deploy ให้อัตโนมัติ คล้ายกับ CI/CD workflow ที่เขียน GitHub Actions เอง แต่ App Platform จัดการ pipeline นี้ให้ในตัว เหมาะกับทีมขนาดเล็กถึงกลางที่ไม่อยากดูแล pipeline แยกต่างหาก ส่วนทีมที่ต้องการควบคุม deploy step เพิ่มเติม เช่นรัน test suite ก่อน deploy จริง สามารถปิด autodeploy แล้วใช้ doctl apps create-deployment ยิง deploy จาก workflow ภายนอกแทนได้เช่นกัน หลัง repo เชื่อมสำเร็จ หน้า App Platform จะแสดง build log แบบ real-time ทำให้ debug ปัญหา dependency หรือ build script ผิดพลาดได้ทันทีโดยไม่ต้องรอ deploy จบก่อน

• สร้าง app จาก cloud.digitalocean.com/apps → Create App → GitHub
• ติดตั้ง DigitalOcean GitHub App เพื่อ authorize repo
• Monorepo ต้องระบุ Source Directory ให้ตรงตำแหน่ง package.json
• เปิด Autodeploy เพื่อ build/deploy อัตโนมัติทุกครั้งที่ push
• ดู build log แบบ real-time เพื่อ debug ปัญหาได้ทันที

ตั้งค่า Build/Run Command สำหรับ Next.js

การตั้งค่า Build และ Run Command ให้ถูกต้องคือจุดที่ทำให้ Next.js รันบน App Platform ได้จริง เพราะ default ที่ buildpack เดาให้อาจไม่ตรงกับโครงสร้างโปรเจกต์เสมอไป Build Command มาตรฐานคือ npm install && npm run build ซึ่งจริง ๆ แล้ว buildpack จะรัน install ให้อัตโนมัติอยู่แล้ว ดังนั้นใส่แค่ npm run build (ที่ภายในเรียก next build) ก็เพียงพอ ถ้าโปรเจกต์ใช้ yarn หรือ pnpm ต้องระบุให้ตรง เช่น pnpm install && pnpm build เพราะ buildpack จะเลือก package manager ตาม lockfile ที่เจอใน repo (package-lock.json, yarn.lock, pnpm-lock.yaml) Run Command สำหรับ Web Service component คือ npm start ซึ่งปกติ map ไปที่ next start ใน package.json — สิ่งที่พลาดบ่อยคือลืมว่า App Platform กำหนด port ผ่าน environment variable $PORT แบบ dynamic ไม่ตายตัวที่ 3000 เสมอไป ต้องแก้ script เป็น next start -p $PORT ไม่เช่นนั้น health check จะ fail เพราะ container ไม่ได้ listen บน port ที่ platform คาดไว้ สำหรับโปรเจกต์ที่ต้องการ image ขนาดเล็กลงและ cold start เร็วขึ้น แนะนำเปิด output: 'standalone' ใน next.config.js ซึ่งจะ bundle เฉพาะไฟล์ที่จำเป็นเข้า .next/standalone ทำให้ run command เปลี่ยนเป็น node .next/standalone/server.js แทน (ต้อง copy public/ และ .next/static เข้าไปเพิ่มเองใน build step เพราะ standalone output ไม่รวมให้อัตโนมัติ) ส่วน Node.js version ควร pin ให้ตรงกับที่ทดสอบไว้ในเครื่อง โดยระบุใน package.json ด้วย field "engines": {"node": "20.x"} เพื่อป้องกัน buildpack เลือก Node version ที่ใหม่หรือเก่ากว่าจนพฤติกรรม build ต่างไปจากที่คาด กรณีต้องการ deploy แบบ static export ล้วน (ไม่มี SSR/API route) ให้ตั้ง output: 'export' ใน next.config.js แล้วใช้ Build Command next build พร้อมระบุ Output Directory เป็น out จากนั้นเลือก component type เป็น Static Site แทน Service — วิธีนี้เข้าเงื่อนไข free tier ได้ แต่แลกกับการเสีย feature แบบ SSR/ISR ทั้งหมด

• Build command: npm run build (เรียก next build)
• Run command ต้อง bind $PORT: next start -p $PORT
• เปิด output: 'standalone' เพื่อลดขนาด build และ cold start เร็วขึ้น
• Pin Node version ด้วย engines ใน package.json
• Static export ใช้ output: 'export' + Output Directory out

Environment Variables และ Custom Domain

Environment Variables บน App Platform แบ่งเป็นสองระดับ คือระดับ App (ใช้ร่วมกันทุก component) และระดับ Component (เฉพาะ service นั้น) ตั้งค่าได้ทั้งผ่านหน้า Dashboard ในแท็บ Settings > App-Level Environment Variables หรือผ่าน App Spec แบบ YAML จุดที่ต้องเข้าใจให้ชัดสำหรับ Next.js คือ ตัวแปรที่ขึ้นต้นด้วย NEXT_PUBLIC_ จะถูก inline เข้าไปใน JavaScript bundle ฝั่ง client ตั้งแต่ตอน build — หมายความว่าค่าจะถูกฝังตายตัวในไฟล์ static ที่ browser โหลด และมองเห็นได้จากใครก็ตามที่เปิด DevTools ดังนั้นห้ามใส่ secret หรือ API key ที่ต้องปิดเป็นความลับด้วย prefix นี้เด็ดขาด ส่วนตัวแปรที่ไม่มี prefix นี้จะใช้ได้เฉพาะฝั่ง server เช่นใน API route หรือ getServerSideProps เท่านั้น อีกจุดที่พลาดบ่อยคือเมื่อแก้ค่า NEXT_PUBLIC_* แล้ว deploy ใหม่ App Platform จะไม่ auto-rebuild ให้เสมอถ้าไม่มีการ push commit ใหม่ — ต้องกด "Deploy" หรือ trigger rebuild ด้วยมือ เพราะค่าถูก bake เข้า build ไม่ใช่ inject ตอน runtime เหมือนตัวแปรฝั่ง server สำหรับข้อมูล sensitive เช่น database connection string หรือ API secret ควรตั้ง type เป็น "Encrypted" (SECRET) แทน "Plain Text" (GENERAL) ในหน้า environment variables ของ Dashboard เพื่อไม่ให้ค่าแสดงเป็น plaintext ใน build log หรือหน้า UI เรื่อง Custom Domain ทำได้จากแท็บ Settings > Domains ของ app โดยกด Add Domain แล้วใส่โดเมนที่ต้องการ ระบบจะให้ค่า CNAME หรือ A/ALIAS record ที่ต้องไปตั้งที่ DNS provider ให้ชี้มาที่ domain default ของ app (รูปแบบ your-app-xxxxx.ondigitalocean.app) หลังจาก DNS propagate สำเร็จ App Platform จะออกใบรับรอง TLS จาก Let's Encrypt ให้อัตโนมัติโดยไม่ต้องตั้งค่า Certbot เองเหมือนตอนใช้ Droplet ทำให้ HTTPS พร้อมใช้งานภายในไม่กี่นาทีหลัง DNS ชี้ถูกต้อง

• แยก env variable ระดับ App กับระดับ Component
• NEXT_PUBLIC_ prefix = ฝัง client-side ตอน build ห้ามใส่ secret
• แก้ NEXT_PUBLIC_* แล้วต้อง trigger rebuild ใหม่เสมอ

ราคา: Free tier static เท่านั้น / Paid เริ่ม $5/เดือน

เรื่องราคาเป็นจุดที่ทำให้หลายคนสับสนเมื่อย้ายจาก static site มาเป็น Next.js แบบ SSR เพราะ App Platform free tier ครอบคลุมเฉพาะ Static Site component เท่านั้น — ใช้งานได้สูงสุด 3 apps ต่อบัญชี พร้อม bandwidth 1 GiB ต่อ app ไม่มีค่าใช้จ่าย เหมาะกับเว็บที่ export เป็น static ล้วน (output: 'export') โดยไม่มี API route หรือ SSR แต่ถ้าแอป Next.js ใช้ getServerSideProps, API routes, middleware, หรือ ISR ที่ revalidate on-demand ต้อง deploy เป็น Web Service component ซึ่งไม่มี free tier — ต้องเลือกแผนจ่ายเงินเสมอ ปัจจุบัน DigitalOcean ยกเลิกชื่อแผน Basic/Professional แบบเดิมไปแล้ว (ยกเลิกกลางปี 2026) เปลี่ยนมาให้เลือก container instance size ตรง ๆ แทน โดยมีตัวเลือกเริ่มต้นดังนี้ Shared 1 vCPU / 512 MiB RAM / 50 GiB transfer ต่อเดือน อยู่ที่ $5/เดือน, Shared 1 vCPU / 1 GiB RAM / 100 GiB transfer อยู่ที่ $10/เดือน, Shared 1 vCPU / 1 GiB RAM / 150 GiB transfer อยู่ที่ $12/เดือน, Shared 1 vCPU / 2 GiB RAM / 200 GiB transfer อยู่ที่ $25/เดือน และ Shared 2 vCPU / 4 GiB RAM / 250 GiB transfer อยู่ที่ $50/เดือน สำหรับ Next.js app ขนาดเล็กถึงกลางที่มี traffic ไม่สูงมาก แผน $5/เดือน (512 MiB RAM) มักเพียงพอสำหรับทดสอบหรือ MVP แต่ถ้าแอปมีหลายหน้าที่ต้อง build ISR cache จำนวนมาก หรือใช้ memory สูงตอน render เช่น generate PDF หรือ image processing ใน API route ควรพิจารณาแผน 1 GiB ขึ้นไปเพื่อป้องกัน process ถูก kill จาก out-of-memory ข้อควรระวังอีกจุดคือถ้าตั้ง instance count มากกว่า 1 เพื่อรองรับ traffic สูงหรือทำ zero-downtime deploy ค่าใช้จ่ายจะคูณตามจำนวน instance ทันที เช่น 2 instance บนแผน $10/เดือน จะรวมเป็น $20/เดือน ไม่ใช่ราคาคงที่แบบ Droplet เดียว — ตัวเลขทั้งหมดนี้เป็นข้อมูล ณ กรกฎาคม 2026 ควรตรวจสอบราคาล่าสุดที่หน้า pricing ของ DigitalOcean ก่อนตัดสินใจจริงเสมอ

• Free tier: static site เท่านั้น สูงสุด 3 apps, 1 GiB transfer/app
• Web Service ไม่มี free tier ต้องจ่ายเสมอ
• แผนเริ่มต้น $5/เดือน (1 vCPU/512 MiB RAM/50 GiB transfer)

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

App Platform เหมาะกับการ deploy Next.js ในหลายสถานการณ์ที่ทีมให้น้ำหนักกับความเร็วในการ ship มากกว่าการควบคุม infrastructure แบบละเอียด เช่น MVP หรือ side project ที่ต้องการขึ้น production ภายในไม่กี่นาทีหลัง push code, เว็บไซต์การตลาดที่ผสม static page กับ API route เล็ก ๆ สำหรับ contact form หรือ newsletter signup, หรือทีมขนาดเล็กที่ไม่มี DevOps เฉพาะทางคอยดูแล Nginx/SSL/process manager เอง อีก use case ที่เหมาะคือ preview environment สำหรับ pull request — App Platform รองรับการสร้าง deploy preview แยกต่างหากเมื่อเปิด PR ทำให้ทีม review ฟีเจอร์ใหม่บน URL จริงก่อน merge ได้โดยไม่ต้อง setup CI/CD เพิ่มเอง ซึ่งมีประโยชน์มากสำหรับทีมที่ทำงานแบบ trunk-based development หรือ review UI บ่อย ในทางกลับกัน มีสถานการณ์ที่ App Platform ไม่ใช่ตัวเลือกที่คุ้มค่าที่สุด เช่น แอปที่ต้อง fine-tune ระดับ OS หรือ network stack อย่าง custom Nginx rewrite rule ซับซ้อน หรือ WebSocket connection จำนวนมากที่ต้อง tuning connection pool เอง, แอปที่มี traffic สูงมากจนต้องคุมต้นทุนต่อ request อย่างละเอียด ซึ่ง Droplet ร่วมกับ PM2 และ Nginx มักถูกกว่าต่อหน่วยเมื่อ scale ใหญ่, หรือแอปที่ทำ ISR หนักและต้องการ shared cache ระหว่างหลาย instance เพราะ App Platform ไม่มี shared filesystem ระหว่าง container — แต่ละ instance มี cache ของตัวเองแยกกัน ทำให้ผู้ใช้อาจเห็นข้อมูลไม่ตรงกันชั่วขณะเมื่อมีมากกว่า 1 instance รับ traffic พร้อมกัน สำหรับทีมที่ยังไม่แน่ใจว่า traffic จะโตแค่ไหน การเริ่มด้วย App Platform ก่อนแล้วค่อยย้ายไป Droplet หรือ Kubernetes ทีหลังเมื่อ requirement ชัดเจนขึ้น เป็นแนวทางที่สมเหตุสมผล เพราะต้นทุนเริ่มต้นต่ำและไม่ต้อง lock-in สถาปัตยกรรมล่วงหน้า

• เหมาะกับ MVP, marketing site, ทีมไม่มี DevOps เฉพาะทาง
• รองรับ preview environment แยกต่างหากต่อ pull request
• ไม่เหมาะกับแอปที่ต้อง fine-tune OS/network stack ระดับลึก
• ISR แบบหลาย instance ต้องระวังเรื่อง cache ไม่ sync กัน

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

ปัญหาที่พบบ่อยที่สุดเมื่อ deploy Next.js บน App Platform คือ build fail จาก Node.js version ไม่ตรงกับที่โปรเจกต์ต้องการ โดยเฉพาะเมื่อใช้ syntax หรือ dependency ที่รองรับเฉพาะ Node เวอร์ชันใหม่ วิธีแก้คือ pin เวอร์ชันด้วย field engines ใน package.json ให้ตรงกับที่ทดสอบในเครื่อง ปัญหาที่สองคือ deploy สำเร็จแต่เข้าเว็บไม่ได้ หรือ health check ขึ้น fail ต่อเนื่อง สาเหตุหลักมักเป็นเพราะ run command ไม่ได้ bind กับ $PORT ที่ App Platform กำหนดให้ ทำให้ container listen ผิด port — ต้องแก้ start script เป็น next start -p $PORT เสมอ อย่า hardcode 3000 ปัญหาที่สามคือ environment variable ที่ควรใช้ฝั่ง client กลับอ่านค่าไม่ได้ (undefined) เพราะลืมใส่ prefix NEXT_PUBLIC_ — ตัวแปรฝั่ง server ธรรมดาจะไม่ถูกส่งไปยัง browser bundle ไม่ว่าจะตั้งค่าถูกต้องแค่ไหนก็ตาม ปัญหาที่สี่เกี่ยวกับ ISR: เมื่อใช้ revalidate แบบ time-based หรือ on-demand revalidation ผ่าน API route แล้วพบว่าบางครั้งเห็นหน้าเก่า บางครั้งเห็นหน้าใหม่สลับกันไปมา ทั้งที่ revalidate สำเร็จแล้ว — นี่คือผลจากการมีมากกว่า 1 instance ที่แต่ละตัวมี cache แยกกัน ไม่ sync กัน วิธีแก้เบื้องต้นคือลด instance count เหลือ 1 ถ้า traffic ไม่สูงมาก หรือย้าย cache layer ไปที่ external store เช่น Managed Valkey Database แทนการพึ่ง filesystem cache ในตัว container ปัญหาที่ห้าคือ build timeout หรือ build ใช้เวลานานผิดปกติในโปรเจกต์ monorepo — มักเกิดจากไม่ได้ระบุ Source Directory ให้ตรง ทำให้ buildpack พยายาม install dependency ของทั้ง monorepo แทนที่จะ scope เฉพาะ Next.js app เดียว แก้โดยตั้งค่า Source Directory ให้ตรงกับตำแหน่ง package.json ของแอปนั้น และถ้าเป็นไปได้ใช้ workspace filtering ของ package manager เช่น pnpm --filter ใน build command เพื่อลดเวลา install

• Build fail จาก Node version ไม่ตรง → pin ด้วย engines
• Health check fail → ลืม bind $PORT ใน run command
• Client อ่าน env var ไม่ได้ → ลืม prefix NEXT_PUBLIC_

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

แนวทางที่ควรทำเป็นมาตรฐานเมื่อ deploy Next.js บน App Platform เริ่มจากเปิด output: 'standalone' ใน next.config.js เสมอสำหรับ production เพราะช่วยลดขนาด build artifact และทำให้ cold start เร็วขึ้นอย่างชัดเจนเมื่อเทียบกับการ deploy node_modules เต็มรูปแบบ ควบคุม instance count ให้เหมาะสมกับ workload จริง — ถ้าแอปพึ่ง ISR หรือ in-memory cache หนัก ให้เริ่มที่ 1 instance ก่อน แล้วค่อยพิจารณาย้าย cache ไปที่ external layer เช่น Managed Valkey Database ก่อนจะ scale เป็นหลาย instance เพื่อไม่ให้ผู้ใช้เห็นข้อมูลไม่สอดคล้องกันระหว่าง instance ใช้ App Spec แบบ YAML เก็บไว้ใน repo ผ่าน doctl apps create --spec app.yaml หรือ update ด้วย doctl apps update แทนการตั้งค่าทุกอย่างผ่าน dashboard ล้วน ๆ เพื่อให้ configuration ของ infrastructure ถูก version control ไปพร้อมกับโค้ด ทำให้ reproduce environment ใหม่หรือ rollback การตั้งค่าย้อนหลังทำได้ง่าย แยก secret ออกจาก plain environment variable เสมอ โดยตั้ง type เป็น Encrypted สำหรับ API key, database URL, และ auth secret ทั้งหมด และตรวจสอบให้แน่ใจว่าไม่มี secret ใดหลุดไปอยู่ใน prefix NEXT_PUBLIC_ โดยไม่ตั้งใจ เปิดใช้ preview environment สำหรับทุก pull request เพื่อให้ทีม review งานบน URL จริงก่อน merge เข้า main แทนการ review แค่ diff code เฉย ๆ ซึ่งช่วยจับบั๊กที่เกี่ยวกับ UI/UX หรือ environment variable ผิดพลาดได้เร็วกว่า สุดท้ายควรตั้ง monitoring/alert พื้นฐานผ่านฟีเจอร์ในตัวของ App Platform ให้แจ้งเตือนเมื่อ memory usage หรือ restart count สูงผิดปกติ เพราะเป็นสัญญาณเตือนล่วงหน้าว่าแผนปัจจุบันเล็กเกินไปสำหรับ traffic จริง ก่อนที่ผู้ใช้ปลายทางจะเจอปัญหา

• เปิด output: 'standalone' เสมอสำหรับ production
• คุม instance count ให้เหมาะกับ workload ที่พึ่ง cache
• เก็บ App Spec เป็น YAML ใน repo (infra-as-code)
• แยก secret เป็น Encrypted type เสมอ

รับ $200 Free Credit →