"A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable."

Leslie Lamport

Every Crossplane story starts the same way. You spin up a single-node cluster on your laptop, install Crossplane, and watch your first composition reconcile. It's almost magical, until you try to run real applications next to it.

Single node is fine, until you add the rest of the stack​

Crossplane itself behaves perfectly well on a single node. The control plane reconciles, the providers reconcile, the compositions do their thing. The problem isn't Crossplane. The problem is everything else you actually want to run next to it.

Local development is the most important phase of the whole project. Long before any of this lands in a cloud, you need to see your app talk to the resources Crossplane is provisioning, watch the wiring with your own eyes, break it on purpose, fix it, break it again. That's where the real work happens. And the laptop has to host it: Crossplane, its providers, every microservice you're building, the databases they hit, the message bus, the auth stub. Memory and CPU run out fast. Crossplane is a polite citizen, but it's still a control plane with reconcilers watching CRDs. It eats space. So do your apps. They eat the same space, and something gives.

The instinct is to scale down: fewer providers, smaller workloads, mock more, run less. That's a tax on the work itself. The thing you came to test gets distorted to fit the machine, and what you end up validating is a smaller, faker version of the system you actually care about.

Move what doesn't need to be local, off the laptop​

There's a quieter answer. Stop treating the laptop as the place where everything lives. Treat it as the workbench. Push everything that doesn't need to be in front of you out to other nodes, and keep on the laptop only the thing you're actively touching this afternoon.

That can start small: move Crossplane out. Just to a node that isn't your laptop. A spare box on the network, an old NUC, a teammate's idle workstation. And if you don't happen to have any of those lying around, any SSH-reachable Linux host does the job, including a cheap cloud VM at a few dollars a month. The point isn't to avoid the cloud entirely, it's to avoid having to build a production cloud setup just to develop. Let that node run the engine: Crossplane, providers, functions, Kyverno, CertManager, all the heavy reconcilers. The laptop suddenly has its CPU back, and the control plane is on stable infrastructure that doesn't have to share a fan with VS Code.

It doesn't stop there. The same gesture works for a workloads node, for a node that hosts your databases, for one that runs the message broker, for whatever else takes resources without ever needing your eyes on it. Each piece lands where it makes sense. The laptop keeps shrinking down toward the one microservice you're rewriting, the dashboard you're inspecting, the test you're stepping through. The supporting cast lives elsewhere, reachable, observable, but no longer fighting your editor for memory.

The microservice topology, made real before cloud​

This is exactly what Kubernetes was made for and exactly what microservice architecture promised. Each role on its own infrastructure, talking over a network, scheduled where it makes sense. Crossplane already lets you wire the pieces together as composable resources. A distributed environment is what makes that wiring real instead of theoretical. The control plane is a real control plane on its own host, the data services run on theirs, the workloads on another, and the bit you're developing sits right under your fingertips. The same shape you'll see in production, except the network hop is to your closet instead of eu-west-2.

Adding a remote node, in one command​

Overlock collapses each join into a single sentence. One for the engine:

overlock env node create my-engine \
  --env my-env \
  --host 192.168.1.100 \
  --scopes engine

Another for a workloads host. Another for a database host. Run them as you grow the topology, drop them as you shrink it back down. Behind each line, a remote Linux box goes through the entire ceremony: SSH in, Docker if it's missing, an agent container, a WireGuard tunnel back to the server, CNI wiring, registration. The node shows up in kubectl get nodes and the control plane never realises it's two hops away over an encrypted overlay. You shape the cluster around the work, not the other way round.

What you end up with​

The picture you end up with is the picture Crossplane was always meant to project. Control plane on stable infrastructure. Data and infra services on their own hosts. The laptop holding only what you're developing or watching, fast to iterate, easy to throw away. The microservice topology stops being a slide and starts being something you can kubectl get, break, and watch heal.

A single binary, a handful of commands, and the local-and-cloud rehearsal becomes a local-and-remote rehearsal of the cloud. Same shape, no AWS bill, full speed of iteration. That's what local development looks like when distributed environments are this cheap to summon, and when "what's on the laptop" can finally be just the part of the system you actually want to see.

Bug fixes​

