คู่มือ Deploy Python Django บน DigitalOcean Droplet 2026

A complete step-by-step guide to deploying a Python Django application on a DigitalOcean Droplet with Gunicorn, PostgreSQL, Nginx, and free Let's Encrypt SSL.

คู่มือนี้พาไล่ทีละขั้นตอนสำหรับ deploy เว็บแอป Python Django บน DigitalOcean Droplet ตั้งแต่เตรียมเครื่องด้วย virtualenv ติดตั้ง Gunicorn เชื่อมต่อ PostgreSQL ไปจนถึงตั้งค่า Nginx reverse proxy และเปิด SSL ฟรีด้วย Let's Encrypt พร้อมคำสั่งจริงที่ใช้รันได้ทันทีในแต่ละขั้น เหมาะสำหรับนักพัฒนาที่ต้องการควบคุม production environment เองแบบเต็มรูปแบบโดยไม่ผ่าน PaaS

เตรียม Droplet + Python virtualenv

ก่อนเริ่ม deploy Django ต้องเลือกขนาด Droplet ให้เหมาะกับโปรเจกต์ก่อน สำหรับแอปขนาดเล็กถึงกลางที่ยังไม่มีทราฟฟิกสูง Droplet ระดับ Basic แบบ $6/เดือน (1 GiB RAM, 1 vCPU, 25 GB SSD, 1,000 GiB transfer) เพียงพอสำหรับรันเว็บแอปพร้อม Gunicorn และ Nginx บนเครื่องเดียวกัน ถ้าคาดว่าจะมีผู้ใช้พร้อมกันมากขึ้นหรือรัน PostgreSQL อยู่บนเครื่องเดียวกันด้วย ควรขยับไปที่แผน $12/เดือน (2 GiB RAM, 1 vCPU, 50 GB SSD, 2,000 GiB transfer) เพื่อกันหน่วยความจำไม่พอ สำหรับผู้ใช้ในไทย เลือก region sgp1 (สิงคโปร์) จะได้ latency ต่ำที่สุด รองลงมาคือ blr1 (บังกาลอร์) เมื่อสร้าง Droplet เรียบร้อยพร้อม SSH key แล้ว ให้ SSH เข้าเครื่องด้วย ssh root@your_droplet_ip จากนั้นอัปเดตระบบก่อนเสมอด้วย apt update && apt upgrade -y ขั้นต่อไปคือสร้าง user แยกจาก root เพื่อความปลอดภัย ด้วยคำสั่ง adduser deployer แล้วเพิ่มสิทธิ์ sudo ให้ด้วย usermod -aG sudo deployer ก่อนสลับไปใช้งานด้วย su - deployer จากนั้นติดตั้ง Python และเครื่องมือที่จำเป็นสำหรับสร้าง virtual environment ด้วย sudo apt install python3-venv python3-pip build-essential -y Python 3 มาพร้อม Ubuntu 24.04 LTS อยู่แล้ว แต่ต้องติดตั้งแพ็กเกจ venv แยกต่างหาก เมื่อพร้อมแล้วให้สร้างโฟลเดอร์โปรเจกต์และ virtual environment แยกสำหรับแต่ละแอป ป้องกันปัญหาเวอร์ชันไลบรารีชนกันระหว่างหลายโปรเจกต์บน Droplet เดียวกัน ด้วยคำสั่ง mkdir -p ~/myproject && cd ~/myproject ตามด้วย python3 -m venv venv แล้วเปิดใช้งานด้วย source venv/bin/activate พรอมต์ terminal จะเปลี่ยนมามีคำว่า (venv) นำหน้า แสดงว่า virtualenv ทำงานอยู่ จากจุดนี้ทุกแพ็กเกจ Python ที่ pip install จะถูกเก็บแยกในโฟลเดอร์ venv ไม่ปนกับระบบหลัก ซึ่งเป็นแนวทางมาตรฐานสำหรับ deploy Django บน production เสมอ

