คู่มือ Self-host GitLab บน DigitalOcean Droplet 2026

A practical, command-by-command guide to self-hosting GitLab Community Edition on a DigitalOcean Droplet, from sizing to backups.

GitLab Community Edition เป็นทางเลือกสำหรับทีมที่ต้องการเก็บซอร์สโค้ดและ CI/CD pipeline ไว้บนโครงสร้างพื้นฐานของตัวเอง แทนที่จะพึ่ง GitLab.com หรือ GitHub การรัน GitLab บน DigitalOcean Droplet ทำได้ทั้งผ่าน Marketplace 1-Click App และ Docker แต่ต้องเข้าใจข้อจำกัดด้านทรัพยากรของ GitLab เองก่อนเลือกสเปก เพราะเป็นระบบที่รวม Postgres, Redis, Sidekiq และ Gitaly ไว้ในเครื่องเดียว

สเปก Droplet ขั้นต่ำสำหรับ GitLab CE

เอกสารทางการของ GitLab ระบุสเปกขั้นต่ำสำหรับติดตั้งแบบ Omnibus ไว้ที่ 4 GB RAM และ 2 CPU core สำหรับองค์กรขนาดเล็กที่มีผู้ใช้ไม่เกินประมาณ 20 คน แต่ตัว GitLab เองก็ระบุชัดว่าตัวเลขนี้เป็น "ขั้นต่ำที่พอรันได้" ไม่ใช่ค่าที่แนะนำสำหรับการใช้งานจริง เพราะกระบวนการ gitlab-ctl reconfigure และการรัน Puma, Sidekiq, PostgreSQL, Redis, Gitaly พร้อมกันบนเครื่องเดียวกินหน่วยความจำสูงกว่าที่คิด โดยเฉพาะช่วง reconfigure ครั้งแรกหรือตอนรัน CI job ที่หนัก GitLab จึงแนะนำให้ใช้ 8 GB RAM ขึ้นไปเป็นมาตรฐานที่ปลอดภัยกว่าสำหรับ instance เดี่ยว (single-node) ที่ใช้งานจริง ไม่ใช่แค่ทดลอง เมื่อจับคู่กับตาราง Droplet ของ DigitalOcean แผน 4 GiB RAM / 2 vCPU / 80 GB SSD / 4,000 GiB transfer ราคา $24/เดือน ถือว่าตรงกับสเปกขั้นต่ำที่ GitLab ระบุไว้พอดี แต่จะรู้สึกอึดอัดเมื่อมีผู้ใช้พร้อมกันหลายคนหรือรัน CI runner ร่วมเครื่อง ส่วนแผน 8 GiB RAM / 4 vCPU / 160 GB SSD / 5,000 GiB transfer ราคา $48/เดือน เป็นจุดที่เหมาะสมกว่าสำหรับทีมขนาด 10-20 คนที่ใช้งานจริงทุกวัน เพราะมี headroom ให้ Sidekiq queue และ PostgreSQN cache ทำงานได้โดยไม่ swap ตลอดเวลา สำหรับพื้นที่เก็บข้อมูล นอกจาก SSD ที่ติดมากับ Droplet แล้ว repository, CI artifact และ Container Registry มักโตเร็วกว่าที่คาด การเผื่อพื้นที่ด้วย DigitalOcean Volumes ที่คิดราคา $0.10 ต่อ GiB ต่อเดือนแล้วย้าย /var/opt/gitlab/git-data ไปไว้บน Volume แยกต่างหาก ช่วยให้ resize พื้นที่ในอนาคตโดยไม่ต้อง migrate ทั้ง Droplet

