AWS Puts Superblocks Vibe Coding in Your VPC
Superblocks signed a multiyear deal with AWS that lets its vibe-coding tool run inside a customer's own private cloud.
The agreement, announced on August 3, 2026, is a joint marketing arrangement: AWS helps sell Superblocks into enterprise accounts, and Superblocks runs where those accounts already keep their data. Apps that business users build will spin up Amazon Aurora databases inside the company's own AWS account instead of reaching for an outside service, and they will call models through Amazon Bedrock. The practical effect is that internal tools built by people who don't write code land inside IT's existing perimeter instead of outside it. Superblocks is a small company — 50 employees, $60 million raised through a Series A announced in May 2025 — which makes the choice of partner the more interesting half of the story.
· Multiyear joint marketing agreement; AWS co-sells Superblocks to its enterprise customers, as it does for many Marketplace partners.
· Apps stay inside the customer's own cloud. Data and information do not go out to external model providers or databases.
· Databases are Amazon Aurora inside that account, not an external Supabase project.
· Model calls route through Amazon Bedrock, AWS's app development, gateway, and inference layer.
· Superblocks: 50 employees, $60 million raised as of its May 2025 Series A, backed by Spark Capital, Kleiner Perkins, Meritech Capital, and Greenoaks.
Superblocks co-founder and CEO Brad Menezes. The company has 50 employees and raised $60 million through its Series A, announced in May 2025.
What the Agreement Covers
Vibe coding means describing the app you want in plain language and letting a model build it. Up to now that has mostly meant a public SaaS product: the tool runs on the vendor's infrastructure, and whatever the business user builds lives there too. What the Superblocks deal changes is the address. The tool can be embedded within the private clouds of AWS customers, so an enterprise that subscribes can hand vibe coding to its business users without the output leaving the company's own account.
There are two halves to it. The technical half is placement — the generated apps run in the customer's cloud, provision Amazon Aurora databases there, and integrate with Amazon Bedrock for model access. The commercial half is distribution: AWS will help sell Superblocks to enterprises the way it does for many of its Marketplace partners. "We support partners where we see strong customer demand and alignment with how customers want to build," an AWS spokesperson told TechCrunch.
Superblocks co-founder and CEO Brad Menezes frames the placement as the whole point.
"We're going to bring it to your data inside your private cloud. The big thing about that is data never leaves. … It's their AWS account and basically secure with all of the auditing, all of the encryption, all of the network controls."
Read plainly, that sentence is about inheritance. The app doesn't get a new security model; it inherits the one the company already runs.
Aurora Instead of Supabase
The database detail deserves more attention than it usually gets. When a business user vibe-codes an internal tool on a public product, the app typically creates an external Supabase database — the vibe-coding database of choice. Every table it writes becomes a copy of company data living in a system that procurement never reviewed and that the security team may not know exists.
Under this arrangement, the same act of building produces an Aurora database inside the company's own account. The person building the tool notices nothing different. The blast radius is what changed: the data sits where the existing encryption, network controls, and audit logging already apply.
Dimension
Typical hosted vibe coding
Superblocks in your AWS account
Where the app runs
Vendor infrastructure
The customer's own private cloud
Database
External Supabase project
Amazon Aurora inside the account
Model access
Direct calls out to a provider
Through Amazon Bedrock
Governance
Outside IT's view
Under IT's management and security
Bedrock plays the same role on the model side that Aurora plays on the data side. Instead of the finished app holding a credential to one outside provider, its inference goes through a layer the account already governs. The result, in Menezes's framing, is that these apps automatically fall under IT's management and security, rather than be rogue applications — which is a fair description of what most internal AI tooling has been so far.
The Gap Kiro and Quick Leave
AWS is helping sell this partly because it doesn't have the product itself. It has Kiro, an AI coding agent aimed at developers, and Quick, an AI assistant for business users. Neither is a vibe-coding agent for the business side.
The distinction matters. Quick sits closer to something like Claude Cowork or Microsoft Copilot — an assistant that helps you work — than to Lovable or Replit, which hand you a running application at the end. AWS covers the developer case and the assistant case, and the space between them is exactly where Superblocks fits.
For a 50-person startup, that gap is worth more than any engineering AWS could have contributed. Getting co-sold into enterprise accounts is a distribution channel that a Series A company cannot buy at any price, and it arrives while the category is still small enough that being early counts.
Why Clouds Want the App Layer
On its own the deal is a modest item. As a signal it is larger, because it fits a pattern the hyperscalers have been building toward: push enterprises to separate the model from everything wrapped around it, then sell the wrapping themselves. Harnesses, agent orchestration, security tooling, the app layer — the clouds want customers buying that from them and not from the frontier labs.
Microsoft CEO Satya Nadella has been making that argument out loud in recent weeks. His pitch to enterprise customers has two parts: run multiple models to hold costs down and avoid lock-in, and don't hand agent orchestration or app-level harnesses to the labs, because they may study your business through that data and later compete with you.
Take or leave the motive — a cloud vendor arguing that you should buy the scaffolding from a cloud vendor is not a neutral party. The architecture the argument implies is the part worth noticing, because it treats the model as a swappable component and the surrounding layer as the durable purchase. AWS embedding a third-party vibe-coding tool into customer VPCs is that architecture showing up as a product decision rather than a keynote slide.
The Multi-Model Flip
Enterprises may not need the warning. Menezes says his customers moved on their own, and fast: "That is flipped because 60 days ago they were like, I want a specific model. It's called Anthropic." Two months, by his account, from single-vendor preference to spreading across providers, with Chinese open-weight models a large part of the shift.
One outside number points the same direction. Open models accounted for 29% of all traffic routed through Vercel's AI gateway last month — and a gateway is where enterprises manage multi-model use, so that traffic is mostly deliberate, not experimental. Once a company is genuinely running several models, none of its scaffolding can be tied to a single provider without undoing the point.
Menezes puts the requirement in blunt terms:
"Having a multi-model strategy across big frontier labs, OpenAI, Anthropic, and open source — and I'd say Chinese open source right now, but also U.S. open source is now starting to come up. It's a must-have for the CIO."
He goes further and predicts that "any enterprise that is betting on a single model provider, that executive will be fired." Worth discounting for who is speaking: he sells the layer that makes swapping models easy, so the prediction is also a sales argument. The direction still matches the Vercel figure, but treat the certainty as his, not as established fact.
What Changes for Your Team
If you already run on AWS, the concrete change is that a business-user app builder can now be bought as something that produces artifacts inside your governed account. The shadow-IT problem shrinks by architecture rather than by policy, which historically works better than asking people not to use the fast tool.
If you are evaluating any vibe-coding product, this deal hands you a checklist. Where does the generated database get created, and who owns that account? Which model endpoint does the finished app call, and can it be changed later without a rewrite? Does the app inherit your existing logging and network controls, or does it come with its own? Those three answers now separate products that would have looked identical in a demo.
It is reasonable to expect other clouds to arrange something similar, since the same gap exists across the hyperscalers — but that is an inference from the pattern, not something either company announced. AWS's own comment stays at the level of category: "It's an emerging category with real momentum, and exactly the kind of innovation we support."
One thing the arrangement does not solve is what gets built. Running inside a VPC keeps the data in place; it does not review the logic, check the permissions the app grants itself, or stop three teams from building the same tool. Placement is a governance floor, not a governance program.
The Short Version
AWS agreed to co-sell Superblocks and let it run inside customer clouds, so business-user apps now create Aurora databases and call Bedrock inside the account that already has the audit trail. The reason it matters beyond one startup is that it makes the model a component and the surrounding layer the product — the same bet Nadella has been arguing for, arriving here as a signed agreement. For anyone buying this class of tool, the useful question changed from what can it build to where does what it builds end up.