Before deploying Django, choose a Droplet size appropriate for your project. For small to medium-sized applications with low traffic, a $6/month Basic Droplet (1 GiB RAM, 1 vCPU, 25 GB SSD, 1,000 GiB transfer) is sufficient to run a web application with Gunicorn and Nginx on the same machine. If you expect concurrent users or plan to run PostgreSQL on the same machine, consider upgrading to the $12/month plan (2 GiB RAM, 1 vCPU, 50 GB SSD, 2,000 GiB transfer) to avoid memory issues. For users in Thailand, choose the sgp1 region (Singapore) for the lowest latency, followed by blr1 (Bangalore). Once your Droplet is created with SSH key authentication, SSH into the machine with ssh root@your_droplet_ip. Always update the system first with apt update && apt upgrade -y. Next, create a separate non-root user for security using adduser deployer, then grant sudo privileges with usermod -aG sudo deployer. Switch to the new user with su - deployer. Install Python and essential tools for creating virtual environments: sudo apt install python3-venv python3-pip build-essential -y. Python 3 comes pre-installed with Ubuntu 24.04 LTS, but you need to install the venv package separately. When ready, create a project folder and virtual environment for each app to prevent library version conflicts between multiple projects on the same Droplet: mkdir -p ~/myproject && cd ~/myproject followed by python3 -m venv venv, then activate it with source venv/bin/activate. The terminal prompt will change to show (venv) at the beginning, confirming the virtual environment is active. From this point on, all Python packages installed via pip will be stored separately in the venv folder, not mixed with the system. This is the standard practice for deploying Django to production.

• Basic Droplet $6/เดือน (1 GiB RAM) พอสำหรับแอปเล็ก, $12/เดือน (2 GiB RAM) แนะนำถ้ารัน DB บนเครื่องเดียวกัน
• region sgp1 (สิงคโปร์) latency ต่ำสุดสำหรับผู้ใช้ไทย รองลงมาคือ blr1 (บังกาลอร์)
• สร้าง non-root user ด้วย adduser + usermod -aG sudo ก่อนใช้งานจริงเสมอ

ติดตั้ง Django + Gunicorn

เมื่อเปิดใช้งาน virtualenv แล้ว ติดตั้งแพ็กเกจหลักสามตัวที่จำเป็นสำหรับ deploy Django บน production ด้วยคำสั่งเดียว pip install django gunicorn psycopg2-binary โดย Django คือ framework หลัก Gunicorn คือ WSGI HTTP server ที่รันแอป Python จริงแทน development server ของ Django เอง และ psycopg2-binary คือ driver เชื่อมต่อ PostgreSQL จาก Python จากนั้นสร้างโปรเจกต์ Django ใหม่ในโฟลเดอร์ปัจจุบันด้วย django-admin startproject myproject . (สังเกตจุด . ท้ายคำสั่งเพื่อไม่ให้สร้างโฟลเดอร์ซ้อนอีกชั้น) ก่อนไปต่อ ควรทดสอบว่าแอปรันได้จริงด้วย development server ก่อนชั่วคราว ด้วย python manage.py runserver 0.0.0.0:8000 แล้วเปิด sudo ufw allow 8000 เพื่อทดสอบผ่าน browser จาก IP ของ Droplet แต่ขั้นตอนนี้ใช้เพื่อ debug เท่านั้น ห้ามปล่อยพอร์ต 8000 เปิดค้างไว้ตอน production เพราะ development server ไม่ได้ออกแบบมาให้รับทราฟฟิกจริงหรือรองรับหลาย request พร้อมกัน เมื่อทดสอบผ่านแล้วให้ปิดพอร์ตด้วย sudo ufw delete allow 8000 ขั้นตอนถัดไปคือทดสอบรันผ่าน Gunicorn แทน development server ด้วยคำสั่ง gunicorn --bind 0.0.0.0:8000 --workers 3 myproject.wsgi ตัวเลข workers ที่แนะนำทั่วไปคือ (2 × จำนวน CPU core) + 1 ซึ่งสำหรับ Droplet ระดับ 1 vCPU ตั้งไว้ที่ 3 workers ก็เพียงพอ ก่อนรันจริงต้องแก้ไฟล์ myproject/settings.py ในส่วน ALLOWED_HOSTS = ['your_domain.com', 'your_droplet_ip'] ไม่เช่นนั้น Django จะตอบกลับ 400 Bad Request ทันทีเมื่อเข้าถึงผ่านโดเมนหรือ IP จริง เพราะค่า default อนุญาตแค่ localhost เท่านั้น เมื่อ Gunicorn รันสำเร็จโดยไม่มี error ในขั้นตอนนี้ก็พร้อมย้ายไปตั้งค่าให้รันเป็น background service ถาวรด้วย systemd ในขั้นตอนถัดไป