GitLab's official documentation specifies a minimum of 4 GB RAM and 2 CPU cores for an Omnibus installation, suited for small teams with up to roughly 20 users. However, GitLab itself is clear that this number represents "the bare minimum to run"—not a recommended spec for actual production use. The gitlab-ctl reconfigure process and running Puma, Sidekiq, PostgreSQL, Redis, and Gitaly concurrently on a single machine consume far more memory than expected. Especially during initial reconfiguration or when running heavy CI jobs, GitLab recommends at least 8 GB RAM as the safer standard for a single-node instance meant for real-world use, not just testing. Comparing this to DigitalOcean's Droplet tiers, the 4 GiB RAM / 2 vCPU / 80 GB SSD / 4,000 GiB transfer plan at $24/month exactly matches GitLab's stated minimum, but feels constrained with concurrent users or CI runners. The 8 GiB RAM / 4 vCPU / 160 GB SSD / 5,000 GiB transfer plan at $48/month strikes a better balance for teams of 10–20 actively using it daily, giving Sidekiq and PostgreSQL enough headroom to avoid constant swapping. For storage, beyond the SSD included with the Droplet, repositories, CI artifacts, and Container Registry images grow faster than anticipated. Provisioning DigitalOcean Volumes at $0.10 per GiB per month and moving /var/opt/gitlab/git-data there lets you resize independently without migrating the entire Droplet.

• GitLab ระบุขั้นต่ำ 4 GB RAM + 2 vCPU สำหรับผู้ใช้ไม่เกิน ~20 คน แต่แนะนำ 8 GB ขึ้นไปสำหรับการใช้งานจริง
• Droplet 4 GiB/2 vCPU/80 GB SSD ราคา $24/เดือน = ตรงขั้นต่ำพอดี เหมาะกับทดลองหรือทีมเล็กมาก
• Droplet 8 GiB/4 vCPU/160 GB SSD ราคา $48/เดือน = จุดสมดุลสำหรับทีมใช้งานจริงทุกวัน
• แยก repository/artifact ไปเก็บบน DigitalOcean Volumes ($0.10/GiB/เดือน) เพื่อ resize พื้นที่ได้อิสระจากตัว Droplet

ติดตั้งผ่าน Marketplace 1-Click App หรือ Docker

ข้อที่มักถูกมองข้ามคือ digitalOcean มี GitLab CE อยู่ในหมวด Marketplace ให้เลือกตอนสร้าง Droplet ได้เลย โดยระบบจะติดตั้ง GitLab แบบ Omnibus package บน Ubuntu ให้อัตโนมัติ ข้อดีคือไม่ต้องพิมพ์คำสั่งติดตั้งเอง เปิดเครื่องมาก็มี GitLab พร้อมใช้ทันทีหลังรอ cloud-init ทำงานเสร็จประมาณ 5-10 นาที เมื่อ SSH เข้าไปครั้งแรกจะเจอไฟล์ตั้งค่า instructions บอกให้ตั้ง external URL ผ่าน /etc/gitlab/gitlab.rb แล้วรัน gitlab-ctl reconfigure เพื่อ apply การตั้งค่า ทางเลือกที่สองคือติดตั้งผ่าน Docker ซึ่งเหมาะกับคนที่อยากควบคุม volume, network และ resource limit เองมากกว่า โดยตัว docker-compose.yml จะมี service ชื่อ gitlab ใช้ image ทางการ gitlab/gitlab-ce:latest กำหนด hostname เป็นโดเมนจริงตั้งแต่แรก แมปพอร์ต '80:80', '443:443' และ '22:22' (หรือเปลี่ยนพอร์ต SSH host ถ้า Droplet ใช้พอร์ต 22 สำหรับ SSH เข้าเครื่องอยู่แล้ว) พร้อม mount volume สามจุดคือ /etc/gitlab, /var/log/gitlab และ /var/opt/gitlab ไปยัง path บน host เพื่อให้ข้อมูลไม่หายเมื่อ container ถูก recreate ทั้งสองแบบสุดท้ายแล้วรันซอฟต์แวร์ตัวเดียวกันคือ Omnibus GitLab เพียงแต่ Marketplace ติดตั้งลง OS โดยตรงส่วน Docker รันแยกใน container จึงย้ายเครื่องหรือ backup ทั้งชุดได้ง่ายกว่าด้วยการ copy volume เมื่อ container พร้อมใช้งานให้ตั้งรหัสผ่าน root ครั้งแรกผ่านหน้าเว็บ หรือดูรหัสผ่านชั่วคราวที่ระบบสุ่มไว้ในไฟล์ /etc/gitlab/initial_root_password ซึ่งจะถูกลบอัตโนมัติภายใน 24 ชั่วโมงแรก