• Fix image pulls behind PPPoE links (#468) — pod MTU and TCP MSS are now clamped so the registry handshake completes on connections with a smaller MTU than standard Ethernet. If you saw image pulls hanging on home/PPPoE networks, this release is for you.

What's new​

• Docusaurus documentation site (#450) — ./docs is now a Docusaurus project with sidebar, search, and edit-on-GitHub links. The same Markdown still works on GitHub.
• GitHub-style admonitions in docs (#467) — > [!NOTE] / [!WARNING] syntax renders as proper Docusaurus admonitions.
• Docker Desktop on Linux setup guide (#465).

Bug fixes​

• Docker Desktop compatibility and remote wg0 reuse (#464) — environments now come up cleanly on Docker Desktop, and existing WireGuard interfaces on remote nodes are reused instead of failing.
• Install script repo URL (#458) — install.sh now points at web-seven/overlock after the org rename.
• Fix Documentation deploy workflow on main (#462).

Highlights​

The k3s-docker engine​

A new engine that runs each Kubernetes node as its own Docker container with WireGuard tunneling between them. By default you get an agentless K3s server plus two agent nodes — workloads (user pods, system services) and engine (Crossplane, providers, functions, Kyverno, CertManager). Spin up with:

overlock environment create my-env --engine k3s-docker

Multi-node and remote nodes​

Add a Linux host as a worker over SSH:

overlock env node create my-remote-node \
  --env my-env \
  --host 192.168.1.100 \
  --scopes engine

Inter-node traffic is WireGuard-encrypted automatically. Remote nodes start and stop with the environment lifecycle.

CPU limits, taints, mounts​

• --cpu 2 / --cpu 0.5 / --cpu 50% per node.
• --taints key=value:NoSchedule with auto-generated node labels for each taint.
• --mount /host:/container on node create and env create for bind-mount workflows.

Registry improvements​

• registry create --update to update an existing registry secret in place.
• --label key=value on registry create, with label merging on update.
• Server, username and password are now stored in the secret data fields.

Bug fixes​

• IP conflicts on environment start are gone — the server container starts before agents now.
• Port conflicts for local nodes on host networks resolved (host networking on remotes for WireGuard peering, --node-external-ip set on local nodes).
• env create waits for the API server before starting remote nodes.
• Duplicate node names are rejected; environments and nodes that already exist are skipped gracefully.
• SSH Run no longer returns EOF on successful commands.

For the full list, browse the closed PRs against the v1.0.0 milestone.

Welcome to v1.

Bug fixes​

• Install script fetches latest stable by default (#375) — install.sh no longer picks up pre-release tags. You always get the most recent stable release unless you pass an explicit version.

What's new​

• HTTPS for the local registry (#346) — local registries now serve HTTPS in addition to HTTP, fronted by an nginx reverse proxy (#347).
• registry load-image subcommand (#342) — push pre-built OCI images straight into the local registry without going through docker push.
  • --helm flag to load Helm charts (#345).
  • Always uses the OCI empty base layer (#349).
• --container-path on environment create (#354) — pin a custom container path for environment data.
• --version on the install script (#356) — install a specific Overlock version.
• Optional admin service account creation (#338).
• README refresh with badges and clearer navigation (#367).

Behaviour changes​

• registry create warns instead of erroring on duplicates (#352).
• environment create warns instead of erroring on duplicate names (#336).

Bug fixes​

• Kyverno policy CRD conflicts resolved (#340).

What's new​

• Kyverno upgraded to 3.4.4 (#333) — was 3.2.5.
• Standardized error handling across packages (#326) — clearer, more consistent error messages.
• Code agent instructions for contributors (#322).

Bug fixes​

• Dependency error fixed (#325).

What's new​

• Config-file driven environment setup (#306) — define an environment in a single config file and let Overlock create cluster, registry, providers and configurations.
• Network-event auto-provisioning — environments, registries, configurations and providers can now be created automatically in response to on-chain events:
  • Auto-create environment from a Solana TX (#296).
  • Auto-create configuration from a network event (#294).
  • Auto-create local registry from a network event (#292).
  • Auto-register providers in the network (#302, #304).
• Cosmos plugin: environment subscribe (#291) — subscribe to Cosmos chain events and react to them.
• Billing reconciliation event watching (#301).
• Discord notifications on release (#308).
• Friendlier error UX — surfaced errors now link to the docs (#320).

Bug fixes​

• Install script bug (#317).
• Missing default values filled in (#319).
• Spurious "plugin doesn't exist" warning silenced (#318).

What's new​

• Wait for the policy controller to install during env creation — fewer race conditions on first boot.
• Unified image-archive loader for functions, providers, and configurations — one code path, fewer corner cases.

Bug fixes​

• New function instantiation on load no longer fails on the first invocation.

What's new​

• env create accepts engine config — fine-tune the underlying Kubernetes engine right at cluster creation time, no manual chart edits required.

What's new​

• --engine-version for Crossplane — pin a specific Crossplane release; useful for matching production or testing upgrades.
• Default Crossplane version: 1.19.0.

What's new​

• LoadPackageDirectory accepts kinds for filtering — load only what you need from a package directory.

Bug fixes​

• No more global error when there's no kube context — the CLI fails specifically where it needs a context, not before.

What's new​

• configuration serve now uses rjeczalik/notify — better recursive watch coverage on macOS / Windows / Linux, fewer missed events on the live-reload loop.

What's new​

• Configuration tar load now uses the layers loader — consistent with how providers and functions are loaded.
• New Discord invite link — see the README / docs.

What's new​

• function serve — live-reload Crossplane functions from your local filesystem.
• One-line install script — curl -sL .../install.sh | sh to get the binary.
• Refreshed logos and README.

What's new​

• provider serve — develop providers locally with the same fast feedback loop already available for configurations and functions.
• Improved file watching for function serve.

What's new​

• Docs for configuration serve — basic guide for the live-reload workflow.
• Discord invite link added.

Bug fixes​

• YAML delimiter handling in the configuration package.

What's new​

• configuration serve — watch a configuration package directory and auto-rebuild + reload into the cluster on every save.
• README refresh.

Re-published to fix a release pipeline issue from 0.6.0.

What's new​

• Local registry appears in registry list — single, consistent view of every registry your environment knows about.