บทที่ 57: Railway รัน Backend และ Database

ใน บทที่ 16 Vercel คืออะไร เราเรียนเส้นทางเอาเว็บขึ้นออนไลน์ แต่ระบบธุรกิจหนึ่งระบบมักไม่ได้มีแค่หน้าเว็บ ยังมี API, งานเบื้องหลัง และฐานข้อมูลที่ต้องรันต่อเนื่องด้วย

Railway มองแต่ละส่วนเป็น Service หรือจุดหมายของการ Deploy ซึ่งทำงานเป็น Container จาก Image และเก็บ Source, Variables, Build/Start command, Deployment logs และ Metrics ของตัวเอง.[1] Service แบบรันตลอดใช้กับ Web app, Backend API, Queue และ Database ส่วนงานตามเวลาสามารถเป็น Scheduled Job ได้.[1]

บทนี้จึงไม่สอนว่า Railway “ดีกว่า” Hosting อื่นทุกกรณี แต่สอนให้เลือกตำแหน่งของมันในระบบและ Deploy แบบมี Gate ก่อนรับ Traffic จริง

สไลด์ 1 — Railway อยู่ตรงไหนในระบบ

มองระบบร้านออนไลน์เป็นสี่ชั้น

ลูกค้า → Frontend → Backend API / Worker → PostgreSQL

Frontend คือหน้าที่ลูกค้าเห็น ส่วน Backend API รับคำขอและใช้กฎธุรกิจ Worker ทำงานเบื้องหลัง และ PostgreSQL เก็บข้อมูลถาวร

Railway สามารถรันส่วนเหล่านี้เป็นหลาย Service ใน Project เดียวได้ Service แบบ Persistent เหมาะกับ Web app, Backend API, Queue และ Database ขณะที่ Scheduled Job ใช้กับงานที่รันตามเวลาแล้วจบ.[1]

Frontend จะอยู่บน Vercel หรือที่อื่นก็ได้ แล้วชี้ API มาที่ Railway หรือจะ Deploy ทั้ง Frontend และ Backend บน Railway ก็ได้ ประเด็นคือวางแต่ละชิ้นตามหน้าที่ ไม่ใช่ย้ายทุกอย่างเพราะเห็นปุ่ม Deploy

หน้าเว็บคือหน้าร้าน · Railway คือพื้นที่ให้ระบบหลังร้านทำงาน

สไลด์ 2 — ศัพท์ 5 คำที่ต้องรู้

• Service — หน่วยที่ Railway เอาไปรัน เช่น API, Worker หรือ Database; แต่ละ Service มี Source และการตั้งค่าของตัวเอง.[1]
• Deployment — รุ่นของ Service ที่ถูก Build และเปิดใช้งาน
• Variable — ค่าตั้งค่าและความลับที่ส่งเข้าแอปเป็น Environment Variable.[3]
• Volume — พื้นที่เก็บไฟล์ถาวรที่ต่อเข้ากับ Service.[4]
• Private Network — เครือข่ายภายใน Project ที่ให้ Service คุยกันโดยไม่ต้องเปิด Traffic สู่อินเทอร์เน็ตสาธารณะ.[6]

คำเหล่านี้ช่วยแยกว่าอะไรคือโค้ด อะไรคือค่าตั้งค่า อะไรคือข้อมูล และอะไรคือเส้นทางเชื่อมต่อ

แยกหน่วยให้ถูก แล้วเวลาเสียจะรู้ว่าต้องดูตรงไหน

สไลด์ 3 — 1 Project มีหลาย Service

ตัวอย่างระบบตอบลูกค้าของร้าน

PUBLIC
ลูกค้า → API

PRIVATE NETWORK
API → PostgreSQL
Worker → PostgreSQL
Cron → Worker

API เป็น Service ที่เปิดรับคำขอจากภายนอก Worker เป็น Service ที่รันงานเบื้องหลัง PostgreSQL เป็น Database Service และ Cron เป็นงานตามเวลา ทุกชิ้นมี Deployment, Variables และ Logs แยกกัน แต่รวมอยู่ใน Project เดียว.[1]

Railway PostgreSQL สร้างเป็นอีก Service ใน Project และให้ Variables เช่น PGHOST, PGPORT, PGUSER, PGPASSWORD, PGDATABASE และ DATABASE_URL สำหรับเชื่อมต่อ.[5]

อย่าเอาทุก Process ไปรวมใน Service เดียวเพียงเพราะ Deploy ง่าย เพราะเวลาส่วนหนึ่งล้มจะ Scale, Debug และ Rollback แยกได้ยาก

Project เดียวได้ · แต่แต่ละหน้าที่ควรเป็นคนละ Service

สไลด์ 4 — Git Push แล้ว Deploy ยังไง

เมื่อ Service เชื่อมกับ GitHub repository และ branch ที่กำหนด Push ใหม่จะ Trigger การ Deploy อัตโนมัติ.[2]

