Linux & Self-Hosting

Most of the self-hosted apps we look after are a database plus a folder of uploads and config. You don't need a backup suite for that. A short shell script, cron and a second location do the job, as long as the database dump is consistent, retention is sensible and a copy gets off the box. Then you test the restore, because the day someone calls about missing files is a bad day to find out your backups were empty. You'll need the host running the app with MySQL or MariaDB, mysqldump and gzip (in the MySQL/MariaDB client package), and somewhere off-box. That can be another server you can rsync to over SSH (192.0.2.10 in the examples) or an object storage bucket with rclon…

When someone hands us a self-hosted app running in Docker, the trouble is almost never Docker itself. It's a .env full of passwords anyone on the box can read, data living somewhere nobody can point to, an update that quietly pulled a breaking major version, or backups nobody ever took. Compose fits this kind of work well because one YAML file describes the whole stack, so we use the same layout and routine on every Compose host. That way whichever tech gets the call already knows where everything is. You'll need Docker Engine with the Compose plugin (docker compose, not the old docker-compose), and root or sudo. One directory per app under /opt /opt/wiki/ compose.yam…

This setup came out of a PHP app's web installer telling me No such file or directory when I pointed it at the database. We'd moved MySQL into a container because upgrades and rollbacks are much easier than with the distro package, but the app itself ran on the host under nginx and PHP-FPM. Apps like that usually expect MySQL on the local Unix socket at /var/run/mysqld/mysqld.sock, the same as a native install. So this is how we do it now, with TCP on loopback only and the socket shared to the host. Why localhost gave a file error We'd only published the TCP port, and the installer had the database host set to localhost. With mysqli, the word localhost doesn't mean TCP …

Most of the small web apps we host live the same way. One LXC container or VM per service on Proxmox, nginx and PHP-FPM inside it, and a separate reverse proxy in front handling TLS. Each app is isolated, backups and rebuilds are easy, and when a PHP upgrade goes sideways only one app is down instead of everybody's. Two details get missed almost every time. The app needs to see the real client IP instead of the proxy's, and PHP needs to know the original request was HTTPS. Miss those and you get logs full of one IP, broken rate limiting and redirect loops. What I'm assuming you have A Debian 12 LXC or VM for the app, 10.10.20.21 in the examples A reverse proxy (nginx,…