• Marketplace 1-Click App ติดตั้ง Omnibus GitLab บน Ubuntu อัตโนมัติ พร้อมใช้ใน 5-10 นาที
• ติดตั้งด้วย Docker ใช้ image gitlab/gitlab-ce:latest แมปพอร์ต 80/443/22 และ mount volume /etc/gitlab, /var/log/gitlab, /var/opt/gitlab
• ทั้งสองวิธีคือ Omnibus GitLab ตัวเดียวกัน ต่างกันที่รันบน OS ตรงหรือใน container
• รหัสผ่าน root เริ่มต้นอยู่ที่ /etc/gitlab/initial_root_password ถูกลบอัตโนมัติภายใน 24 ชั่วโมง

ตั้งค่าโดเมน + SSL

ก่อนตั้งค่า SSL ต้องชี้ DNS record ประเภท A ของโดเมนหรือ subdomain เช่น git.example.com ไปยัง IP ของ Droplet ให้เสร็จและรอ propagate ให้เรียบร้อยก่อน เพราะขั้นตอนขอใบรับรอง Let's Encrypt ต้องยืนยันความเป็นเจ้าของโดเมนผ่าน HTTP challenge จาก IP นั้นจริง สำหรับการติดตั้งแบบ Omnibus (ทั้ง Marketplace และ Docker) ให้แก้ไฟล์ /etc/gitlab/gitlab.rb กำหนด external_url 'https://git.example.com' แล้วเปิดใช้ Let's Encrypt ในตัวด้วยการตั้งค่า letsencrypt['enable'] = true จากนั้นรัน gitlab-ctl reconfigure อีกครั้ง ระบบจะขอและติดตั้งใบรับรองให้อัตโนมัติ รวมถึงตั้ง cron job ต่ออายุใบรับรองให้ด้วย ไม่ต้องติดตั้ง Certbot แยกเหมือนเว็บทั่วไป ข้อควรระวังคือถ้า Droplet อยู่หลัง Cloudflare แบบเปิด proxy (orange cloud) การขอใบรับรองผ่าน HTTP challenge อาจล้มเหลวเพราะ IP ที่ Let's Encrypt เห็นไม่ใช่ IP จริงของ Droplet วิธีแก้คือปิด proxy ชั่วคราวระหว่างขอใบรับรองครั้งแรก หรือใช้ DNS challenge แทน สำหรับคนที่ deploy GitLab ผ่าน Docker และมี Nginx หรือ reverse proxy อื่นอยู่หน้า container อยู่แล้ว ควรปิดการจัดการ SSL ในตัวของ GitLab แล้วให้ reverse proxy เป็นคน terminate SSL แทน เพื่อไม่ให้ config สองชั้นตีกัน หลังตั้งค่าเสร็จควรทดสอบ push/pull ผ่าน HTTPS และ SSH เพื่อยืนยันว่า port 22 (หรือพอร์ตที่กำหนดไว้สำหรับ git over SSH) ยังใช้งานได้ปกติ เพราะบางครั้งการเปลี่ยน external_url ไปพร้อมกับเปลี่ยนพอร์ต SSH ทำให้ client เดิมต่อไม่ติด

• ชี้ A record ของโดเมนไป Droplet IP และรอ propagate ก่อนขอใบรับรองเสมอ
• ตั้ง external_url และ letsencrypt['enable'] = true ใน gitlab.rb แล้วรัน gitlab-ctl reconfigure
• ถ้าใช้ Cloudflare proxy (orange cloud) ต้องปิดชั่วคราวหรือใช้ DNS challenge ตอนขอใบรับรองครั้งแรก
• ถ้ามี reverse proxy หน้า Docker container อยู่แล้ว ให้ปิด SSL ในตัวของ GitLab เพื่อไม่ให้ config ซ้อนกัน

