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

Python บน Vercel เปิดตัว GA แล้ว: ใช้ FastAPI Django ได้จริง ไม่ต้องเซ็ตเซิร์ฟเวอร์เอง

น้องกายEngineering

เมื่อวันพฤหัสบดีที่ 15 ตุลาคม 2026 (อีกสองวันก่อนวันนี้) Vercel ประกาศว่า Python บน Vercel เปิดให้ใช้งานแบบ Generally Available (GA) โดยเรียก Python ว่าเป็น “first-class language and runtime” ของแพลตฟอร์ม https://vercel.com/changelog/python-on-vercel-is-now-generally-available https://vercel.com/blog/python-on-vercel-is-now-generally-available นักพัฒนาที่เคยเขียน FastAPI, Flask หรือ Django สามารถนำแอปเดิมไป deploy ได้โดยไม่ต้องดูแลเซิร์ฟเวอร์เอง เพราะ Vercel ตรวจจับเฟรมเวิร์กและตั้งค่า build ให้ รองรับ uv กับ pyproject.toml และมี Vercel Daemons สำหรับงานที่ต้องรันต่อเนื่อง https://vercel.com/changelog/python-on-vercel-is-now-generally-available

บทความนี้ไม่ใช่โฆษณานะครับ ผมจะเล่าว่าแหล่งข้อมูลทางการพูดอะไรไว้บ้าง จุดไหนยังไม่มีตัวเลข จุดไหนเป็นข้อควรระวัง และเมื่อไหร่ VPS ยังเป็นตัวเลือกที่ดีกว่า

สรุป 30 วินาที: เกิดอะไรขึ้น

ทำไมเรื่องนี้เกี่ยวกับคุณ

ถ้าคุณเป็นฟรีแลนซ์ที่รับทำ LINE bot ให้ร้านค้า เป็นนักศึกษาที่ทำ Django side project ส่งอาจารย์ หรืออยากเปิด FastAPI ให้เพื่อนในทีมเรียกใช้ คุณอาจเคยเจอสถานการณ์นี้ครับ จะเอาโค้ดขึ้นออนไลน์ก็ต้องเช่า VPS ติดตั้ง Python ตั้งค่า web server และคอยดูแลเครื่องเอง งานโค้ดจริงยังไม่ทันเริ่ม เวลาก็หมดไปกับงานระบบแล้ว

Vercel บอกว่าตัวเองรับผิดชอบเรื่องโครงสร้างพื้นฐานให้ คุณจะได้โฟกัสที่แอป https://vercel.com/changelog/python-on-vercel-is-now-generally-available แปลว่าสำหรับโปรเจกต์ขนาดเล็ก ขั้นตอนอาจเหลือแค่เตรียมโค้ดให้ Vercel อ่านได้ แล้ว deploy ผ่าน Git หรือ CLI แต่ผมยังไม่มีข้อมูลพิสูจน์ว่า “งานจะเสร็จเร็วขึ้นกี่เท่า” เพราะแหล่งข้อมูลไม่ได้ให้ตัวเลขนั้นไว้

แหล่งข้อมูลมีตัวเลขเรื่องการใช้งานจริงอยู่หนึ่งชุด บล็อก Backends ของ Vercel ระบุว่ามี 150,000 ทีมรัน Python backend บน Vercel อยู่แล้ว รวมถึงวิศวกรที่ OpenAI, Polymarket และ Exa https://vercel.com/blog/backends-on-vercel-python-containers-and-daemons ตัวเลขนี้มาจาก Vercel เองและยังไม่มีแหล่งอิสระยืนยัน ให้ใช้เป็นภาพรวมของความนิยม ไม่ใช่หลักฐานว่าโปรเจกต์ของคุณจะเหมาะ

บล็อกเดียวกันยังเล่าเคสของ Delphi ที่ย้าย Python backend จาก AWS ECS มาอยู่บน Vercel ทีมมีวิศวกร 10 คน ไม่มีตำแหน่งดูแลโครงสร้างพื้นฐานโดยเฉพาะ และ deploy ขึ้น production มากกว่า 100 ครั้งต่อวัน เคสนี้ Vercel เลือกมาเล่าเอง จึงอ่านเป็นตัวอย่างจากผู้ให้บริการ ไม่ใช่ผลสำรวจกลาง