PUSH
→ WAIT FOR CI (ถ้าเปิด)
→ BUILD IMAGE
→ START NEW SERVICE
→ HEALTHCHECK 200
→ SWITCH TRAFFIC

ถ้า Repository มี GitHub Actions สามารถเปิด Wait for CI เพื่อให้ Deployment อยู่สถานะ Waiting จน Workflow ผ่าน ถ้า Workflow ล้ม Deployment จะถูก Skip.[2]

ถ้าตั้ง Healthcheck Railway จะเรียก Endpoint จนได้ HTTP 200 ก่อนทำ Deployment ใหม่เป็น Active และทำรุ่นก่อนหน้าเป็น Inactive.[7]

Push สำเร็จจึงยังไม่ใช่หลักฐานว่า Production พร้อม ต้องดู CI, Build, Healthcheck และหน้าใช้งานจริงต่อ

Push ไม่เท่ากับเสร็จ · ต้องผ่าน Gate ก่อนรับ Traffic

สไลด์ 5 — กุญแจไม่อยู่ในโค้ด

Railway Variables ใช้เก็บ Configuration และ Secrets แล้วส่งเข้า Build และ Runtime เป็น Environment Variables.[3]

GitHub
  .env.example = มีเฉพาะชื่อช่อง
  ไม่มี Secret จริง

Railway Variables
  DATABASE_URL
  API_KEY
  WEBHOOK_SECRET

การเพิ่ม แก้ หรือลบ Variable จะเกิดเป็น Staged Changes ซึ่งต้อง Review และ Deploy จึงมีผล.[3] หน้า Staged Changes แสดง Diff ของค่าเดิมกับค่าใหม่และให้ทิ้ง Change ที่ไม่ต้องการก่อน Deploy ทั้งชุดได้.[8]

Railway ยังมี Sealed Variable ซึ่งเมื่อ Seal แล้ว Value จะถูกส่งให้ Build/Deployment แต่ไม่สามารถดูคืนผ่าน UI หรือ API ได้ และมีข้อจำกัดในการ Copy/Sync จึงควรใช้เมื่อเข้าใจ Recovery path แล้ว.[3]

โค้ดเก็บชื่อช่อง · Railway เก็บค่าจริง

สไลด์ 6 — ข้อมูลจะอยู่ต่อ ต้องเลือกที่เก็บ

พื้นที่ไฟล์ปกติของ Service เป็น Ephemeral ไฟล์นอก Volume ไม่อยู่ข้าม Deployment ถ้าข้อมูลต้องอยู่ต่อให้ใช้ Volume.[1]

เลือกตามชนิดข้อมูล

Volume ให้ Directory แบบ Read/Write ที่ Mount เข้ากับ Service และใช้เก็บข้อมูลถาวร.[4] Railway PostgreSQL ช่วย Provision และ Connect Database ใน Project ได้ แต่เอกสารระบุว่าผู้ใช้ยังต้องดูแล Configuration, Backup และ Monitoring โดยเฉพาะ Production.[5]

ไฟล์ชั่วคราวไม่ใช่ฐานข้อมูล · เลือกที่เก็บก่อนเขียนข้อมูล

สไลด์ 7 — Service คุยกันหลังบ้าน

Service ใน Project Environment เดียวกันคุยกันผ่าน Private Network โดยใช้ Internal DNS และ Traffic ไม่ต้องออกสู่อินเทอร์เน็ตสาธารณะ.[6]

PUBLIC
ลูกค้า → api.example.com

PRIVATE
API → postgres.railway.internal
Worker → api.railway.internal

รูปแบบชื่อภายในคือ SERVICE_NAME.railway.internal.[6] PostgreSQL บน Railway เป็น Private โดยค่าเริ่มต้น ถ้าจะเชื่อมจากภายนอกต้องเปิด Public Access เพิ่ม ซึ่งสร้าง TCP Proxy และ External connection string.[5]

หลักที่ปลอดภัยกว่าคือเปิด Public เฉพาะ Service ที่ผู้ใช้ต้องเรียก และให้ API, Worker กับ Database คุยกันภายในเมื่อทำได้

เปิดสู่สาธารณะเท่าที่จำเป็น · ที่เหลือคุยกันหลังบ้าน

สไลด์ 8 — Deploy อย่างปลอดภัย

Railway รวบรวมการเปลี่ยน Component และ Configuration หลายประเภทเป็น Staged Changes เพื่อให้ Review Diff ก่อน Deploy.[8] แต่ Networking changes ยังมีผลทันที ตามข้อยกเว้นปัจจุบันของระบบ ไม่ได้รออยู่ใน Staged Changes.[8]

Safe flow ที่ควรใช้คือ