Backup และ Restore GitLab

GitLab มีเครื่องมือ backup ในตัวผ่าน Rake task คำสั่งหลักคือ gitlab-rake gitlab:backup:create ซึ่งจะรวม repository, ฐานข้อมูล, uploads, CI artifact และ registry image (ถ้าตั้งค่าให้รวมไว้) เป็นไฟล์ tar เดียวเก็บไว้ที่ /var/opt/gitlab/backups ตามค่าเริ่มต้น ข้อควรรู้คือไฟล์ backup นี้ไม่ได้รวมไฟล์ตั้งค่าและ secret key ไว้ด้วย ต้อง backup แยกสองไฟล์เพิ่มเติมคือ /etc/gitlab/gitlab.rb และ /etc/gitlab/gitlab-secrets.json เพราะถ้าไฟล์ secrets หายจะถอดรหัส credential ที่เก็บในฐานข้อมูลเดิมไม่ได้แม้จะ restore backup สำเร็จก็ตาม การ restore ทำผ่าน gitlab-rake gitlab:backup:restore BACKUP=timestamp โดยระบุ timestamp ที่อยู่ในชื่อไฟล์ backup และต้องมั่นใจว่าเวอร์ชัน GitLab ที่ restore ตรงกับเวอร์ชันตอนสร้าง backup ทุกครั้ง เพราะ schema ฐานข้อมูลเปลี่ยนไปตามเวอร์ชัน การ restore ข้ามเวอร์ชันมักล้มเหลว สำหรับการทำงานจริงควรตั้ง cron job รัน backup อัตโนมัติทุกวันแล้วคัดลอกไฟล์ backup ออกจาก Droplet ทันที ไม่เก็บไว้บนเครื่องเดียวกับ production เพราะถ้า Droplet มีปัญหา backup ที่อยู่บนดิสก์เดียวกันก็จะหายไปด้วย ตัวเลือกที่ใช้ได้จริงคือ sync ไฟล์ไปยัง DigitalOcean Spaces ด้วยเครื่องมืออย่าง s3cmd หรือ rclone หรือใช้ Droplet Snapshot ราคา $0.06 ต่อ GiB ต่อเดือนเก็บภาพรวมทั้งเครื่องเป็นระยะ โดยเฉพาะก่อนอัปเกรดเวอร์ชันใหญ่ทุกครั้ง เพราะ snapshot ให้ rollback ทั้งระบบกลับมาได้เร็วกว่าการ restore backup ทีละส่วน

• สั่ง backup ด้วย gitlab-rake gitlab:backup:create ไฟล์จะอยู่ใน /var/opt/gitlab/backups
• backup ไม่รวมไฟล์ตั้งค่า ต้องเก็บ gitlab.rb และ gitlab-secrets.json แยกต่างหากเสมอ
• restore ด้วย gitlab-rake gitlab:backup:restore BACKUP=timestamp ต้องใช้ GitLab เวอร์ชันเดียวกับตอนสร้าง backup

ข้อควรระวังเรื่องทรัพยากร