ทำงานยังไง

1. Vercel อ่านไฟล์โปรเจกต์แล้วตรวจจับเฟรมเวิร์ก

ตามเอกสาร Vercel ตรวจจับเฟรมเวิร์กอัตโนมัติเมื่อเจอ dependency ที่ตรงกันใน requirements.txt, pyproject.toml หรือ Pipfile preset ของ Python ใช้ได้กับ FastAPI, Flask, Django และเฟรมเวิร์กเว็บ Python อื่น ๆ https://vercel.com/docs/functions/runtimes/python จากนั้น Vercel รันแอปของคุณเป็น Vercel Functions และส่ง request ทุกตัวไปที่แอปนั้น เอกสารบอกว่าแอปที่รันบนเครื่องคุณ deploy ได้ตามเดิม

เอกสารระบุว่า Python runtime รองรับแอปแบบ ASGI และ WSGI สองคำนี้คือมาตรฐานที่เว็บเซิร์ฟเวอร์ใช้คุยกับแอป Python (ASGI รองรับงานแบบ async ส่วน WSGI เป็นแบบดั้งเดิม) คุณไม่ต้องเขียนโค้ดตรงนี้เอง แค่รู้ไว้ว่า FastAPI, Flask และ Django ล้วนอยู่ในกลุ่มนี้

2. ต้องมี entrypoint ที่ Vercel หาเจอ

Vercel มองหาไฟล์ app.py, index.py, server.py, main.py, wsgi.py หรือ asgi.py ทั้งที่ root และในโฟลเดอร์ src/ หรือ app/ หรือจะระบุโมดูลเองด้วย tool.vercel.entrypoint ใน pyproject.toml ก็ได้ ในไฟล์นั้นต้องมีตัวแปรระดับบนสุดชื่อ app (สำหรับ FastAPI, Flask และเฟรมเวิร์ก ASGI/WSGI ส่วนใหญ่) หรือ application (สำหรับ Django และแอป WSGI อื่น ๆ) https://vercel.com/docs/functions/runtimes/python

สำหรับ Django เอกสารบอกว่า Vercel จะมองหา manage.py ที่กำหนด DJANGO_SETTINGS_MODULE (รวมถึงในโฟลเดอร์ย่อยชั้นแรก) แล้วหาตัวแอปจากค่า WSGI_APPLICATION หรือ ASGI_APPLICATION ในไฟล์ settings ดังนั้นโปรเจกต์ Django ที่โครงสร้างปกติควรถูกตรวจเจอ แต่ถ้าคุณจัดโฟลเดอร์แปลก ๆ ก็ควรเปิดเอกสารดูให้ชัดก่อน

3. เลือกเวอร์ชัน Python และจัดการแพ็กเกจ

เอกสารระบุว่ากำหนดเวอร์ชัน Python ได้ผ่าน pyproject.toml, .python-version หรือ Pipfile.lock ถ้าไม่ได้กำหนดหรือเวอร์ชันที่ขอไม่รองรับ Vercel จะใช้เวอร์ชัน default เวอร์ชันที่มีให้เลือกคือ 3.12 (default), 3.13 และ 3.14 https://vercel.com/docs/functions/runtimes/python เรื่องนี้สำคัญ เพราะถ้าคุณไม่ pin เวอร์ชัน แล้วเขียนโค้ดบนเครื่องด้วย Python รุ่นอื่น อาจเจอพฤติกรรมไม่ตรงกันตอน deploy

เรื่อง dependency เอกสารบอกว่าประกาศได้ใน pyproject.toml (จะมี uv.lock หรือไม่ก็ได้), requirements.txt หรือ Pipfile ที่มี Pipfile.lock คู่กัน ส่วนบล็อกระบุว่า Vercel อ่านไฟล์ dependency รวมถึงที่จัดการด้วย uv https://vercel.com/blog/python-on-vercel-is-now-generally-available หมายความว่าไม่ได้บังคับให้เลิกใช้ requirements.txt คุณเลือกวิธีที่ถนัดได้

