Stealing NanoClaw Patterns for Web Apps and SaaS
In Part 1 I pulled apart NanoClaw's codebase and found six patterns that make an 8,000-line AI assistant surprisingly robust. But NanoClaw is a single-user tool running on your laptop. Surely these patterns fall apart once you've got real tenants, real money, and real scale?
Nah. Four of them translate almost directly — and the ones that don't still teach you something useful.
The credential sidecar
NanoClaw's credential proxy — where containers get a placeholder API key and a localhost proxy injects the real one — sounds like a neat trick for a personal tool. But this exact pattern is showing up in production Kubernetes deployments right now.
The broader version is a sidecar proxy that handles credential injection for any service that needs API keys or tokens. Your application code never touches the real secret. A sidecar container intercepts outbound requests, swaps in credentials, and forwards them upstream.
At Vend we managed a bunch of third-party integrations — payment gateways, shipping providers, accounting platforms. Each one had API keys that needed to live somewhere. We went through the typical evolution: environment variables, then a secrets manager, then a service that distributed keys at startup. Every step was an improvement, but the keys still ended up in the application's memory.
The sidecar approach skips that entirely. Your app sends requests with a placeholder. The proxy — which is a separate process with its own security boundary — does the credential swap. Even if your application gets compromised, the real keys aren't there to steal.
If you're running any kind of multi-service architecture where services call external APIs, this pattern is worth adopting. Your API gateway might already be doing a version of it — the insight is making it explicit and consistent across all outbound credential flows.
Isolation as the security model
This is the one I keep thinking about.
NanoClaw uses filesystem mounts to control what each container can see. No application-level permission checks — the security model is the infrastructure topology. If a container can't see a file, it can't access it. No bugs, no missed checks, no escalation vulnerabilities.
In SaaS, we spend enormous amounts of time writing authorisation logic. Role checks, permission middleware, tenant-scoping queries. And it works — until someone forgets a WHERE clause.
AWS's own SaaS tenant isolation guidance makes this point explicitly: authentication and authorisation are not the same as isolation. The fact that a user logged in doesn't mean your system has achieved tenant isolation. A single missed tenant filter on a database query and you've got a cross-tenant data leak.
The NanoClaw-inspired approach is to push isolation down the stack. Separate database schemas per tenant. Separate containers. Separate cloud accounts for your highest-value customers. Not instead of application-level checks — but as a backstop that catches the bugs your application-level checks inevitably have.
At Xero, working across the integrations and app store teams, I saw first-hand how multi-tenant data isolation gets complicated fast. The teams that had the fewest incidents were the ones where the infrastructure itself enforced boundaries, not just the application code.
You don't need to go full NanoClaw and give every tenant their own container. But you should be asking: if my application-level authorisation has a bug, what's my second line of defence? If the answer is "nothing" — that's the pattern to steal.
Polling when it's the right call
NanoClaw polls SQLite every 2 seconds. No WebSockets, no event bus, no pub/sub. Just a loop that checks for new stuff.
The instinct for most teams is to treat polling as a temporary hack you'll replace with "proper" event-driven architecture later. Yan Cui wrote a solid breakdown of push vs poll in event-driven systems and the takeaway isn't that one is always better — it's that the right choice depends on your throughput, ordering, and failure-handling requirements.
For a lot of internal systems, polling is the correct permanent answer.
Admin dashboards. Background job status. Internal reporting. Webhook retry queues. Deployment pipelines. These systems don't need sub-second latency. They need reliability and simplicity. A polling loop against your database gives you both, with zero infrastructure overhead.
At Xero we shipped multiple times per day, and some of the internal tooling that supported continuous deployment was surprisingly simple under the hood. Cron jobs. Polling loops. SQL queries on a timer. Not because anyone was cutting corners — because the requirements genuinely didn't need anything more sophisticated.
The trap is reaching for Kafka or RabbitMQ because you think you'll need it eventually. 70% of startups fail due to premature scaling. The infrastructure you don't deploy is the infrastructure that never breaks.
Your database is your message queue
NanoClaw uses JSON files on the filesystem for inter-process communication. Atomic rename, directory-based identity, simple polling to pick up new messages. No Redis. No message broker.
That specific approach won't scale to a multi-tenant SaaS — but the instinct behind it absolutely does. The instinct is: use the infrastructure you already have.
For most web apps, that means Postgres. The Postgres-as-queue movement has been gaining serious traction, and tools like PGMQ make it practical. You get ACID guarantees, you don't need to manage another service, and your queue is backed by the same database you're already monitoring and backing up.
NanoClaw's
atomic write pattern
— write to a temp file, rename into place — maps to INSERT INTO queue_table
followed by a SELECT ... FOR UPDATE SKIP LOCKED consumer. Same principle: the
message either exists completely or doesn't exist at all. No partial state.
The "just add Redis" reflex is strong in our industry. Sometimes it's the right call. But I've seen plenty of teams introduce a message broker for a workload that Postgres could've handled without breaking a sweat — and then spend the next six months debugging consumer lag and dead letter queues.
The real pattern
The specific techniques matter less than the discipline behind them.
NanoClaw's developer looked at a 500,000-line framework and asked: what are my actual constraints? Single user. Local machine. One AI provider. And then built exactly the architecture those constraints required — nothing more.
Most teams don't do this. They build for imaginary scale, imaginary multi-tenancy requirements, imaginary traffic spikes. They reach for Kubernetes before they've outgrown a single server. They deploy event buses before they've outgrown a polling loop. They write complex authorisation middleware before they've considered whether infrastructure isolation would eliminate the problem entirely.
The pattern worth stealing isn't the credential proxy or the polling loop or Postgres-as-queue. It's the habit of understanding your constraints first and letting them delete complexity from your architecture.
Hardest pattern to adopt, though. Because it means admitting you're smaller than you think.