จุดที่คนเพิ่งเริ่ม self-host GitLab มักคาดไม่ถึงคือ Omnibus package รวมบริการหลายตัวไว้ในเครื่องเดียวกันทั้งหมด ได้แก่ PostgreSQL, Redis, Sidekiq สำหรับ background job, Gitaly สำหรับจัดการ repository, Puma สำหรับเสิร์ฟหน้าเว็บ และถ้าเปิด Container Registry ก็มีอีกบริการหนึ่งเพิ่มเข้ามา ทุกตัวแย่งหน่วยความจำและ CPU กันบน Droplet เดียว บน Droplet ขนาด 4 GB การรัน CI/CD job หนักๆ พร้อมกับมีคนใช้งานเว็บอยู่มักทำให้ Sidekiq queue ค้างหรือหน้าเว็บช้าลงอย่างเห็นได้ชัด อาการที่พบบ่อยที่สุดคือระบบเริ่ม swap หนักจนโหลดเว็บช้าเป็นวินาที หรือ gitlab-ctl reconfigure ค้างระหว่างขั้นตอน ถ้าใช้ GitLab Runner สำหรับรัน CI/CD ควรแยก Runner ไปอยู่อีก Droplet ต่างหาก ไม่รันร่วมกับ GitLab server หลัก เพราะ CI job อาจกิน CPU เต็มจนกระทบผู้ใช้ที่กำลัง push/pull code อยู่พร้อมกัน อีกจุดที่ต้องระวังคือพื้นที่ดิสก์ ไม่ใช่แค่ repository ที่โต แต่ CI artifact, log และ Container Registry image สะสมเร็วกว่าที่คาดไว้มาก ถ้าไม่ตั้ง retention policy ลบ artifact เก่าอัตโนมัติ ดิสก์อาจเต็มโดยไม่รู้ตัวและทำให้ GitLab หยุดทำงานกะทันหัน สุดท้ายคือการอัปเกรดเวอร์ชัน GitLab มีข้อจำกัดเรื่อง upgrade path ที่ต้องอัปเกรดเรียงตามลำดับเวอร์ชันที่ GitLab กำหนดไว้ ข้ามเวอร์ชันมากเกินไปในครั้งเดียวมีความเสี่ยงที่ migration ฐานข้อมูลจะล้มเหลว ควรอ่าน release note และวางแผนอัปเกรดทีละขั้นแทนที่จะปล่อยค้างไว้นานแล้วอัปเกรดรวดเดียว

• PostgreSQL, Redis, Sidekiq, Gitaly, Puma รันรวมกันบนเครื่องเดียว แย่งทรัพยากรกันเมื่อโหลดสูง
• แยก GitLab Runner ไปอีก Droplet ต่างหาก ไม่รันร่วมกับ GitLab server หลัก
• ตั้ง retention policy ลบ CI artifact และ registry image เก่า ป้องกันดิสก์เต็มกะทันหัน

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

การ self-host GitLab บน Droplet เหมาะกับทีมหรือองค์กรที่มีเหตุผลชัดเจนในการเก็บโค้ดและข้อมูลไว้บนโครงสร้างพื้นฐานของตัวเอง เช่น ข้อกำหนดด้าน data residency ที่ต้องเก็บซอร์สโค้ดไว้ในภูมิภาคที่กำหนด หรือธุรกิจที่มีนโยบายความปลอดภัยภายในไม่อนุญาตให้เก็บโค้ดบน SaaS ของบุคคลที่สาม อีกกรณีที่พบบ่อยคือทีมที่ต้องการ CI/CD runner ที่เข้าถึง hardware หรือ network เฉพาะทาง เช่น ทดสอบกับอุปกรณ์ภายในองค์กร ซึ่งทำได้ง่ายกว่าเมื่อ GitLab server อยู่ในเครือข่ายเดียวกัน การ self-host ยังเหมาะกับทีมขนาดเล็กถึงกลางที่อยากได้ฟีเจอร์ระดับ Premium ของ GitLab เช่น approval rule หรือ advanced CI/CD บางส่วน โดยไม่ต้องจ่ายค่า license ต่อ seat แบบ SaaS แต่ต้องแลกกับภาระดูแลระบบเองทั้งหมด ตั้งแต่ patch ความปลอดภัย, อัปเกรดเวอร์ชัน, ไปจนถึง backup ในทางกลับกัน ถ้าทีมมีจำนวนผู้ใช้มากกว่า 20-30 คนขึ้นไปและต้องการ high availability จริงจัง สถาปัตยกรรมแบบ single Droplet ตามคู่มือนี้จะเริ่มไม่เพียงพอ ต้องขยับไปใช้ reference architecture แบบหลายเครื่องที่แยก Gitaly, PostgreSQL, Redis ออกจากกัน หรือพิจารณาใช้ GitLab.com แบบ SaaS แทนถ้าไม่มีเหตุผลด้าน compliance บังคับให้ต้อง self-host สำหรับสตาร์ทอัพหรือทีมพัฒนาภายในที่มีคนดูแลระบบเพียงคนสองคน การเริ่มจาก Droplet เดียวตามคู่มือนี้ก่อนแล้วค่อยขยายเมื่อจำเป็นจริงเป็นแนวทางที่คุ้มค่ากว่าการลงทุนสถาปัตยกรรมซับซ้อนตั้งแต่วันแรก

