Why SkyOps is self-hosted

The one-sentence pitch for SkyOps: your servers, your data, your rules.

Every competitor in the “server control panel” space has moved toward a SaaS model where your production hosts phone home with telemetry, app metadata, or — in some cases — live stdout streams. That’s fine for simple deployments. It’s incompatible with compliance regimes that forbid data leaving your perimeter, and it’s incompatible with the unwritten rule that production should not depend on a vendor’s uptime for YOUR uptime.

SkyOps runs as one binary on your server. The engine does every control-panel job locally — deployment, monitoring, security scanning, log aggregation, backups. The only network call we require is a heartbeat every six hours to validate the license. If that fails, the engine keeps running in a 72-hour grace window; after that, it enters read-only mode with existing apps still serving. No customer data — application payloads, user records, log contents — ever leaves your perimeter.

This blog is where we’ll write up the design decisions behind that model. First up next week: why activation is a signed JWS and how you can audit it.