git clone git://
Log | Files | Refs | README

server-guide.html (7771B) - raw

      1 <h1>Alex's Guide to running a home server (WIP, DRAFT)</h1>
      2 <p>This is a living guide to hosting digital infrastructure. I'm writing this out
      3 of a dissatisfaction with a lot of existing approaches to running a home server. It
      4 seems to me that a lot of self-hosting guides mirror the approaches and
      5 infrastructure of big tech.</p>
      6 <p>This is a living document, and I will update it as I learn more. If you have
      7 suggestions or corrections, please contact me.</p>
      8 <h2>Principles</h2>
      9 <h3>Keep it simple</h3>
     10 <p>Your system should be as simple as possible. Use lightweight tools: this often
     11 means that you will be using things that are not mainstream, as mainstream
     12 tools are often designed primarily with large, modern, distributed,
     13 high-traffic services in mind: not what we are doing here. You may find
     14 yourself using Linux tools that are quite old, from an era were simpler and
     15 more straightforward infrastructure was more common.</p>
     16 <h3>No cloud services</h3>
     17 <p>Some self-hosting guides will say, set up your home server then use a cloud
     18 proxy server, or put things behind Cloudflare. In my view, this defeats the
     19 purpose: if you want true digital self-sufficiency, you should control as much
     20 of your infrastructure as possible.</p>
     21 <h3>Accept limitations</h3>
     22 <p>There are things that you won't be able to do on self-hosted infrastructure.
     23 Rather than compromise another principle to attempt them, accept and work
     24 within these limitations. For example: you will probably not achieve 100%
     25 uptime with your service. Accept this and communicate it to your site visitors</p>
     26 <h2>Operating System</h2>
     27 <p>I choose <strong>Linux</strong> as my operating system. Alternatives to consider, in order of
     28 feasibility, are OpenBSD and Plan9. This guide is focused on Linux because it
     29 is the operating system I am most familiar with, and it is so ubiquitous that
     30 it is easy to find resources, software and guides for configuring Linux.</p>
     31 <p>In terms of distros, I choose <strong>Alpine Linux</strong>. Alpine Linux is a very minimal
     32 distro. I am both familiar with it and philosophically aligned with it. Alpine
     33 Linux uses musl rather than glibc, which may cause software incompatibilities,
     34 but this is less of a concern for the kind of thing you'll be hosting in the
     35 cloud. Unlike something like Raspberry Pi OS, there won't be a step by step
     36 "how-to" guide for running Alpine on the Raspberry Pi. You'll need to develop a
     37 bit of understanding about your operating system. You are welcome to use
     38 another Linux distro if you'd prefer.</p>
     39 <h2>TLDs</h2>
     40 <p>Unfortunately, a lot of TLDs are operated by <a href="">Identity
     41 Digital</a> or a similar
     42 for-profit company. These companies are rent-seekers: they seek to profit on
     43 the natural abundance of digital infrastructure by creating walled gardens to
     44 exploit. Companies like this exist all throughout the infrastructure of the
     45 internet, and it is difficult to avoid them, but it is something to consider
     46 when choosing a TLD. Preferring TLDs operated as nonprofits (e.g. .org) or at
     47 least as public-private partnerships is a good idea.</p>
     48 <p>I chose .nyc as my TLD, which is a public-private partnership between the City
     49 of NY and Verisign.</p>
     50 <p>TODO -- update this section. This may be misinformation or incomplete</p>
     51 <p>Some TLDs may have difficulty sending email.</p>
     52 <h2>ISP</h2>
     53 <p>Your ISP may or may not "officially" let you self-host a web server or other
     54 traffic on your network. Whether this is actually enforced depends on your
     55 location and ISP. Do whatever research you can on your ISP, and consider a
     56 local ISP if available.</p>
     57 <p>A better connection is preferable, but you can still self-host with relatively
     58 low upload speeds so long as you lean harder into the third principle (accept
     59 limitations).</p>
     60 <p>Your ISP may or may not have a static IP adress, in which case you may need to
     61 set up DDNS to handle DNS records.</p>
     62 <h2>Hardware</h2>
     63 <p>In terms of hardware, you should be fine with any hardware that can run Linux.
     64 Personally, I use a Raspberry Pi 3B, because I already have one lying around.
     65 This setup is so light that you can probably get away with something as
     66 lightweight as the Raspberry Pi Zero. </p>
     67 <h3>Comments on the Raspberry Pi</h3>
     68 <p>Installing Alpine Linux on the Raspberry Pi is a bit of a challenge, by which I
     69 mean, you will not find any guide that will tell you exactly everything you
     70 need to do. Instead, you should develop an understanding of your specific needs
     71 and how different installation methods may or may not meet them. </p>
     72 <p>Raspberry Pis boot from an SD card, and SD card wear is a problem: SD cards an
     73 unreliable storage medium, and may fail for any reason. I have not found
     74 reliable information about SD card wear and how to avoid it, so I tried the SD
     75 card as inherently unstable and make sure to have regular backups.</p>
     76 <p>For my Alpine installation on the Rasbperry Pi, I uase a combination of this</p> <a href="">wiki</a> guide, using diskless install, plus a few bind-mounted filesystems, as described in <a href="">this guide</a>.
     77 <h2>Router</h2>
     78 <p>I use <em>OpenWRT</em> as my router software. I much prefer this to using proprietary,
     79 commercial software, whose security I cannot vouch for.</p>
     80 <p>OpenWRT does not auto-update. You'll need to keep on top of security updates
     81 and patch your router regularly. </p>
     82 <h3>Configuration</h3>
     83 <p>I put my publicly-facing infrastructure on a separate VLAN so it should not be
     84 able to access anything else if it is compromised. A combination of these two guides, plus reading and understanding OpenWRT docs, should get you a VLAN set up: <a href="">cli guide</a> <a href="">web iface guide</a></p>
     85 <h2>Security</h2>
     86 <p>Opening up your network to the public internet means that you'll have to take
     87 security seriously. A misconfiguration can mean compromising your server, and
     88 potentially anything else on your network that the server may have access to.</p>
     89 <p>I do not have any IOT devices, such as a "smart" TV, thermostat, etc. The only
     90 devices on my network are my home laptop, work laptop, and cell phone. I
     91 recommend this as a general principle, not just if you're operating a home server.</p>
     92 <p>Move carefully and make sure you understand things thoroughly before you make
     93 your server accessible to the public</p>
     94 <h2>Software</h2>
     95 <p>Learn Linux a bit. Be able to navigate around your filesystem and understand
     96 how things are laid out. </p>
     97 <h3>Firewall</h3>
     98 <p>I use ufw as my firewall, and block all in and out ports by default. I then allowlist the needed ports. A good place to start is: DNS, NTP, HTTP, HTTPS</p>
     99 <h3>Web Server</h3>
    100 <p>I use lihgttpd as my </p>
    101 <h3>Monitoring</h3>
    102 <p>I use rrdtool for monitoring, which is an older and much lighter-weight alternative to something like Prometheus</p>
    103 <h2>Other helpful resources</h2>
    104 <ul>
    105   <li>
    106   <a href="">A Traversal Network of Feminist Servers</a>
    107   </li>
    108   <li><a href="">Counter Cloud Strategies</a></li>
    109   <li><a href="">Feminist Server Manifesto</a></li>
    110   <li><a href="">Server Security</a></li>
    111 </ul>
    112 <p>For anyone interested in setting up their own home infrastructure, I am happy to help, please send me an email at <a href=""></a></p>