4. ทำไมเลือก CPython บน Linux

บล็อกอธิบายเป้าหมายข้อหนึ่งของทีมว่า runtime ควรใช้ CPython ซึ่งเป็น interpreter มาตรฐานของ Python บน Linux เพื่อรักษาความเข้ากันได้กับแพ็กเกจและเครื่องมือที่นักพัฒนา Python ใช้อยู่แล้ว https://vercel.com/blog/python-on-vercel-is-now-generally-available สำหรับคุณ นี่คือเหตุผลที่แอปส่วนใหญ่ที่เขียนแบบมาตรฐานควรย้ายมาได้ไม่ยาก แต่บล็อกไม่ได้รับประกันว่าทุกแพ็กเกจใช้ได้ ถ้ามีแพ็กเกจที่ต้องพึ่งไลบรารีระดับระบบ ควรทดสอบก่อน

5. Bytecode และการเริ่มต้นเร็วขึ้น

ตอน build เอกสารบอกว่า Vercel คอมไพล์ซอร์สโค้ด Python เป็น bytecode (ไฟล์ .pyc) แล้วใส่ไว้ใน function bundle “เมื่อมีพื้นที่เหลือพอ” เพื่อลดเวลา initialization โดยไม่ต้องตั้งค่าอะไร https://vercel.com/docs/functions/runtimes/python คำว่า “เมื่อมีพื้นที่เหลือพอ” บอกเราว่าถ้า bundle ใหญ่มาก ประโยชน์ส่วนนี้อาจไม่ได้เสมอไป

6. อธิบายแบบบ้าน ๆ

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

ข้อแลกเปลี่ยนก็เหมือนศูนย์อาหารจริงครับ คุณต้องทำตามกฎของที่นั่น ผังร้านจะดัดแปลงตามใจไม่ได้ทั้งหมด และถ้าวันหนึ่งอยากย้ายไปเปิดร้านที่อื่นก็ต้องขนของเอง

7. งานที่ต้องรันยาว: Vercel Daemons (Public Beta)

บางงานไม่ได้รอ request จากผู้ใช้ เช่น worker ที่คอยดึงงานจากคิวหรือฐานข้อมูลมาประมวลผล บล็อก Backends อธิบายว่า Vercel Daemons ให้คุณ deploy container เป็น background worker ที่รันต่อเนื่องบน Fluid compute คุณกำหนดจำนวน instance ในแต่ละ region แล้ว Vercel จะรักษาจำนวนนั้นไว้โดยรีสตาร์ตโปรเซสเมื่อมันหยุดหรือแครช Daemons รองรับงานแบบ pull-based เช่น อ่านข้อความจากคิวหรือไปดึงงานที่ค้างจากฐานข้อมูล https://vercel.com/blog/backends-on-vercel-python-containers-and-daemons

ตัวอย่างในบล็อกคือแอปวิดีโอที่ใช้ Daemons รันตัวประมวลผลวิดีโอต่อเนื่อง ดึงงานจาก Vercel Queues แล้วสร้างไฟล์สำหรับเล่นกับภาพตัวอย่างให้คลิปที่อัปโหลด ตัวอย่างกำหนดให้รัน 1 instance ใน region iad1 ซึ่งบล็อกระบุว่าคือ Washington, D.C. ย้ำอีกครั้งว่านี่เป็น Public Beta ถ้าจะใช้กับงานที่ธุรกิจพึ่งพา ควรอ่านเงื่อนไขและทดสอบเองก่อน

8. Frontend กับ backend ในโปรเจกต์เดียว

Vercel Services ให้ deploy frontend และ backend ในโปรเจกต์เดียวกัน มี preview และ rollback ที่ทำพร้อมกัน (atomic deployments) ดู log แยกตาม service ได้ และเชื่อม backend ถึงกันแบบ private ผ่าน service bindings ตัวอย่างใน changelog วางไฟล์ vercel.toml ที่ root กำหนด root ของแต่ละ service แล้วใช้ rewrites ส่ง /api/ ไปที่ FastAPI ส่วนที่เหลือไปที่ frontend จากนั้นรันสอง service พร้อมกันบนเครื่องด้วย vercel dev ได้ https://vercel.com/changelog/python-on-vercel-is-now-generally-available

