Changelog - 042 - OTel for BYOC - Improved UI - Cleaner deprovisions - and more (link in 🧵)

There are many ways to meet EU data residency and sovereignty requirements. BYOC is one of them. Blog link in the reply.

Changelog - 041 - Nuon MCP - Health Checks - Triggers (for self-healing BYOC) - PR Previews, and more (link in 🧵)

The best platform architecture isn't always the one with the most features. Sometimes it's the one you know when to delete. Nuon recently ripped out container builds from our platform. At first, it made sense to build containers as part of the deployment process. But operating build infrastructure at scale created more problems than it solved: → Unpredictable CPU and memory spikes → Health checks failing during heavy builds → Kaniko blocking artifact vendoring → ~5 minute onboarding times → Dedicated infrastructure for every organization The realization was simple: building containers wasn't our core job. Customers already had CI pipelines producing container images. So we separated CI from CD. Customers bring their artifacts from their existing pipelines. Nuon handles the rest: orchestrating environments, infrastructure updates, and delivery across customer clouds. The result: → Setup time: 5 minutes → ~1 second → 64.6% lower control-plane CPU load → 74.6% fewer database operations → ~$6K in infrastructure savings in one month Sometimes the biggest infrastructure improvement is the infrastructure you stop running.

The moment you go BYOC, every customer environment starts looking different. One customer takes the full stack and doesn't care about the network. Another wants to plug your app into their internal APIs, their LLM provider, their database. A third has a hub-and-spoke network with strict routing requirements and a list of what you're not allowed to touch. That's before you get to storage policies, encryption key ownership, region restrictions, and the customers who want to bring their own S3 bucket because they've been burned by a public bucket before and they're not doing that again. Now multiply all of that by N customers. Each with at least a stage and prod environment. Some customers have 20+ environments running your app across their own customers' regions. Every change you make gets amplified across all of it. Different versions, different configurations, different ownership models, each environment a little different from the last. The instinct is to limit your architecture to make it manageable. Strip dependencies, simplify the design, constrain what you build. The better answer is tooling that bends to the customer: configurable inputs, toggleable components, per-install overlays, and continuous delivery that works across environments you didn't set up and often can't directly access.

Single-tenant and BYOC are one problem wearing two names. The only real split is whose account the instance runs in. Both models put the vendor on the hook for a fleet of isolated environments, one per customer. Both carry the same requirements. → Roll a version w/ visibility into who runs what → Keep each customer's secrets inside their own environment → Scope vendor access so a security team can audit it → Give each customer their own update approval window Now look at how single-tenant fleets get operated in practice. Runbooks, Terraform scripts, and a spreadsheet tracking which customer sits on which version. That setup holds until the fleet grows. → Upgrades turn into multi-week coordination projects → Non-prod soak periods get skipped because manual upgrades make them impractical → Standing up a new customer environment takes weeks instead of days So vendors staff two toolchains for one architecture. Hand-rolled scripts for the single-tenant fleet, a separate stack for BYOC, two procurement threads, two systems to learn and maintain. The two models sit a configuration change apart. Run both on one platform and you onboard customers faster, keep day-two operations in one place, and hold a ready migration path for the single-tenant customer who asks to move into their own account. A well-run single-tenant fleet turns out to be the rehearsal for BYOC.

BYOC breaks vendors in the same three places: (the sales demo surfaces none of them) 1/ Porting the app to infrastructure you never chose Each enterprise arrives with its own setup. → A locked-down shared Kubernetes cluster you deploy into → Their own LLM, whether Bedrock, Azure OpenAI, or Vertex AI → Their own S3 bucket and their own encryption keys Supporting that takes flexible, repeatable handling of custom inputs across CloudFormation, Azure ARM, and Google Deployment Manager templates. The commitment compounds with each customer you add. 2/ Operating after the deploy Provisioning is the easy part. Terraform handles it. The real work starts after. → Upgrades with zero SSH access → Drift detection when a customer admin changes something → Incident response inside an environment you neither own nor control Each state change needs an audit log. Each troubleshooting script needs customer authorization. Wide-open access models, cross-account roles and VPC peering, carry a wider blast radius and resist auditing. They collapse once customer requirements get complex. 3/ Scaling across the fleet One change, deployed dozens of times. The environments differ slightly, sit locked down, drift over time, and run separate versions with separate release windows. That stops being a deployment problem and becomes fleet management, and it gets harder as you grow. The buyers see it too. JPMorgan's CISO flagged SaaS concentration risk in an open letter to suppliers, and their own technology strategy team named BYOC a top emerging trend. Enterprise buying is moving toward software that runs inside the buyer's boundary. The vendors who treat these three as product problems, instead of services engagements, are the ones positioned to sell into that shift

git push, and every customer environment updates. App Branches are the delivery pipeline for your fleet of BYOC customers, whether that's 10 environments or 1,000.

Building BYOC in-house can costs $500K+ before the first install. Then $400K+ a year for as long as you keep it. An in-house BYOC is a full DevOps org commitment. → Kubernetes and containerization → Auth, networking, DNS, subnets, policies → Provisioning and secrets management → Health checks, upgrades, de-provisioning Then multiply all of it across clouds and customer environments. Our latest post puts real numbers to both paths. Building in-house → $598K upfront, nine months of build time → $409K per year to maintain → The maintenance line is three DevOps engineers giving 30% of their time, indefinitely Buying → $138K upfront → $238K per year → 114% ROI over three years on a greenfield decision For vendors already running a homespun build, the switch breaks even in roughly 10 months, and the savings compound from there. The spreadsheet leaves out the biggest line item, focus. Each engineering hour spent on deployment plumbing comes straight off your core product. Dollars you recover. Roadmap time stays gone.

S3 started as blob storage. Files in, files out. In 2006, that was enough. Twenty years later, it's become the default infrastructure primitive for an entirely new class of software: stateless, portable, and customer-owned. Here's what’s changed: Versioning shipped in 2010. Read-after-write consistency in 2020. Conditional writes in 2024. Each one replaced a workaround that developers had been maintaining in application code for years. Each one made it viable to build genuinely distributed, stateful systems on S3 without bolting on a separate locking store or metadata layer. Stack that with S3 Express One Zone (10ms reads/writes), VPC endpoints for private network lockdown, and replication for cross-region consistency. All behind the same API. Now you have a storage layer where the customer picks their own tradeoffs. That API stability is what turned S3 into a standard. WarpStream built a 10x cheaper Kafka alternative on it. Turbopuffer and Chroma are building vector search on it. SlateDB embeds a durable database directly into applications, backed by object storage. Tigris extended the S3 protocol and shipped bucket forking: Git-style versioning for entire buckets. For BYOC, this matters a lot. If your software uses S3 as its data layer, you can deploy it into a customer's cloud account and it works with their bucket, in their VPC, on their terms. The customer owns the data. You get a consistent API. No separate storage layer to manage on either side. We wrote up the full picture: the history, the features, and the companies building on it.