Sample architecture study — not a named client
B2B application hosting
Overview
Sample operations study — not a claim about a specific customer’s uptime. It captures the standard Palmate approach when an application already works but nobody can deploy it twice.
Production was a VM with files changed over SSH. Staging did not match production. TLS renewal was a calendar event. Backups existed as a zip in someone’s cloud drive. A dependency update required tribal knowledge.
The application had local file uploads and a database that had never been restored. DNS and email were entangled with the same host. Downtime windows were short because staff used the app during business hours.
Package the application, put a reverse proxy in front, move secrets to environment files that are not in git, and make backups a tested job. Keep the same VPS if it is sufficient; do not migrate to a maze of managed services without a reason.
01
Reverse proxy terminates TLS and routes to the app container. Health checks fail closed.
02
App and worker containers share an internal network. The database has a named volume and a backup sidecar or host job.
03
CI builds images, SSHs or uses a registry, and runs compose pull/up. Previous images remain until rollback is confirmed.
Success is a second person on the team being able to deploy and restore. We do not quote fake 99.99% figures for this sample; see the uptime calculator and uptime article for how those percentages actually work.
Next step
If this pattern matches a system you run, bring the current tools and the failure mode. We will say whether a sample should stay a sample — or become a build.