9. Python SDKs

changelog และบล็อกระบุว่ามี SDK สำหรับ Python ดังนี้ https://vercel.com/changelog/python-on-vercel-is-now-generally-available https://dev48.org/en/articles/python-on-vercel-is-now-generally-available

  • Sandbox: ให้แอปหรือ agent ได้ Linux VM แบบแยกส่วนตามต้องการ ใช้รันโค้ดที่ไม่น่าไว้ใจ
  • AI SDK for Python (Beta): สร้างหรือสตรีมคำตอบจากโมเดลและเรียก tool
  • Workflow SDK for Python (Beta): เก็บสถานะการทำงานและ retry ขั้นตอนที่ล้มเหลว
  • Queues (Beta): ส่งและรับข้อความสำหรับงานเบื้องหลัง
  • Connect: ขอ credential สำหรับเรียก API ภายนอก
  • Blob: อัปโหลดและดึงไฟล์จาก object storage

บล็อกบอกว่า API ของ SDK เหล่านี้ใช้ type annotations, async/await และ context managers ให้เข้ากับธรรมเนียมของภาษา Python และใช้ร่วมกับเฟรมเวิร์กที่คุณมีได้ https://vercel.com/blog/python-on-vercel-is-now-generally-available เห็นได้ว่า SDK เหล่านี้เป็นส่วนเสริม คุณไม่จำเป็นต้องใช้ทั้งหมด

จุดหักมุม: GA ของ Python ไม่ได้แปลว่าทุกส่วนเสถียรเท่ากัน

ข่าวนี้อ่านแล้วอาจรู้สึกว่า “ทุกอย่างพร้อม” แต่แหล่งข้อมูลแยกสถานะไว้ชัดเจน Python runtime เป็น GA ส่วนที่ติดป้าย Beta คือ AI SDK for Python, Workflow SDK for Python และ Queues (ตาม changelog) และ Vercel Daemons ที่เป็น Public Beta (ตามบล็อก Backends) https://vercel.com/changelog/python-on-vercel-is-now-generally-available https://vercel.com/blog/backends-on-vercel-python-containers-and-daemons ถ้าโปรเจกต์ของคุณพึ่งชิ้นส่วนเหล่านี้ ให้ถือว่ายังมีโอกาสเปลี่ยนแปลงได้

อีกเรื่องคือขนาด bundle เอกสารระบุว่า Python Functions จะรวมไฟล์ทั้งหมดในโปรเจกต์ที่เข้าถึงได้ตอน build และ ไม่มี tree-shaking อัตโนมัติสำหรับ Python (tree-shaking คือการตัดส่วนที่ไม่ถูกใช้ออกจากแพ็กเกจให้เล็กลง) เอกสารจึงแนะนำให้ระบุเฉพาะแพ็กเกจที่จำเป็นตอนรันจริง และกำหนด excludeFiles ใน vercel.json เพื่อตัดไฟล์ทดสอบ ไฟล์ static หรือข้อมูลตัวอย่างออก เพื่อให้ bundle เล็กและไม่ชนขีดจำกัดด้านขนาด https://vercel.com/docs/functions/runtimes/python เอกสารที่ผมมีไม่ได้ระบุตัวเลขขีดจำกัดนั้น ผมจึงไม่ขอเดาตัวเลขให้ครับ

เรื่องเงิน / ผลกระทบ

ราคา: แหล่งข้อมูลทั้งห้าชิ้นไม่ได้ระบุราคาของ Python on Vercel เป็นตัวเลข ดังนั้นผมบอกไม่ได้ว่าโปรเจกต์ของคุณจะเสียเดือนละเท่าไหร่ ให้เปิดหน้า pricing ของ Vercel ดูเองก่อนตัดสินใจ

