Pinned Tweet
Today I'm excited to share that Nuon is officially open source!
You can read more about our announcement here: nuon.co/blog/oss-announcemen…
Underrated change here is our new OTEL engine.
Excited to see more and more teams building with Nuon as the center of their BYOC operations hub.
one of our teammates on GTM recently built an interactive onboarding app + shipped it as a Nuon BYOC app
I found out today when demo'ing for a customer 😂
This is the future of marketing: interactive micro-products to help users learn new concepts
Everyone's been busy talking about WAL on S3.
What I'm more interested in are OCI repository tools on S3. ORAS + modern container management has made OCI the defacto standard for not just moving around container images, but also to ship things like helm-charts and more.
Lower level tools in the space on S3 give us all much better primitives for moving policies and things around. You would be surprised at how effective OCI can be as a central artifact, policy and state store.
For the last 6 months, I've driven almost all of my AI coding via ACP (within nvim).
Sometimes, I'll interact with the agent CLIs directly for ideas, but I've found a lot of value in managing my own harness around the agent.
This week, I started using @cursor_ai's agent via this workflow and can say it's the best experience by a long shot I've used.
if curious, I use github.com/agentclientprotoc… from within neovim (forked avante).
Let's me build my own hooks and other functionality in python and is really fast.
I've spent a lot of time thinking about building a great MCP experience for a dev-tools product.
What I've landed on is that you need a remote / API based MCP and you need some sort of local proxy built into your CLI (assuming you have one)
Why? it's about context management.
Basically, this is a local stdio proxy to our API MCP tools.
If you are logged in, you can get started by just hooking that command up to your agent.
Then, we let you add contexts. You can define new contexts (different permissions, apps, installs etc).
Kind of like kubectl
I'm really bullish on a class of primitives like this + Slate powering the next wave of infrastructure.
Provable correct building blocks go a long way. Great read!
A good time to remind you that WAL-on-S3 sounds simple but the correctness protocol is subtle.
I wrote a full post on this a while back which goes over the primitives and protocols for making sure your object storage usage is correct: bitsxpages.com/p/protocols-f…
Wonder how many millions of dollars of tokens have gone to people trying to build something viral using s3 the past few days.
It’s having a moment and I’ve seen like 15 new projects on my timeline.
Capacity isn’t a failure mode when you do BYOC.
It’s a customer issue and decentralizes compute.
our CTO @Vlad_GitHub wrote up the August 17 outage, good to read in full. tldr: outage was not due to code or config changes. both were capacity failures, we didn’t scale ahead of demand.
that’s on us. we’ll earn trust back through the platform actually holding up, not through saying so.
github.blog/news-insights/co…
With everyone talking about s3 on here, I’m surprised I haven’t seen more posts about SlateDB
I have a feeling most will end up using abstractions on s3 to build with (streamstore, Ursula, slate)
One of my favorite parts of working @nuoninc is messaging @harsh_thakur_1 an idea, and he’s already built it 😂
one of the early things we did was add an extension framework to our cli, and that’s let us solve a lot of customer problems before we know how to add them to the platform
I give it less than 18 months until every major dependency in the SDLC is built on S3.
And … 36 months tops until every major runtime dependency (workflow engines, dbs, search) are on S3
Every new infra tool built from the bottoms up for s3 unlocks easier operations, better performance and easier integrations.
Fuels more investment into the cloud providers / storage providers which leads to more capabilities built into the protocol.
It’s already proven at scale, and I don’t see this slowing down.
The first thing you’ll get push back from customer’s when doing a BYOC deployment is your permissions.
Sure, you need permissions for setting up your app (pushing updates, and when things go wrong debugging.)
However, if you go in with one role and can’t justify all permissions and how they will be used, your customer will say no.
We recommend splitting into three modes:
1. setup / teardown - more broad pemrissions to setup the app. Can be removed after a setup window or call
2. Maintenance - the minimal amount of permissions you need to push updates and manage service of your product
3. Break Glass - for all the other things. Toggle’able permissions, your customer can enable when a migration is needed or mid-outage.