1. pip install django gunicorn psycopg2-binary ติดตั้งครบ 3 ตัวในคำสั่งเดียว
2. django-admin startproject myproject . (มีจุดท้ายคำสั่งกันสร้างโฟลเดอร์ซ้อน)
3. ทดสอบด้วย gunicorn --bind ก่อน ตั้งค่า workers = (2×CPU)+1

เชื่อมต่อ PostgreSQL

PostgreSQL เป็นฐานข้อมูลที่แนะนำสำหรับ Django บน production มากกว่า SQLite ที่มากับ default เพราะรองรับการเขียนพร้อมกันหลาย process ได้ดีกว่ามาก ติดตั้งด้วย sudo apt install postgresql postgresql-contrib libpq-dev -y จากนั้นเข้าสู่ psql shell ในฐานะ user postgres ด้วย sudo -u postgres psql แล้วสร้างฐานข้อมูลและ user แยกสำหรับแอปนี้โดยเฉพาะ ไม่ควรใช้ user postgres โดยตรงจากแอป ด้วยคำสั่ง SQL ต่อเนื่อง CREATE DATABASE myproject_db; CREATE USER myproject_user WITH PASSWORD 'ตั้งรหัสผ่านที่แข็งแรง'; ALTER ROLE myproject_user SET client_encoding TO 'utf8'; GRANT ALL PRIVILEGES ON DATABASE myproject_db TO myproject_user; แล้วออกด้วย \q ต่อมาแก้ไฟล์ settings.py ในส่วน DATABASES ให้เปลี่ยนจาก sqlite3 default เป็น PostgreSQL ตามรูปแบบ DATABASES = {'default': {'ENGINE': 'django.db.backends.postgresql', 'NAME': 'myproject_db', 'USER': 'myproject_user', 'PASSWORD': 'ตั้งรหัสผ่านที่แข็งแรง', 'HOST': 'localhost', 'PORT': '5432'}} ในทางปฏิบัติควรดึงค่ารหัสผ่านมาจาก environment variable แทนการเขียนตรงในไฟล์ที่ commit เข้า git เสมอ เมื่อตั้งค่าเสร็จให้รัน migration ครั้งแรกด้วย python manage.py migrate เพื่อสร้างตารางระบบของ Django ในฐานข้อมูลใหม่ และ python manage.py createsuperuser เพื่อสร้างบัญชี admin สำหรับทีมที่ไม่ต้องการดูแล PostgreSQL เอง ไม่ว่าจะเป็นเรื่อง backup, patching หรือ replication DigitalOcean มี Managed PostgreSQL Database ให้เลือกใช้แทน เริ่มต้นที่ $15.15/เดือน สำหรับแผน 1 vCPU/1 GiB RAM พร้อมพื้นที่เก็บข้อมูล 10-30 GiB ซึ่งมาพร้อม automated backup และแยก instance ออกจาก Droplet ที่รันเว็บแอป ช่วยลดภาระงานดูแลระบบและลดความเสี่ยงเวลาต้อง resize เครื่องเว็บโดยไม่กระทบฐานข้อมูล (ข้อมูลราคา ณ กรกฎาคม 2026 — ตรวจสอบราคาล่าสุดที่เว็บผู้ให้บริการ)

• ติดตั้ง PostgreSQL: apt install postgresql postgresql-contrib libpq-dev
• สร้าง DB+user แยกเฉพาะแอป ห้ามใช้ user postgres ตรงจากแอป
• แก้ ENGINE เป็น django.db.backends.postgresql ใน settings.py แล้ว migrate
• ทางเลือก Managed PostgreSQL เริ่ม $15.15/เดือน ถ้าไม่อยากดูแลเอง

ตั้งค่า Nginx Reverse Proxy