สิ่งที่แหล่งข้อมูลพูดถึงคือวิธีคิดเงินของ Fluid compute บล็อก Backends ระบุว่า container ที่ deploy เป็น Vercel Functions บน Fluid compute ใช้ Active CPU pricing ซึ่งไม่คิดเงินช่วงที่รอ API, ฐานข้อมูล หรือ LLM ตอบกลับ https://vercel.com/blog/backends-on-vercel-python-containers-and-daemons แต่ประโยคนี้เขียนไว้ในส่วนของ container ผมจึงไม่ยืนยันว่ามันใช้กับ Python Functions ทุกแบบเหมือนกัน เรื่องนี้ต้องไปอ่านหน้าราคาและเงื่อนไขเอง

ผมยังไม่สรุปว่า Vercel จะถูกกว่า VPS หรือแพงกว่า เพราะมันขึ้นกับ traffic, ขนาดงาน, แผนที่ใช้ และยังไม่มีตัวเลขในแหล่งข้อมูล ให้ลองประมาณการใช้งานของโปรเจกต์คุณแล้วเทียบกับค่าเช่า VPS ที่คุณจ่ายอยู่จริง

ผลกระทบด้านวิธีทำงาน: บล็อกระบุว่าโปรเจกต์ full-stack ใช้ workflow เดียวกันทั้งตอนพัฒนาบนเครื่อง preview deployment และ production release https://vercel.com/blog/python-on-vercel-is-now-generally-available ถ้าคุณทำงานกับเพื่อนที่เขียน frontend การที่ preview ของสองฝั่งอยู่ด้วยกันช่วยให้ตรวจงานง่ายขึ้นได้

เรื่อง lock-in (ข้อสังเกตของผมเอง ไม่ใช่คำของ Vercel): ถ้าคุณใช้ SDK อย่าง Blob, Queues หรือ Workflow โค้ดส่วนนั้นผูกกับบริการของ Vercel ถ้าวันหนึ่งต้องย้ายไปที่อื่น ก็ต้องหาของมาแทนและแก้โค้ดตรงนั้น การเขียนแอปให้แยก logic ธุรกิจออกจากโค้ดที่เรียก SDK จะช่วยให้ย้ายง่ายขึ้น

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

  • วันที่ในเอกสาร: changelog และบล็อกลงวันที่ 15 ตุลาคม 2026 https://vercel.com/changelog/python-on-vercel-is-now-generally-available https://vercel.com/blog/python-on-vercel-is-now-generally-available แต่หน้า docs ของ Python runtime ที่ผมมีลงวันที่ 12 สิงหาคม 2026 และตัวข้อความที่ผมมีไม่ได้พูดถึง GA เลย ผมไม่รู้ว่าเอกสารถูกอัปเดตตามประกาศแล้วหรือยัง ให้ถือว่ารายละเอียดใน docs อาจเปลี่ยน และตรวจหน้าล่าสุดก่อนใช้งาน
  • ตัวเลข 150,000 ทีม: มาจากบล็อก Backends ของ Vercel เพียงแหล่งเดียว ไม่มีผู้ตรวจสอบอิสระ https://vercel.com/blog/backends-on-vercel-python-containers-and-daemons
  • ขีดจำกัดขนาด bundle: docs เตือนถึงขีดจำกัดด้านขนาดและวิธี excludeFiles แต่ไม่ได้ให้ตัวเลข https://vercel.com/docs/functions/runtimes/python บล็อกประกาศไม่ได้พูดถึงเรื่องนี้
  • Region: ตัวอย่าง Daemons ใช้ iad1 (Washington, D.C.) แต่แหล่งข้อมูลที่ผมมีไม่ได้ระบุรายการ region ทั้งหมดของ Python Functions ผมจึงบอกไม่ได้ว่าจะเลือก region ใกล้ไทยได้หรือไม่ และไม่รู้ว่า latency จากไทยจะเป็นอย่างไร
  • Cold start: แหล่งข้อมูลไม่มีตัวเลขเวลา cold start ของ Python เลย ต้องวัดเองกับแอปของคุณ
  • ราคา: ไม่มีตัวเลขราคาในแหล่งข้อมูลทั้งหมด ให้เช็คหน้า pricing ของ Vercel

