A terrible way to jump into colocating your own stuff

Original Article ↗ Hacker News Discussion ↗

Running your own hardware in a colocation facility promises lower costs and more control than cloud hosting, but commenters highlight how easy it is to get in over your head. They stress basics like secure SSH configuration, remote management (IPMI/KVM), and documented reboot procedures, while noting that dedicated servers or VPSes are often cheaper and simpler for most needs. A recurring theme is that colocation is best suited to people with solid sysadmin skills and clear reliability or bandwidth requirements that justify the extra complexity.

SSH and initial hardening

  • Strong agreement on “SSH-only with keys” but many warn distro defaults can re-enable password auth via included config fragments.
  • Suggestions:
    • Use sshd -T | grep -i password and test logins explicitly.
    • Be aware of Include directives that override main config.
    • Some remove all includes; others argue for only using drop-in files (e.g., sshd_config.d/00-custom.conf) for clarity on upgrades.
  • Some use a separate OpenBSD bastion host instead of exposing many Linux boxes directly.

Remote management (KVM, IPMI, power)

  • Remote console and power control are seen as near-essential to avoid data-center trips.
  • Options discussed:
    • Onboard BMC/IPMI/iDRAC: powerful but widely considered insecure; best on isolated management networks or cross-connected between servers.
    • External IP-KVMs (e.g., Lantronix Spider, PiKVM, NanoKVM, TinyPilot) as safer/more flexible alternatives.
    • Serial console + reset via serial break as a simple, DIY, highly trusted approach.
    • Remote-controlled PDUs are useful, but some found they rarely needed them once they had good BMCs.
  • Consensus: never expose BMCs directly to the public internet.

Choosing colo vs dedicated, cloud, or home hosting

  • Many recommend starting with rented dedicated servers or VPS instead of raw colo:
    • No hardware logistics, remote hands included, often cheaper than cloud for heavy compute/bandwidth.
    • Some providers offer both dedicated and basic “cloud” to handle bursts.
  • For AWS-heavy setups, there’s discussion of:
    • Using AWS initially, then offloading bandwidth-heavy workloads to cheaper providers.
    • S3 is seen as cost-effective when egress is low; egress is the main pain point.
  • Home hosting:
    • Pros: cheap, easy physical access, high residential bandwidth in some areas.
    • Cons: unreliable power/network, residential IP/ToS issues, email deliverability, no SLAs.
    • Some argue robust home setups (generator, multiple ISPs) can be “good enough” for non-critical workloads.

Skills, readiness, and “gatekeeping” debate

  • The line “if you locked yourself out of SSH, you’re not ready” triggered debate:
    • One side: this is a valid litmus test; if SSH keys slip your mind, many other critical admin tasks likely will too. Better to learn on VPS/home lab first.
    • Other side: seen as unnecessarily snarky and gatekeeping; tutorials should teach SSH keys and assume people can be new or rusty.
  • Underlying concern: running internet-facing colo boxes carries real security and reliability risks (data loss, abuse, crypto-lockers, attack staging).

Finding and working with datacenters

  • Finding trustworthy, reasonably priced colo is described as hard today.
  • Strategies mentioned:
    • Visit facilities in person; check physical access controls and staff competence.
    • Look for community/non-profit colos and local hacker/housing clubs.
    • Use marketplaces/forums (e.g., WebHostingTalk) for offers.
  • Some see certifications like SOC 2 as mostly box-ticking that can even harm real security; they prefer evidence like red-team reports and direct conversations with staff.
  • Physical security varies widely: anecdotes range from teenage visitors given keys to almost everything, to strict mantraps and biometrics.

Operational tips and costs

  • Practical advice:
    • Bring or install a small switch to:
      • Connect multiple servers.
      • Plug in a laptop on-site for initial troubleshooting.
    • Test hard-reset and full power-loss behavior before leaving.
    • Configure multiple IPs on one interface (colo vs lab), and consider private VLAN + VPN for management.
    • Consider hot spares in storage pools to avoid urgent disk swaps.
    • Use hearing protection; data halls are very loud.
    • Tools: screwdriver, flashlight, and even multiple multitools are handy.
  • Cost ballpark from anecdotes:
    • 1U with power and 1 Gbit uplink: often cited as ~$60–80/month from smaller providers.
    • Half-rack in a larger DC: figures around ~$400/month, strongly dependent on power/bandwidth.
    • Several commenters argue that for modest needs, a VPS or cheap dedicated server is almost always cheaper and simpler than colo.