เมื่อ Gunicorn รันแอปได้แล้ว ขั้นตอนถัดไปคือให้มันทำงานเป็น background service ถาวรด้วย systemd แทนการรันคำสั่งค้างไว้ใน terminal สร้างไฟล์ socket ที่ /etc/systemd/system/gunicorn.socket และไฟล์ service ที่ /etc/systemd/system/gunicorn.service โดยไฟล์ service มีเนื้อหาประมาณ [Service] User=deployer Group=www-data WorkingDirectory=/home/deployer/myproject ExecStart=/home/deployer/myproject/venv/bin/gunicorn --workers 3 --bind unix:/run/gunicorn.sock myproject.wsgi:application จากนั้นเปิดใช้งานด้วย sudo systemctl start gunicorn.socket && sudo systemctl enable gunicorn.socket การใช้ unix socket แทน TCP port ในขั้นตอนนี้ปลอดภัยกว่าเพราะไม่เปิดพอร์ตออกสู่อินเทอร์เน็ตโดยตรง ติดตั้ง Nginx ด้วย sudo apt install nginx -y แล้วสร้างไฟล์ config ใหม่ที่ /etc/nginx/sites-available/myproject เนื้อหาหลักคือ server block ที่ proxy request มาที่ socket ของ Gunicorn เช่น server { listen 80; server_name your_domain.com; location = /favicon.ico { access_log off; log_not_found off; } location /static/ { root /home/deployer/myproject; } location / { include proxy_params; proxy_pass http://unix:/run/gunicorn.sock; } } จากนั้นเปิดใช้งาน config นี้ด้วยการสร้าง symlink sudo ln -s /etc/nginx/sites-available/myproject /etc/nginx/sites-enabled/ ตรวจสอบ syntax ก่อนเสมอด้วย sudo nginx -t ถ้าไม่มี error ให้ restart ด้วย sudo systemctl restart nginx ขั้นตอนสุดท้ายของส่วนนี้คือเปิด firewall ให้รับทราฟฟิกเว็บ ด้วย sudo ufw allow 'Nginx Full' ซึ่งเปิดทั้งพอร์ต 80 และ 443 พร้อมกัน แล้วปิดกฎเก่าที่เปิดพอร์ต 8000 ไว้ทดสอบตอนต้นถ้ายังไม่ได้ปิด จุดที่มักพลาดบ่อยคือลืมเช็คสิทธิ์ของโฟลเดอร์โปรเจกต์ Nginx รันด้วย user www-data ต้องมีสิทธิ์ execute เข้าถึง home directory ของ user deployer ได้ ถ้าเจอ 502 Bad Gateway ให้ตรวจสอบก่อนว่า gunicorn.socket ทำงานอยู่จริงด้วย sudo systemctl status gunicorn.socket และดู log ด้วย journalctl -u gunicorn

• ตั้ง gunicorn เป็น systemd service ผูกกับ unix socket ไม่ใช้ TCP port ตรง
• Nginx server block proxy_pass ไปที่ unix:/run/gunicorn.sock
• ทดสอบ config ด้วย nginx -t ก่อน restart เสมอ

Static Files และ SSL

ที่พบบ่อยในทางปฏิบัติ — django ไม่ serve ไฟล์ static (CSS/JS/รูปภาพ) เองตอน production ต้องให้ Nginx ทำหน้าที่นี้แทนเพื่อประสิทธิภาพที่ดีกว่า ก่อนอื่นกำหนดโฟลเดอร์รวมไฟล์ static ในไฟล์ settings.py ด้วย STATIC_URL = 'static/' และ STATIC_ROOT = BASE_DIR / 'staticfiles' แล้วรันคำสั่งรวบรวมไฟล์ static ทั้งหมดจากทุก app เข้าโฟลเดอร์เดียวด้วย python manage.py collectstatic ขั้นตอนนี้ต้องรันใหม่ทุกครั้งที่แก้ไฟล์ static หรือ deploy โค้ดใหม่ ไม่เช่นนั้นหน้าเว็บจะโหลดขึ้นแต่ไม่มี CSS ใช้งาน จากนั้นตรวจสอบว่า location block ใน Nginx config ที่ /static/ ชี้ไปที่โฟลเดอร์ staticfiles ตรงกับ path จริงบนเครื่อง ขั้นตอนถัดมาคือเปิดใช้ SSL ฟรีด้วย Let's Encrypt ผ่าน Certbot ติดตั้งด้วย sudo apt install certbot python3-certbot-nginx -y จากนั้นออกใบรับรองพร้อมตั้งค่า Nginx ให้อัตโนมัติด้วยคำสั่งเดียว sudo certbot --nginx -d your_domain.com -d www.your_domain.com Certbot จะแก้ config Nginx ให้เองเพื่อ redirect HTTP ไป HTTPS และตั้ง auto-renew ผ่าน systemd timer ที่ทำงานอยู่เบื้องหลังโดยไม่ต้องตั้งค่าเพิ่ม ตรวจสอบว่า timer ทำงานอยู่ด้วย sudo systemctl status certbot.timer ก่อนใบรับรองหมดอายุทุก 90 วัน ระบบจะต่ออายุให้อัตโนมัติ หลังจากมี SSL ใช้งานแล้ว ต้องกลับไปแก้ settings.py เพิ่มเติมสำหรับ production จริง ปิด DEBUG = False เสมอ เพิ่ม SECURE_SSL_REDIRECT = True เพื่อบังคับ redirect ไป HTTPS และ CSRF_TRUSTED_ORIGINS = ['https://your_domain.com'] สำหรับ Django เวอร์ชันใหม่ที่ตรวจสอบ origin ของฟอร์มเข้มงวดขึ้น การเปิด DEBUG=True ค้างไว้บน production เป็นความผิดพลาดด้านความปลอดภัยที่พบบ่อยที่สุด เพราะจะเปิดเผย stack trace, path ของเซิร์ฟเวอร์ และค่า setting ทั้งหมดให้ผู้เข้าเว็บเห็นเมื่อเกิด error

• STATIC_ROOT + collectstatic ต้องรันใหม่ทุกครั้งที่แก้ static/deploy โค้ดใหม่
• certbot --nginx -d domain ออก SSL ฟรีพร้อมตั้งค่า redirect อัตโนมัติ
• certbot.timer ต่ออายุใบรับรองอัตโนมัติทุก 90 วัน ไม่ต้องตั้ง cron เอง
• production ต้องปิด DEBUG=False และตั้ง SECURE_SSL_REDIRECT=True เสมอ

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

แนวทาง deploy Django บน Droplet เอง (self-managed) แบบที่อธิบายมาทั้งหมดเหมาะกับทีมที่ต้องการควบคุมสภาพแวดล้อมเต็มรูปแบบ ต้องการติดตั้งไลบรารีระบบเฉพาะทาง (เช่น GDAL สำหรับ GeoDjango, ffmpeg สำหรับประมวลผลวิดีโอ) หรือมีงบจำกัดและต้องการควบคุมต้นทุนแบบคาดเดาได้ ต่างจาก App Platform ที่เป็น PaaS จัดการ infrastructure ให้อัตโนมัติแต่ราคาแพงกว่าต่อสเปกเดียวกันและปรับแต่ง environment ได้จำกัดกว่า สำหรับโปรเจกต์เริ่มต้นหรือ MVP ที่ทราฟฟิกยังน้อย Droplet ระดับ $6/เดือน (1 GiB RAM) รันได้ทั้ง Django, Gunicorn, Nginx และ PostgreSQL บนเครื่องเดียวพร้อมกันได้สบาย เมื่อแอปเริ่มมีผู้ใช้งานจริงและทราฟฟิกเพิ่มขึ้น สัญญาณที่บอกว่าถึงเวลาขยับขึ้นแผนคือ RAM ใช้เกิน 80% ต่อเนื่อง หรือ response time ช้าลงตอนมีคนใช้พร้อมกันหลายคน ให้ resize ขึ้นไปที่ $12/เดือน (2 GiB) หรือ $24/เดือน (4 GiB, 2 vCPU) ตามลำดับ ถ้าทราฟฟิกโตจนเครื่องเดียวรับไม่ไหวแล้ว ขั้นต่อไปคือกระจายโหลดในแนวนอน (horizontal scaling) ด้วยการรันหลาย Droplet พร้อม Load Balancer ที่เริ่มต้น $12/เดือน วางไว้หน้าเครื่องเว็บทั้งหมด สำหรับฐานข้อมูล ถ้าเริ่มต้นจากการติดตั้ง PostgreSQL เองบน Droplet ตามคู่มือนี้ แนะนำให้ย้ายไปใช้ Managed PostgreSQL (เริ่ม $15.15/เดือน) เมื่อทีมเริ่มไม่มีเวลาดูแล patching และ backup เอง หรือเมื่อฐานข้อมูลกลายเป็นจุดคอขวดของระบบและต้องการแยก resource ออกจากเครื่องเว็บอย่างชัดเจน ซึ่งช่วยให้ resize เครื่องเว็บแอปได้อิสระโดยไม่กระทบข้อมูล กรณีทั่วไปที่เหมาะกับแนวทางนี้มากที่สุดคือทีมพัฒนาภายในองค์กร, เอเจนซี่ที่ต้อง deploy หลายโปรเจกต์ลูกค้าแยกกัน หรือ SaaS ขนาดเล็กที่ยังไม่ต้องการความซับซ้อนของ Kubernetes ผู้ที่สนใจเริ่มทดลองสามารถสมัครและรับเครดิตเริ่มต้นได้ที่ รับ $200 Free Credit → (ข้อมูลราคาทั้งหมดในบทความนี้อ้างอิง ณ กรกฎาคม 2026 — ควรตรวจสอบราคาล่าสุดที่เว็บผู้ให้บริการก่อนตัดสินใจ)

• เหมาะกับทีมที่ต้องการควบคุม environment เต็มรูปแบบ/ไลบรารีระบบเฉพาะทาง
• RAM ใช้เกิน 80% ต่อเนื่อง = สัญญาณควร resize ขึ้นแผนถัดไป ($12 หรือ $24/เดือน)
• ทราฟฟิกเกินเครื่องเดียวรับไหว = กระจายด้วย Load Balancer เริ่ม $12/เดือน
• ทีมไม่มีเวลาดูแล DB เอง = ย้ายไป Managed PostgreSQL เริ่ม $15.15/เดือน

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

ตรงนี้สำคัญ — ข้อผิดพลาดที่เจอบ่อยที่สุดอันดับหนึ่งคือ ALLOWED_HOSTS ไม่ได้ตั้งค่า ทำให้เข้าเว็บผ่านโดเมนหรือ IP จริงแล้วเจอ 400 Bad Request ทั้งที่ development server รันได้ปกติตอนทดสอบบนเครื่อง แก้ได้ด้วยการเพิ่มโดเมนและ IP ของ Droplet เข้า list ใน settings.py ให้ครบ อันดับสองคือลืมปิด DEBUG = True ก่อน deploy จริง ซึ่งนอกจากเสี่ยงด้านความปลอดภัยแล้วยังทำให้ error page แสดง stack trace เต็มรูปแบบให้สาธารณะเห็น ควรใช้ environment variable แยกค่า DEBUG ระหว่าง dev กับ production แทนการแก้ไฟล์ตรงทุกครั้ง ปัญหาที่พบบ่อยรองลงมาคือ 502 Bad Gateway ซึ่งเกิดจาก Gunicorn ไม่ได้รันอยู่ หรือ Nginx เข้าถึง unix socket ไม่ได้เพราะสิทธิ์ไฟล์ผิด ตรวจสอบด้วย sudo systemctl status gunicorn.socket และดู log ล่าสุดด้วย journalctl -u gunicorn -n 50 เกือบทุกครั้งสาเหตุคือ path ใน ExecStart ของไฟล์ service ผิด หรือ virtualenv ไม่ได้ activate ตอนเขียน path ของ gunicorn binary ให้ตรง อีกจุดที่พลาดกันบ่อยคือติดตั้ง psycopg2-binary ไม่ผ่านเพราะขาด libpq-dev และ build tools ในระบบ ซึ่งแก้ได้ด้วยการติดตั้ง build-essential libpq-dev ก่อน pip install ปัญหาเรื่อง static files ก็พบได้บ่อยเช่นกัน หน้าเว็บขึ้นแต่ไม่มี CSS ทั้งที่ทุกอย่างดูรันปกติ สาเหตุมักมาจากลืมรัน python manage.py collectstatic หลัง deploy โค้ดใหม่ หรือ path ใน location /static/ ของ Nginx config ไม่ตรงกับ STATIC_ROOT จริง อีกจุดที่ควรระวังคือลืมปิดพอร์ต 8000 ที่เปิดไว้ทดสอบตอนต้นด้วย ufw ทิ้งไว้ถาวร ซึ่งเปิดช่องให้เข้าถึง development server ได้ตรงโดยไม่ผ่าน Nginx และสุดท้ายคือลืม migrate ฐานข้อมูลหลัง pull โค้ดใหม่ที่มี model เปลี่ยนแปลง ทำให้เจอ error คอลัมน์ไม่มีอยู่จริงตอนรันจริงทั้งที่โค้ดถูกต้องแล้ว ควรใส่ python manage.py migrate เป็นส่วนหนึ่งของ deploy script เสมอไม่ใช่ขั้นตอนแยกที่ต้องจำเอง

• ALLOWED_HOSTS ว่าง/ไม่ครบ = 400 Bad Request บนโดเมน/IP จริง
• DEBUG=True ค้างบน production = เสี่ยง security เปิดเผย stack trace
• 502 Bad Gateway ส่วนใหญ่มาจาก path ผิดใน gunicorn.service หรือสิทธิ์ socket
• ลืม collectstatic / migrate หลัง deploy โค้ดใหม่ = static หายหรือ error คอลัมน์

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

เก็บค่าที่เป็นความลับทั้งหมด เช่น SECRET_KEY, รหัสผ่านฐานข้อมูล, API key ไว้ใน environment variable ผ่านไฟล์ .env ร่วมกับไลบรารีอย่าง python-dotenv หรือ django-environ แทนการเขียนตรงในไฟล์ settings.py และต้องเพิ่ม .env เข้า .gitignore ตั้งแต่วันแรก ไม่ให้หลุดขึ้น git repository เด็ดขาด ควร pin เวอร์ชันไลบรารีทุกตัวด้วย pip freeze > requirements.txt เพื่อให้ environment บน production ตรงกับที่ทดสอบไว้เป๊ะ ป้องกันปัญหา dependency เวอร์ชันใหม่ทำโค้ดพังโดยไม่รู้ตัว ตั้งค่า systemd ให้ gunicorn.service รีสตาร์ทอัตโนมัติเมื่อ crash และรันขึ้นเองหลัง reboot ด้วย Restart=always ในไฟล์ service และ sudo systemctl enable gunicorn เปิด firewall เฉพาะพอร์ตที่จำเป็นจริงด้วย ufw และพิจารณาติดตั้ง fail2ban เพิ่มเพื่อป้องกันการ brute-force SSH จากภายนอก สำหรับ deploy โค้ดใหม่แต่ละครั้งควรทำเป็นลำดับขั้นตอนคงที่เสมอ ได้แก่ pull โค้ด, ติดตั้ง dependency ใหม่ถ้ามี, รัน migrate, รัน collectstatic แล้วค่อย restart gunicorn ท้ายสุด เพื่อลด downtime และป้องกันลืมขั้นตอนใดขั้นตอนหนึ่ง ก่อนทำการเปลี่ยนแปลงใหญ่ เช่น อัปเกรด Django เวอร์ชันหรือแก้ schema ฐานข้อมูล ควรสร้าง Droplet Snapshot ไว้ก่อนเสมอ ซึ่งมีค่าใช้จ่ายเพียง $0.06/GiB ต่อเดือน ถูกกว่าความเสียหายจากการต้อง rebuild ระบบใหม่มากถ้าเกิดปัญหาระหว่างอัปเดต เปิดใช้ DigitalOcean Monitoring ซึ่งฟรีและมาพร้อม 1 Uptime Check ฟรีต่อบัญชี เพื่อรู้ทันทีเมื่อ Droplet ใช้ RAM หรือ disk สูงผิดปกติ และสุดท้ายควรแยก settings.py เป็นไฟล์ dev/production ชัดเจน หรือใช้ตัวแปร environment ควบคุมพฤติกรรมต่างกันระหว่างสภาพแวดล้อม เพื่อไม่ให้ค่า debug หรือค่าทดสอบหลุดไปโดนใช้งานจริงโดยไม่ตั้งใจ

• เก็บ secret ใน .env + python-dotenv/django-environ ห้าม commit เข้า git
• pip freeze > requirements.txt pin เวอร์ชันให้ตรง dev/production
• systemd Restart=always ให้ gunicorn ฟื้นเองเมื่อ crash/reboot
• สร้าง Droplet Snapshot ($0.06/GiB/เดือน) ก่อนเปลี่ยนแปลงใหญ่เสมอ

รับ $200 Free Credit →