แล้วเราควรทำอะไร

สำหรับฟรีแลนซ์และนักเรียนที่อยากลอง

  1. สร้างแอป FastAPI เล็ก ๆ ที่มี route เดียว ตัวอย่างใน docs ใช้ FastAPI() เก็บไว้ในตัวแปรชื่อ app ในไฟล์ที่ Vercel หาเจอ เช่น main.py
  2. สร้าง pyproject.toml และกำหนด requires-python = ">=3.12" ตามตัวอย่างใน docs ถ้าต้องการล็อกเวอร์ชันให้ชัดกว่านั้น ใช้ .python-version หรือ Pipfile.lock ได้ เวอร์ชันที่รองรับคือ 3.12, 3.13 และ 3.14 https://vercel.com/docs/functions/runtimes/python
  3. ใส่เฉพาะ dependency ที่จำเป็นจริง ๆ เพราะ Python ไม่มี tree-shaking อัตโนมัติ
  4. เก็บ secret เช่น token ของ LINE หรือ API key ไว้ใน Environment Variables ของโปรเจกต์ อย่าเขียนลงโค้ดหรือ commit เข้า Git (นี่เป็นหลักปฏิบัติทั่วไป ไม่ได้มาจากแหล่งข้อมูลชุดนี้)
  5. deploy ผ่าน Git หรือ CLI แล้วลองเรียก API หลายครั้ง จับเวลา request แรกหลังทิ้งไว้นานเทียบกับ request ถัด ๆ ไป เพื่อดูเองว่า cold start รับได้ไหมกับงานของคุณ
  6. ถ้าทำ LINE bot ลองสร้าง endpoint รับ webhook แยกจากโค้ดส่วนอื่นให้ชัด เพื่อให้ย้ายที่ได้ง่ายถ้าจำเป็น

สำหรับทีมเล็กหรือบริษัทขนาดเล็ก

  1. เริ่มจากบริการที่ไม่วิกฤต เช่น internal API หรือบอทที่ล้มแล้วไม่เสียหายหนัก
  2. ตรวจ bundle และตั้ง excludeFiles เพื่อตัดไฟล์ทดสอบ ไฟล์ static และข้อมูลตัวอย่างออก
  3. ถ้ามีงานเบื้องหลังที่ต้องดึงงานจากคิว ให้ลองดู Vercel Daemons แต่จำไว้ว่าเป็น Public Beta และเหมาะกับงานแบบ pull-based ไม่ใช่ตัวแทน cron ตรง ๆ
  4. ถ้าต้องควบคุมระบบปฏิบัติการเต็มรูปแบบ หรือต้องการแพ็กเกจระดับระบบเฉพาะ ให้พิจารณา VPS หรือ container เอง บล็อก Backends ระบุว่า Vercel มี container support สำหรับ custom runtime และ system library แต่ระบุสถานะว่ายังเป็น Public Beta ตอนเปิด container https://vercel.com/blog/backends-on-vercel-python-containers-and-daemons

เมื่อไหร่ควรเลือก VPS แทน

  • โปรเจกต์ที่ต้องการติดตั้งซอฟต์แวร์ระบบเอง หรือควบคุมเครื่องเต็มที่
  • งานที่รันต่อเนื่องทั้งวันโดยไม่ใช่รูปแบบ request หรือ pull-based ซึ่งผมยังไม่เห็นข้อมูลราคาเปรียบเทียบจากแหล่งข้อมูล
  • กรณีที่ราคาของ Vercel ตามหน้า pricing สูงกว่า VPS สำหรับโหลดของคุณ ต้องคำนวณเอง
  • กรณีที่ไม่อยากผูกกับ SDK หรือบริการเฉพาะของแพลตฟอร์ม

สำหรับคนที่กังวลเรื่อง lock-in

  • ใช้ SDK เฉพาะส่วนที่จำเป็นจริง ๆ
  • เก็บ business logic แยกจากโค้ดที่เรียกบริการของ Vercel
  • ลองซ้อมย้ายโปรเจกต์ตัวอย่างไปรันที่อื่นสักครั้งก่อนพึ่งพามาก

