Services
Self-hosted infrastructure
Linux servers you own, set up and hardened so nothing listens on the public internet, backed up in a way that has been restore-tested, and handed over with the runbook. Or operated for you. Either way you know where the data is.
- Stack
- Linux, Proxmox, Apache, PHP-FPM, PostgreSQL, Cloudflare Tunnel, systemd, Docker, UFW
- Terms
- Scope call, paid discovery, written plan, fixed-bid milestones
How Fopull approaches it
A managed platform is the right answer until it is not: when the bill becomes a multiple of what the same machines would cost, when a compliance question asks where the data physically lives, or when a vendor changes something under you. Self-hosting is not free either. It costs operations work, and that work has to be done properly or it is worse than the platform was.
Fopull sets up the whole stack on your machines or on rented ones: the web tier, the database, the queue, mail, analytics. Public access goes through a Cloudflare tunnel, so the server opens no inbound ports and the firewall stays closed. The box is hardened: key-only SSH, unattended security updates, least-privilege service accounts, per-service users, audit logging. Backups are automated, encrypted, and restore-tested on a schedule, because a backup that has never been restored is a hope.
What you get is a runbook: how to deploy, how to restore, what each service is, what breaks and how it was fixed. The runbook is written during the build, from the incidents that happen, not afterwards from memory.
Worked example: the machine this page is served from
fopull.com runs on a virtual machine on a server in Knoxville, on hardware Fopull owns. Apache and PHP-FPM serve the site, PostgreSQL holds the data, analytics run self-hosted in containers, and a Cloudflare tunnel is the only public ingress: the router forwards nothing. The Floptle Cloud relay and its fleet box run on rented ARM machines in Ashburn under the same hardening, with a systemd dynamic user and credentials handed to the service by systemd rather than left in a file.
In September a failing memory module on that server was found through a corrupt container image, 46 hours of missing analytics, and a bit pattern that only bad RAM produces: 13 flipped bits in a 499 MB file, every one bit 0 or bit 7. The bad pages were located from the host's own shell and reserved in the kernel command line, a weekly memory canary now runs in the guest, and the whole thing is written up in the engineering log because it is exactly the kind of fault a managed platform hides from you and a self-hosted one makes you find.
The box has a build log going back to June: every service, every port, every restart, with the reason. That log is the runbook a client gets.
More of this, dated and with the numbers, in the engineering log.
Questions people ask
- Do we have to own the hardware?
- No. Rented machines from a cloud provider work the same way; the difference from a managed platform is that you hold root and the data is where you put it. Fopull runs its own on both.
- What about backups?
- Automated, encrypted, and restored on a schedule to prove they work. The restore drill is in the runbook with the last date it ran.
- Will you run it for us?
- Yes, under a maintenance retainer. Or the runbook lets your own people run it, and Fopull is a phone call when something is strange.
How an engagement goes
A scope call
Thirty minutes on the problem and the constraints.
A written plan
Short paid discovery, then a document you can take anywhere.
Built in milestones
Fixed-bid where the scope is clear, hourly where it cannot be.
Handed over with a runbook
Or run for you under a retainer.