• เหมาะกับทีมที่มีข้อกำหนด data residency หรือ compliance ที่ห้ามเก็บโค้ดบน SaaS บุคคลที่สาม
• เหมาะกับ CI/CD ที่ต้องเข้าถึง hardware หรือ network ภายในองค์กรโดยตรง
• ประหยัดกว่า GitLab Premium/Ultimate แบบ SaaS สำหรับทีมเล็กที่ยอมดูแลระบบเอง
• ทีมเกิน 20-30 คนหรือต้องการ high availability ควรขยับไปใช้ reference architecture หลายเครื่องแทน single Droplet

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

ปัญหาที่พบบ่อยที่สุดคือ gitlab-ctl reconfigure ค้างหรือ fail บน Droplet ที่มี RAM น้อยกว่า 4 GB ซึ่งมักเกิดจากหน่วยความจำไม่พอให้ PostgreSQL migration รันจบ วิธีแก้เฉพาะหน้าคือเพิ่ม swap ชั่วคราวด้วยคำสั่งสร้างไฟล์ swap แล้วเปิดใช้งานก่อน reconfigure ใหม่ ส่วนวิธีแก้ระยะยาวคือ resize Droplet ขึ้นไปเป็นแผนที่มี RAM อย่างน้อย 4-8 GB ตามจริง อีกปัญหาที่พบบ่อยคือลืมเปิดพอร์ตที่จำเป็นใน Cloud Firewall ของ DigitalOcean เพราะค่าเริ่มต้นของ Firewall ถ้าตั้งเองมักเปิดแค่ SSH ทำให้เข้าเว็บ GitLab ผ่าน HTTP/HTTPS ไม่ได้ ต้องเพิ่ม rule เปิดพอร์ต 80, 443 และถ้าเปิด Container Registry ต้องเปิดพอร์ต 5050 เพิ่มด้วย ปัญหาถัดมาคือใบรับรอง SSL ขอไม่ผ่านตอน reconfigure ครั้งแรก สาเหตุส่วนใหญ่มาจาก DNS ยังไม่ propagate เต็มที่หรือ Cloudflare proxy บังหน้า IP จริงไว้ วิธีตรวจสอบคือใช้คำสั่ง dig หรือ nslookup เช็คว่าโดเมนชี้มา IP ของ Droplet ตรงแล้วจริงก่อนรัน reconfigure ซ้ำ อีกกรณีที่พบคือ restore backup แล้วล้มเหลวเพราะเวอร์ชัน GitLab ปัจจุบันไม่ตรงกับตอนสร้าง backup ทางแก้คือต้องติดตั้ง GitLab เวอร์ชันเดิมให้ตรงก่อน restore แล้วค่อยอัปเกรดต่อหลัง restore สำเร็จ ไม่ใช่ restore ข้ามเวอร์ชันโดยตรง สุดท้ายคือดิสก์เต็มแบบไม่ทันตั้งตัวจาก CI artifact สะสม แก้ได้ด้วยการเข้าไปตั้งค่า expiration policy ของ artifact ใน CI/CD setting ของแต่ละ project หรือรัน Rake task ล้าง artifact ที่หมดอายุด้วยมือเป็นระยะ

• reconfigure ค้าง/fail บน RAM น้อย → เพิ่ม swap ชั่วคราว แล้ว resize Droplet เป็น 4-8 GB ในระยะยาว
• เข้าเว็บไม่ได้ทั้งที่ Droplet รันอยู่ → เช็ค Cloud Firewall เปิดพอร์ต 80/443 (และ 5050 ถ้าใช้ Registry)
• ขอใบรับรอง SSL ไม่ผ่าน → ตรวจ DNS propagate ด้วย dig/nslookup และปิด Cloudflare proxy ชั่วคราวถ้าจำเป็น

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

เริ่มจากเลือกสเปก Droplet ให้เผื่ออนาคตไว้บ้าง แทนที่จะตั้งบนแผนขั้นต่ำสุดแล้วต้อง resize บ่อย เพราะการ resize ต้อง reboot เครื่องซึ่งกระทบผู้ใช้ทุกคนที่กำลังทำงานอยู่ ควรตั้ง cron job รัน gitlab-rake gitlab:backup:create ทุกวันโดยอัตโนมัติ และ sync ไฟล์ backup พร้อมไฟล์ gitlab-secrets.json ออกไปเก็บนอก Droplet ทันทีทุกครั้งที่รันเสร็จ ไม่ปล่อยให้ backup ค้างอยู่บนดิสก์เดียวกับ production นานเกินไป ก่อนอัปเกรดเวอร์ชันใหญ่ทุกครั้งควรถ่าย Droplet Snapshot ไว้ก่อนเสมอ เพื่อให้ rollback กลับมาได้เร็วถ้าอัปเกรดมีปัญหา แทนที่จะพึ่ง backup/restore แบบ Rake task อย่างเดียวซึ่งใช้เวลานานกว่า ด้านความปลอดภัยควรเปิด DigitalOcean Cloud Firewall จำกัด IP ที่เข้าถึงพอร์ต SSH ได้ ไม่เปิดกว้างให้ทุก IP บนโลกยิงเข้ามา และเปิด 2FA สำหรับบัญชี root/admin ของ GitLab เองด้วย ควรใช้ DigitalOcean Monitoring ตั้ง Alert Policy แจ้งเตือนเมื่อ RAM หรือ Disk ใช้งานเกิน threshold ที่กำหนดไว้ล่วงหน้า เพื่อรู้ตัวก่อนระบบล่มจริง ถ้าทีมเริ่มโตขึ้นและ CI/CD job หนาแน่นขึ้นเรื่อยๆ ให้แยก GitLab Runner ออกไปอีก Droplet ต่างหากตั้งแต่เนิ่นๆ ก่อนที่ CPU บนเครื่อง GitLab server หลักจะเริ่มกระทบผู้ใช้งานจริง สุดท้ายควรติดตามช่องทาง release note ของ GitLab เป็นประจำ เพื่อวางแผนอัปเกรดตามรอบที่ GitLab กำหนดไว้ แทนที่จะปล่อยเวอร์ชันค้างไว้นานจนอัปเกรดทีเดียวข้ามหลายเวอร์ชันซึ่งเสี่ยงกว่ามาก

• เลือกสเปก Droplet เผื่ออนาคต ลด downtime จากการ resize บ่อยครั้ง
• อัตโนมัติ backup ทุกวันด้วย cron และ sync ออกนอก Droplet ทันที รวมไฟล์ gitlab-secrets.json เสมอ
• ถ่าย Droplet Snapshot ก่อนอัปเกรดเวอร์ชันใหญ่ทุกครั้ง เพื่อ rollback ได้เร็วกว่า restore แบบ Rake task
• จำกัด IP เข้าถึง SSH ผ่าน Cloud Firewall และเปิด 2FA บัญชี admin ของ GitLab
• ตั้ง Alert Policy ผ่าน DigitalOcean Monitoring แจ้งเตือน RAM/Disk ก่อนระบบล่มจริง

รับ $200 Free Credit →