ผมมองว่า…

ผมมองว่าการที่ Vercel ลงทุนกับ Python ครั้งนี้ดูจริงจัง บล็อกเล่าว่าทีมตั้งเป้าเมื่อสิบเดือนก่อน และทีม Gel Data ที่นำโดย Yury Selivanov กับ Elvis Pranskevichus เข้าร่วม Vercel เมื่อเดือนธันวาคมปีที่แล้วเพื่อสร้าง Python support นอกจากนี้ยังประกาศสนับสนุน Python Software Foundation https://vercel.com/blog/python-on-vercel-is-now-generally-available จุดที่ผมชอบคือ SDK ที่ออกแบบให้เข้ากับวิธีเขียน Python (type annotations, async/await, context managers) และการรองรับ uv กับ pyproject.toml ซึ่งทำให้นักพัฒนา Python ไม่ต้องเปลี่ยนนิสัยมากนัก

ส่วนที่ผมยังระวังคือ ส่วนที่ยังเป็น Beta ที่ต้องรอดูความเสถียร ขีดจำกัดเรื่อง bundle ที่ต้องดูแลเอง และข้อมูลที่ขาดอย่างราคา, region และ cold start ความเห็นต่อไปนี้เป็นของผมเอง ไม่ใช่ข้อสรุปจากแหล่งข้อมูล: สำหรับโปรเจกต์เล็ก ๆ อย่าง LINE bot หรือ side project มันน่าลอง เพราะข้อดีคือเริ่มได้เร็ว แต่ถ้า traffic สูงสม่ำเสมอตลอดวันหรืองานต้องการควบคุมระบบมาก ผมจะคำนวณเทียบกับ VPS ก่อน และไม่ได้มองว่า Vercel เป็นคำตอบเดียวสำหรับทุกโปรเจกต์

ปิดท้าย: สิ่งที่ต้องจับตา

  • Python SDKs ที่ยังเป็น Beta (AI SDK, Workflow SDK, Queues) จะเป็น GA เมื่อไหร่ ซึ่งแหล่งข้อมูลยังไม่บอกกำหนดการ
  • Vercel Daemons จะออกจาก Public Beta เมื่อไหร่ และจะมีรูปแบบงานอื่นนอกจาก pull-based หรือไม่
  • ราคาและเงื่อนไขจริงของ Fluid compute สำหรับ Python Functions และ Daemons ในหน้า pricing
  • ข้อมูลเรื่อง region และ cold start สำหรับผู้ใช้ในไทย ซึ่งตอนนี้ยังไม่มีในแหล่งข้อมูล
  • ทิศทางที่บล็อกระบุไว้ว่าจะปรับปรุง Python SDKs, runtime performance และ workflow การพัฒนาต่อไป https://vercel.com/blog/python-on-vercel-is-now-generally-available

Recap

  • ลองสร้าง FastAPI app เล็ก ๆ แล้ว deploy บน Vercel ภายในสัปดาห์นี้หรือสัปดาห์หน้า
  • pin เวอร์ชัน Python (3.12, 3.13 หรือ 3.14) ผ่าน pyproject.toml, .python-version หรือ Pipfile.lock
  • อ่านเรื่อง excludeFiles และจัดการขนาด bundle เพราะ Python ไม่มี tree-shaking อัตโนมัติ
  • เก็บ secret ใน Environment Variables เสมอ ไม่ใส่ในโค้ด
  • วัด cold start เองกับแอปของคุณ เพราะแหล่งข้อมูลไม่มีตัวเลข
  • ถ้าจะใช้ Vercel Daemons หรือ SDK ที่ติดป้าย Beta ให้จำไว้ว่ายังไม่ใช่ GA
  • เปิดหน้า pricing ของ Vercel แล้วเทียบกับค่า VPS ก่อนย้ายโปรเจกต์ใหญ่
  • แยก business logic ออกจากโค้ดที่เรียก SDK เฉพาะของ Vercel เพื่อลดภาระถ้าต้องย้าย