The Philosophical Developer — Chapter 13: Why Local Matters

All code for this series lives in the local-cloud repo on GitHub.

Three things converged in 2025-2026 that make this timely:

1. LocalStack’s Community Edition was sunset in March 2026. The go-to free local AWS emulator went proprietary overnight. Teams that built their entire local dev workflow around it suddenly needed an auth token, were hitting feature gates, or were paying.

2. Cloud providers raised prices across the board. AWS, Azure, GCP all increased pricing. Egress fees became a real business decision point, not just an ops footnote.

3. The local-first movement is maturing. From data sync (Automerge, CRDTs) to AI inference (Ollama, local GGUF), developers are pushing computation back to their machines. Infrastructure is the last frontier.

The thesis: If your infrastructure cannot run on your desk, you are renting understanding.

The emotional problem

Developers fear change because:

• The last time someone changed production, something broke and nobody could trace why
• Staging doesn’t match production, so “testing” is theater
• Rollback means praying the backup works
• New team members need weeks to understand the stack
• You don’t know something is wrong until a customer complains

This fear is not irrational. It is the logical response to infrastructure that is not reproducible, not traceable, not testable, not safe.

Four pillars

Reproducible — If you cannot reproduce it, you cannot trust it. git clone + one command equals identical environment. No snowflake configs, no “it works on my machine,” no tribal knowledge about how staging was set up differently than production.

Traceable — Every change has a lineage. Container image SHA traces back to a git commit. Infrastructure state traces back to a config file. Pipeline runs trace back to a branch. Prometheus alerts trace back to a deployment. You can answer “what changed and when?” without guessing.

Testable — Every assumption has a test. Infrastructure plans before applies. Health checks after deploys. Chaos injection to prove recovery. The pipeline IS the test suite. If you cannot test a change, you should not deploy it.

Safe — Fear of change is not a personal weakness. It is a rational response to infrastructure that cannot be tested or rolled back. Safety is engineered, not hoped for. Blue-green, immutable images, automated rollback. Change becomes boring because it is predictable.

The small investment

You can understand an entire AWS-scale platform with a few gigabytes of disk space and an afternoon. Not a course. Not a certification. Not a sandbox account. Your actual laptop.

Here is what we built:

The stack in action

Floci

Floci is a Quarkus-native AWS emulator. It starts in 24 milliseconds and idles at 13 MiB of RAM. Drop-in replacement for LocalStack at localhost:4566. No credentials needed. No auth tokens. Sixty-nine AWS services running out of the box — S3, SQS, DynamoDB, Lambda, IAM, CloudFormation, ECS, EKS, and everything between.

# Docker Compose service
floci:
  image: floci/floci:latest
  ports: ["4566:4566"]
  environment: [FLOCI_REGION=us-east-1]

Health check returns the full service catalog. You can curl localhost:4566/_localstack/health and see every service running.

k3d (not raw k3s)

Running k3s directly in Docker is a trap. The pid: host mode required for k3s makes containers un-stoppable — processes escape the container’s PID namespace, and docker stop hangs indefinitely. We learned this the hard way.

The answer is k3d — a tool built specifically for running k3s in Docker with clean lifecycle management.

k3d cluster create local-cloud
kubectl get nodes
# k3d-local-cloud-server-0   Ready   control-plane

Cluster creation, destruction, and kubeconfig extraction all work without fighting the container runtime.

Local registry

A Docker registry on port 5000. Stateless enough to run in a container, persistent enough to keep images between restarts:

docker build -t localhost:5000/hello:latest ./hello
docker push localhost:5000/hello:latest
curl localhost:5000/v2/_catalog
# {"repositories":["hello"]}

End-to-end: build, push, deploy

The proof is in the pipeline. We built a minimal Alpine container, pushed it to the local registry, imported it into the k3d cluster, and deployed it:

apiVersion: v1
kind: Pod
metadata:
  name: hello
spec:
  containers:
    - name: hello
      image: localhost:5000/hello:latest
      imagePullPolicy: Never

kubectl apply -f hello/deployment.yaml
kubectl logs hello
# Hello from local cloud!

Reproducibility proof

The real test: tear down everything and bring it back.

./scripts/down.sh   # destroy compose + k3d cluster
./scripts/up.sh     # recreate everything from scratch

The up script is deterministic:

1. docker compose up -d for Floci + registry
2. k3d cluster create for Kubernetes
3. Wait for k3d nodes to be Ready
4. Wait for compose health checks to pass
5. Build, push, import image, deploy pod
6. Verify all three services respond

Down + up cycle completes in under 2 minutes. Zero cloud accounts. Zero API keys. Zero credits.

What this means

We are not trying to avoid failure. We are trying to make failure irrelevant.

When your entire infrastructure can be reproduced from a single git clone, when every deployment traces back to a commit, when every change is tested before it touches running systems, and when rollback is as simple as destroying and recreating — fear of change disappears.

We move only forward. We are not defensive. We are proactive. We have a plan.

The measure of your infrastructure is not how many clouds you support, but how quickly you can reproduce it, trace a change through it, test every assumption about it, and sleep safely knowing it will recover from anything.

What comes next

This chapter proves the building blocks work. The next chapters build on them:

• Chapter 14: OpenTofu — Infrastructure as Code connecting to Floci
• Chapter 15: Pulumi (Go) — Programmatic infrastructure with real language semantics
• Chapter 17: Prometheus + OpenTelemetry — Observability from day one
• Chapter 18: Dagger — CI/CD that runs locally
• Chapter 19: Immutable Infrastructure in Practice
• Chapter 19.5: When Immutability Is Not Enough — Databases, streaming, and why immutability is a culture, not a checklist
• Chapter 20: Zero Downtime
• Chapter 22: Agent Orchestration — Hermes dispatching the entire pipeline

The code for this chapter lives at ~/workspace/local-cloud/ and will be published to a Git repository after we decide on the destination.

Also on LinkedIn.