REVIEW STAGED CHANGES
→ DEPLOY
→ HEALTHCHECK 200?
  FAIL → KEEP PREVIOUS
  PASS → VERIFY REAL URL
         BAD RELEASE → ROLLBACK APP IMAGE + VARIABLES

Healthcheck เป็น Deployment Gate ไม่ใช่ระบบ Monitor ต่อเนื่อง หลัง Deployment Active แล้ว Railway จะไม่เรียก Endpoint นี้เพื่อเฝ้าระบบตลอดเวลา.[7]

ถ้า Release ใหม่พัง Railway Rollback จะนำ Docker Image และ Custom Variables ของ Deployment เก่ากลับมาเป็น Active Deployment ใหม่.[9] Rollback นี้ไม่ได้ย้อนข้อมูลหรือ Schema ใน Database จึงต้องแยกแผน Backup และ Migration rollback สำหรับข้อมูล

Service ที่ติด Volume มีข้อยกเว้น: Railway ไม่ให้สอง Deployment Mount Volume เดียวพร้อมกัน จึงอาจมี Downtime สั้นแม้ตั้ง Healthcheck.[7]

ตรวจ Change · ผ่าน Healthcheck · เปิดจริง · พร้อมย้อนกลับ

สไลด์ 9 — เลือก Railway เมื่อไหร่

ใช้ Railway เมื่อระบบต้องมีอย่างน้อยหนึ่งอย่างนี้

• Backend API ที่ต้องรันต่อเนื่อง
• Worker หรือ Queue consumer
• Cron job ที่ทำงานตามเวลา
• Database Service ใน Project เดียวกัน
• หลาย Service ที่ต้องคุยกันผ่าน Private Network
• Container หรือ Start command ที่ต้องควบคุมเอง

ถ้ามีเพียง Frontend หรือเว็บเนื้อหา บทที่ 16 และบทที่ 52 มีทางเลือก Hosting ที่ตรงกว่าและง่ายกว่าได้ แต่ระบบหนึ่งสามารถใช้หลาย Platform ร่วมกัน เช่น Frontend บน Vercel, Backend กับ Worker บน Railway และ Database บน Railway หรือ Supabase

ก่อน Deploy ตอบให้ครบ

1. Service ไหน Public และ Service ไหน Private 2. Variable ไหนเป็น Secret 3. ข้อมูลไหนอยู่ Ephemeral, Volume หรือ Database 4. Healthcheck Endpoint คืออะไร 5. ถ้ารุ่นใหม่พัง จะ Rollback โค้ดและกู้ข้อมูลอย่างไร

ลองทำเลย

เลือกโปรเจกต์เล็กที่มี Backend หนึ่งตัว แล้ววาด Architecture ก่อนโดยยังไม่ Deploy: Frontend → API → PostgreSQL ระบุ Public/Private, Variables, Storage, Healthcheck และ Rollback จากนั้นให้ Claude Code ตรวจว่า Application ฟัง PORT, มี /health และไม่ Commit Secret เมื่อ Contract ชัดแล้วให้ขอ OWNER APPROVAL ก่อนสร้าง Railway Project หรือเชื่อม GitHub จริง

Deploy ง่ายไม่พอ · ต้องรู้ว่าอะไร Public ข้อมูลอยู่ไหน และย้อนกลับอย่างไร

เช็คลิสต์ท้ายบท

• อธิบาย Service, Deployment, Variable, Volume และ Private Network ได้
• แยก Frontend, API, Worker, Cron และ Database เป็นหน้าที่ต่างกัน
• รู้ว่า Git push ต้องผ่าน CI, Build และ Healthcheck ก่อนถือว่าพร้อม
• Secret จริงไม่อยู่ใน Repository
• แยก Ephemeral filesystem, Volume และ PostgreSQL ได้
• เปิด Public เฉพาะ Service ที่จำเป็น
• เข้าใจว่า Healthcheck เป็น Deployment Gate ไม่ใช่ Continuous Monitoring
• เข้าใจว่า Rollback ย้อน Image/Variables แต่ไม่ย้อนข้อมูล Database
• มี Backup และ Migration rollback แยกจาก Application rollback
• ได้ Owner approval ก่อนสร้าง Project เชื่อม Repository หรือ Deploy จริง
• ตรวจ URL จริงและ Logs หลัง Deploy

Sources

[1] https://docs.railway.com/services — Railway Services [2] https://docs.railway.com/deployments/github-autodeploys — Railway GitHub Autodeploys [3] https://docs.railway.com/variables — Railway Variables [4] https://docs.railway.com/volumes — Railway Volumes [5] https://docs.railway.com/databases/postgresql — Railway PostgreSQL [6] https://docs.railway.com/networking/private-networking — Railway Private Networking [7] https://docs.railway.com/deployments/healthchecks — Railway Healthchecks [8] https://docs.railway.com/deployments/staged-changes — Railway Staged Changes [9] https://docs.railway.com/guides/roll-back-bad-deploy — Railway Rollback Guide