How I Started Self-Hosting
By: Will Ho
Tags: Open Source, Docker, Kubernetes, Programming, Raspberry Pi

Should You Self-Host?

There are many factors to consider when deciding whether to self-host your applications.

You should self-host if:

You’re still reading patiently at this point. You enjoy tinkering with stuff and fussing over minute details, spending many hours or even days on the tiniest of problems. You are a generalist who wants to learn anything and everything about computers. You like the cheap thrills you get from being able to achieve everything big companies do with their products at little to no cost. You want to own your data and web services.

I put the ownership of data as the final point as I believe that complete ownership of your data is a moonshot, if not impossible, goal in today’s highly interconnected world. For this reason, it should be the last motivation you should have when it comes to self-hosting.

I cannot emphasize point two enough. Over the past three years of self-hosting, I’ve run into numerous problems and spent many days debugging an issue, only to find that the problem was a typo in the configuration, or worse, a yet-to-be-discovered bug with the FOSS software I was trying to host. Let me illustrate this with an example.

A painful typo you’ll never spot

Just four weeks ago, I was trying to deploy OpenLDAP , a lightweight client-server protocol for accessing directory services, commonly used for storing credentials and user metadata. This was meant to be the core of my SSO service where users can just use a single username and password to access all my services. Have a look at my Kubernetes env configuration for osixia/openldap-backup , a dockerized implementation of OpenLDAP.

containers:

- name: openldap

image: osixia/openldap-backup:1.3.0

env:

- name: LDAP_ORGANIZATION

value: ikarus

- name: LDAP_DOMAIN

value: ikarus.sg

- name: LDAP_BASE_DN

value: 'dc=ikarus,dc=sg'

- name: LDAP_ADMIN_PASSWORD

valueFrom:

secretKeyRef:

name: openldap

key: admin_password

- name: LDAP_READONLY_USER

value: 'true'

You’ll NEVER spot this error! Can we even call it an error?

I struggled for two days with why OpenLDAP did not pick up the LDAP_ORGANIZATION value from the environment variable — deleting, redeploying, and changing the order of the variables. It was only when I actually dug into the code did I see how trivial this error was:

slapd slapd/internal/generated_adminpw password ${LDAP_ADMIN_PASSWORD}

slapd slapd/internal/adminpw password ${LDAP_ADMIN_PASSWORD}

slapd slapd/password2 password ${LDAP_ADMIN_PASSWORD}

slapd slapd/password1 password ${LDAP_ADMIN_PASSWORD}

slapd slapd/dump_database_destdir string /var/backups/slapd-VERSION

slapd slapd/domain string ${LDAP_DOMAIN}

slapd shared/organization string ${LDAP_ORGANISATION} ## THIS LINE

slapd slapd/backend string ${LDAP_BACKEND^^}

How did I miss that?!

The variable name should have been LDAP_ORGANISATION and not LDAP_ORGANIZATION .

Looking back at the documentation, I couldn’t believe I missed it.

The following are only required and used for a new LDAP server:

LDAP_ORGANISATION : Organisation name. Defaults to Example Inc .

: Organisation name. Defaults to . LDAP_DOMAIN : Ldap domain. Defaults to example.org .

: Ldap domain. Defaults to . LDAP_BASE_DN : Ldap base DN. If empty automatically set from LDAP_DOMAIN value. Defaults to (empty) .

: Ldap base DN. If empty automatically set from LDAP_DOMAIN value. Defaults to . LDAP_ADMIN_PASSWORD : Ldap Admin password. Defaults to admin .

Ldap Admin password. Defaults to . LDAP_CONFIG_PASSWORD : Ldap Config password. Defaults to config .

It turns out the organization maintaining the Docker image of OpenLDAP, osixia, is based in Nantes, France —which is probably why they wrote the variable names in British English instead of American English.

If what you just read terrifies you deeply, I suggest you reconsider!

You should not self-host if: