Hello This Is My Name

Managing Your Identity Across Self-Hosted Services Without Losing Your Mind

Setting up a personal server or homelab is one thing. Figuring out how every application references your name, your email, and your credentials across twelve different dashboards is another thing entirely. I have been doing this for years, and I still hit the same wall when I try to make everything talk to each other cleanly. The simplest way to start is by treating your own identity as a single source of truth instead of a scattered collection of login notes. When I first set up my home network, I stored my primary email in the reverse proxy configuration, another email in the monitoring stack, and a third in the backup tool. Three different addresses for the same person. It worked, but it made troubleshooting miserable. I eventually moved everything to a single YAML file that lives in my ~/.config/id-entity/ directory. Each service reads from that one file instead of having its own hardcoded values. This is not a perfect solution, but it cuts down configuration drift significantly.

If you are looking for a starting point, I put together a small config template that handles the basic name and contact fields across common services. You can grab it at https://id-entity.example.org/releases/v1.4.2/id-config.tar.gz (the actual link is in the original post comments). It is a tarball, not a heavy installer, and it unpacks cleanly on both Debian-based and Alpine setups.

How the actual mapping works

Most people assume that admin_email or owner_name fields are interchangeable between tools. They are not. Portainer expects company_name during setup, while Gitea uses user_full_name in its configuration. If you map them blindly, you will end up with blank fields in at least one service, and the UI will show "Guest" or "Unknown" where your actual name should be. I learned this the hard way. Last winter I migrated a Caddy reverse proxy setup from one VLAN to another, and I assumed the admin_contact field was universal. It was not. The proxy panel showed a broken icon instead of my initials, and the log aggregation tool wrote "null" to the metadata field. I fixed it by running a quick lookup script that compared each service's schema against the master identity file and reported any mismatches. The script is small and runs in about forty seconds on a Raspberry Pi 4.

#!/bin/bash
identity-check.sh
Compares master config against known service schemas
MASTER_FILE="$HOME/.config/id-entity/master.yaml"
for svc in caddy portainer gitea authentik; do
  CONFIG="/etc/$svc/config.yml"
  if [ -f "$CONFIG" ]; then
    missing=$(diff <(yq '.identity' "$MASTER_FILE") <(yq '.identity' "$CONFIG") 2>/dev/null | grep "^<" | wc -l)
    [ "$missing" -gt 0 ] && echo "MISMATCH in $svc: $missing fields differ"
  fi
done

This script is not production-grade. It breaks if you use JSON configs or non-standard YAML paths. But it caught three mismatches in my setup on the first run, which saved me hours of debugging later. Pitfall 1: Hardcoding in environment variables. A lot of tutorials tell you to export OWNER_NAME="Your Name" in ~/.bashrc and reference it across containers. This works until you need to rotate your contact info, which happens more often than you expect. Use a config map or a single env file that all services mount read-only instead. Pitfall 2: Assuming case sensitivity does not matter. It does. Some services normalize to lowercase on import, others preserve casing. I once had two instances of the same tool running side by side, and they could not find each other because one stored "Agnes" and the other stored "agnes" in their peer discovery tables. It took me two hours to realize the casing difference was the root cause.

Pitfall 3: Not separating display name from technical identifier. Your name might be "João Silva" in the UI, but your database UID could be "jsilva-01". Mixing these up causes issues when you need to script automated tasks or pull data through APIs. Keep display names in config files and technical IDs in separate credential stores.

What this approach does not solve

Having a master identity file does not fix broken authentication backends, and it will not stop a service from requiring manual field entry during initial setup. Some tools, especially older ones, do not support external config injection at all. In those cases, you are stuck with duplicating the data manually, which defeats part of the purpose. For those stubborn services, I recommend keeping a second file called fallback-refs.txt that lists the exact field paths for each incompatible tool. It sounds tedious, but it takes about fifteen minutes to compile and saves you from hunting through documentation months later when something breaks. I also do not recommend this for shared team environments. Single-source identity works well when you are the only operator. Once you bring other people into the loop, you need proper access controls and audit logging, which is a different problem altogether.

A practical workflow that actually sticks

1. Create the master identity YAML with your preferred fields.
2. Mount it read-only into each service container.
3. Run the mismatch-check script after every deployment.
4. Update fallback-refs.txt whenever you add a new tool that does not support external config.
5. Back up the master file alongside your other infrastructure configs.

That last step is important. I lost the master file once because I stored it on the same NVMe drive as the services it managed. When the drive failed, I had no single source of truth left. After that, I started backing it up to a separate USB drive and pushing a copy to a private Git repo. The extra minute of setup time is worth it. If you want the exact version of the config template I referenced earlier, the download page is still live at the URL above. It includes commented examples for Caddy, Nginx Proxy Manager, Traefik, Authentik, Gitea, and Portainer. Nothing fancy, just the field mappings that actually work across those tools. I have been using this system for about eighteen months now. It is not elegant, but it keeps my identity data from fracturing across a dozen dashboards, and that is enough for me.