Server Recipes by Workload: Copy-Paste Config Sheets and Pitfall Lists

# What this hub answers Configuration sheets and pitfall checklists per business shape: trade sites, game servers, small APIs, test rigs, PBNs, download boxes. Don't want the theory? Copy the recipe for your shape, then double-check details against the selection hub. Every scenario ships as a trio: **config sheet + line notes + pitfall list**. ## Scenario cheat sheet | Scenario | Region / line | Starter config | Monthly order | |---|---|---|---| | Trade site | HK/SG · CN2 or BGP | 2C4G / 60G SSD | $10–30 | | Game server | JP/HK low-latency line | 4C8G, dedicated CPU | $30–100 | | Small API / backend | Follow your users | 1–2C 2–4G VPS | $5–20 | | Multi-site / PBN | BGP multi-line, many IPs | Multi-IP dedicated (25 IP tier $190.80) | from $190 | | Heavy download / distribution | SG/US-West big bandwidth | 100M+ dedicated or 1G shared | traffic-driven | | Dev / test / learning | anywhere | entry VPS (from $5.34) | $5–10 | ## Trade site (brochure + enquiries) - **Config:** HK or SG, 2C4G / 60G SSD to start; WordPress + cache plugin + CDN. - **Line:** customers inside China → CN2 GIA/CMI first; pure overseas → local BGP + CDN is enough. - **Pitfalls:** shipping an English-only site and forgetting CN visit speed; no SPF/DKIM/DMARC so enquiries land in spam; no daily backup — run the security baseline before launch. ## Game server (MC / Palworld / self-hosted) - **Config:** JP or HK, 4C8G minimum; prefer dedicated-CPU bare metal (game loops are single-thread and jitter-sensitive). - **Line:** test where your players are — East-China heavy → JP SoftBank/CN2; South-China heavy → HK; cross-region communities → consider multi-region deployment. - **Pitfalls:** shared VPS stuttering at peak; UDP ports left closed (firewalls default to TCP); panel (MCSM etc.) without permission isolation, letting players touch the host. ## Small API / backend - **Config:** 1–2C 2–4G VPS, Docker Compose, Nginx reverse proxy + Let's Encrypt auto-renewal. - **Key points:** database on localhost bound to 127.0.0.1; log rotation and disk alerts (full disks are the #1 API outage); health endpoint + uptime monitoring. - **Pitfalls:** debug ports (DB, Node inspector) exposed to the internet — run the hardening checklist before going live. ## Multi-site / PBN operations - **Config:** multi-IP dedicated server sized to your site count (25 IP tier $190.80/mo); BGP multi-line is fine; memory-heavy, CPU-light. - **Key points:** confirm the AUP allows PBNs first; check IP-range reputation before buying; separate directory and DB user per site. - **Pitfalls:** one template + one /24 across all sites → search engines fingerprint the cluster and de-rank it. Differentiation beats quantity. ## Heavy download / distribution - **Config:** SG or US-West big-bandwidth box (100M+ dedicated or 1G shared); HDD capacity or object storage as origin. - **Key points:** do the traffic math first (overage rates spiral faster than bandwidth fees); put hot content behind a CDN to drop origin load an order of magnitude. - **Pitfalls:** comparing bandwidth unit prices while ignoring traffic caps; judging bandwidth from single-thread tests (use the diagnostics hub method). ## Dev / test / learning - **Config:** entry VPS (1C1–2G, $5.34 tier) monthly; pair with the "Internet from Zero · L1" course. - **Key points:** delete after use or snapshot it — don't let it become a zombie asset; test credentials strictly separated from production. - **Pitfalls:** testing on unmasked copies of production data — the classic leak source. ## SaaS startup's first server - **Config:** 2C4G VPS (HK/SG, $10–20 tier) running app + database; object storage for uploads; free CDN for static traffic. - **Architecture principle:** single box ≠ naked box — layer app, DB and proxy with Compose; dump volumes to object storage daily. When DB connections saturate, split the database onto its own machine before upsizing the app box. - **Pitfalls:** object-storage keys hardcoded in frontend bundles (you become a free image host); no rate limiting → script-driven SMS bill shock; domain email without the SPF/DKIM/DMARC trio → confirmation mails in spam. ## Personal blog / knowledge base - **Config:** entry VPS ($5.34 tier) + static generator (Hugo/Hexo) or lightweight WordPress behind a free CDN; origin load then approaches zero. - **Key points:** static is the optimal answer here — build once, distribute everywhere; comments via a hosted service, not your own database. - **Pitfalls:** buying headroom for "features I might add later" (a blog's later is usually still a blog); forgetting domain and certificate expiry dates — put them in monitoring. ## When to leave free tiers Free PaaS/object-storage tiers are right for validating ideas. Three signals say move: ① the free tier starts limiting resources real users feel (sleeping instances, connection caps); ② you outgrow the free quota and bills appear; ③ you need custom runtimes, WebSockets, cron or resident processes. The migration itself is small: one $5 VPS + Docker absorbs most free-tier loads — and buys you full control. Match your shape against the sheets above and the decision takes ten minutes. ## Bandwidth math (universal formula) Rough cut: concurrent users × average page weight ÷ acceptable load time. Example: 10 concurrent users opening a 2 MB page within 3 s ≈ 55 Mbps. Brochure sites are fine at 5–10M; video/download tiers need peak-traffic math plus a clear overage policy (throttle or bill). Verify real throughput with multi-thread iperf3 or a large-file pull — never single-thread numbers. ## Verify before you buy For any shape: run the speed test hub against your target region and line before ordering; complete first-hour hardening after ordering; then set a monitoring baseline (reachability + latency to start) from the diagnostics hub.