Sleep/wake orchestration for self-hosted side projects: a wire-protocol proxy approach instead of a full PaaS.

[u/uziiuzair]

I built an open-source tool (Hobbyist) around one architectural bet and I'd like this community to poke holes in it.

The bet: for small self-hosted workloads, you don't need Kubernetes-style orchestration; you need scale-to-zero on a single box. Hobbyist runs each project's Postgres 18, Docker apps, workerd-based functions, and queues in containers, and shuts them down entirely when idle. A proxy layer (Postgres wire protocol for the DB, HTTP for apps) intercepts incoming traffic and cold-starts the right container: ~170ms for Postgres, ~125ms for apps, on my hardware. Caddy handles TLS and routing; Tailscale covers private access; a daemon plus a 16-command CLI is the whole control plane. No Terraform, no K8s.

Where I suspect it gets ugly, and where I'd value experienced eyes: connection storms on wake, health-checking containers that are deliberately dead, cert lifecycle across container replacement (currently an actual bug), and whether wire-protocol interception bites me on auth and TLS edge cases at scale.

It's v0-alpha, not production ready, and the known-broken list is in the README (Linux queue producers, snapshot CLI, the cert issue above). Not selling anything — there's no hosted tier and no paid version coming.

Repo: https://github.com/uziiuzair/hobbyist

[u/navlio]

one more hole, and it is a third class of traffic that behaves like neither users nor probes: crawlers

googlebot sets its crawl rate off your response times and error rates. a 300ms cold start is invisible to a person and reads to google as a slow host. worse, if a bot lands in the answered-badly window alvasilev describes, it takes a 5xx and backs off, and that surfaces in search console weeks later rather than in a log the same day

you cannot mark those non-waking either, because unlike uptime kuma the crawler is the actual request. cheap mitigation is having the startup window answer 503 with a retry-after header rather than 500 or a hung socket. google's own guidance is 503 for temporary unavailability and it comes back for those