Every developer eventually hits the same wall: you write a beautiful, stateless application, and then you burn an entire weekend fighting with ingress configurations, TLS certificates, and YAML files just to get it online.

On one extreme, you have the bare-metal VPS - sovereign and cheap, but requiring you to act as a full-time systems administrator. On the other extreme, you have the managed PaaS and Kubernetes ecosystems, which offer frictionless deployments but trap you in proprietary platforms or bury you under enterprise-grade cognitive overhead.

You can have both sovereignty and ergonomics. While open-source tools like Dokku, Coolify, and CapRover are fantastic solutions for self-hosting, they largely default to monolithic designs. In a monolithic setup, if your orchestration layer crashes during a heavy build or deploy, your routing table and active containers are suddenly in an inconsistent state because they all share the same execution context. Even Kamal - arguably the closest philosophical cousin in this space - relies heavily on remote SSH execution rather than maintaining a persistent, state-aware connection to the cluster.

By abandoning strict multi-tenant isolation and aggressively decoupling state from execution, we can architect a deployment engine that feels like a managed cloud but runs comfortably on a $5 DigitalOcean droplet - sovereign infrastructure on your own terms.

The Third Path: Asymmetric Decoupling

The reason most existing deployment tools feel heavy is that they bundle state, scheduling, networking, and execution into monolithic systems. To achieve simplicity and scale without the bloat, we use a Dual-Binary Architecture.

We split the system into two distinct pieces: the Brain, and the Hands.

1. The Control Plane (The Brain)

This is a single, stateful binary responsible for global decision-making. It runs an API, listens for your Git webhooks, builds your Docker images, and schedules deployments. It sits on top of a lightweight PostgreSQL database for state and a Redis instance for job queues. Critically, it also acts as the internal Certificate Authority (CA) for the entire cluster.

What about Control Plane failure?
By design, the brain is a single point of failure for deployments, but not for uptime. Because the architecture is decoupled, if the Control Plane goes offline, your existing Worker Agents and the Caddy proxy continue serving traffic uninterrupted. (To ensure resilience, Caddy's dynamic API state is persisted to disk via caddy.json snapshots, so even if the proxy itself restarts during a Control Plane outage, no routes are lost.) You lose the ability to deploy new code until the brain reboots, but you don't drop a single user request.

2. The Worker Agent (The Hands)

On every server in your cluster, you install a tiny, stateless Worker Agent. This agent is deliberately dumb. It holds no global state, makes no scheduling decisions, and simply listens to the Control Plane via gRPC to spin up local Docker containers.

Node enrollment is the only moment of meaningful ceremony. When you provision a new server and start the agent binary for the first time, it reaches out to the Control Plane's enrollment endpoint over HTTPS and presents a one-time token. The Control Plane, acting as its own internal CA, generates a signed TLS certificate unique to that node and returns it. From that point on, the agent uses this certificate for all gRPC communication - and never needs to contact the enrollment endpoint again. Adding a new server to your cluster takes roughly thirty seconds.

Once enrolled, the agent is entirely reactive. It maintains a persistent gRPC stream to the Control Plane and processes three types of instructions: spin up a container with this image and these environment variables, stop a container by ID, and report current resource telemetry. That's the entire surface area of the agent's responsibility.

To keep the Control Plane informed, every agent emits a periodic heartbeat with an exponential backoff reconnect on failure. It reports real-time telemetry - CPU load, RAM usage, and disk space - on every beat. If an agent misses three consecutive beats, it is marked as dead, and the Control Plane instantly reschedules its workloads to healthy nodes.

Deep Dive: Networking, Secrets, and Manifests

This asymmetric decoupling allows us to handle complex infrastructure requirements natively, without reaching for external orchestrators.

gRPC over mTLS and Zero-Knowledge Secrets

We secure the cluster using gRPC over mTLS (Mutual TLS). Trust is bootstrapped during node enrollment: the Control Plane, acting as its own self-signed CA, generates and signs the agent's certificate. Both sides mathematically verify each other on every request, neutralizing rogue agents and man-in-the-middle attacks.

For environment variables, we implement a strict zero-knowledge architecture. Secrets are secured using envelope encryption - a master Key Encryption Key (KEK) stored securely in the Control Plane protects unique Data Encryption Keys (DEKs) for each payload. When a deployment occurs, the Control Plane passes the encrypted payload and the DEK securely over the mTLS channel. The agent decrypts the secrets in-memory and injects them directly into the Docker container. The plaintext secrets never touch the physical disk.

Dynamic Networking without Ingress Controllers

Managing Nginx configs and rotating SSL certificates is fragile. In our stack, we bypass traditional ingress controllers and integrate directly with Caddy.

Caddy exposes a local admin API at localhost:2019. When a container spins up, the Control Plane dynamically writes JSON route configurations to this API, which Caddy applies instantly without a reload. The proxy handles the upstream mapping and provisions Let's Encrypt certificates automatically. We extend this to local development by forcing environments to bind to a .localhost suffix, leveraging native OS DNS resolution for exact production parity.

Deterministic Manifests

Helm charts and complex YAML configurations fail because they force developers to memorize arbitrary schema definitions. We replace them with a single, declarative .msks (short for Meeseeks) lockfile stored in the repository.

name: "my-app"
environments:
 production:
 replicas: 2
 domain: "api.myapp.com"
 build:
 dockerfile: "./Dockerfile"
 services:
 - type: postgres
 version: "15"
 - type: redis
 version: "7"
 cron:
 - schedule: "02***"
 command: "nodescripts/cleanup.js"

When you push your code, the Control Plane parses this block top-to-bottom and executes it as a deterministic plan. It provisions an isolated PostgreSQL container and a Redis instance, networks both securely to your application, and injects the dynamically generated connection strings directly into your app's environment variables - DATABASE_URL, REDIS_URL - without you writing a single line of configuration. The cron entry gets registered as a scheduled job on the worker node running your container.

Crucially, how does the system handle manifest drift? The architecture is strictly declarative. If someone SSHes into a server and manually stops a container, the Control Plane detects the mismatch against the .msks source of truth during the next heartbeat cycle. It immediately issues a reconciliation command to spin the container back up.

The key design constraint is that the manifest declares what you need, not how to wire it. You never specify ports, network names, or volume paths. The Control Plane owns those decisions. This means the manifest is portable across every environment in your cluster - staging, production, or a local .localhost dev environment - without modification.

System Architecture Summary

At a high level, the deployment lifecycle flows top-down through a highly secured, deterministic pipeline:

Conclusion

By aggressively decoupling state from execution, we stop fighting the orchestrator and start owning our platforms again. The philosophical promise of the .msks manifest is that a developer should declare intent, not wire plumbing.

We can reclaim the bare metal without sacrificing the developer experience. The next era of software engineering belongs to the sovereign developer - the one who builds quickly, scales cheaply, and controls the stack from top to bottom.