EPISODE 1950

[INTRODUCTION]

[0:00:00] ANNOUNCER: For two decades, the cloud has been shaped by human developers writing code and managing its deployment. Now, a growing share of production code is generated by LLMs with little human review. Because that code is not fully trusted, it increasingly runs in isolated sandboxed environments. Meanwhile, AI agents are starting to operate infrastructure directly by spinning services up and tearing them down on their own. Together, these shifts raise the question of whether the cloud needs to be rebuilt for machine operators rather than humans. 

Render is a cloud platform designed for application deployment by handling scaling, self-healing, and security to reduce operations work. Render has been adapting to the AI era by building tools that let agents deploy and debug applications directly with added guardrails and security. 

Anurag Goel is the founder and CEO of Render. In this episode, Anurag joined Shaun Falconer to discuss why so many teams end up rebuilding the same infrastructure on top of Kubernetes, what changes when AI agents become first-class users of infrastructures and the guardrails that shift demands, and why the economics of AI are pushing developers towards higher-level platforms that trade fine-grained control for speed and safety. 

This episode is hosted by Sean Falconer. Check the show notes for more information on Sean's work and where to find him.

[INTERVIEW]

[0:01:42] SF: Anurag, welcome to the show. 

[0:01:43] AG: Thank you, Sean. It's great to be here. 

[0:01:45] SF: Yeah, absolutely. I've been looking forward to this. I wanted to go back a little bit in time and ask you a little bit about your history and maybe how some of those experiences led you to founding Render and everything that you're doing there today. You were roughly, I think, around the eighth employee at Stripe. 

[0:02:04] AG: Yes. 

[0:02:05] SF: Yeah. By the time you left, how many engineers were managing AWS? I guess what did that experience kind of teach you about cloud complexity and the actual cost companies are putting into just simply managing this beast of the cloud? 

[0:02:18] AG: Yeah. At all times when I was at Stripe, around 15% to 20% of the engineering team was simply managing VMs on AWS and all the complexity around that storage and networking and load balancing, and it didn't really get easier. And obviously as Stripe scaled grew, the complexity increased, and you needed to continue to hire people to continue to help you scale, and it just never stopped. 

[0:02:51] SF: I also think if you think about like Stripe or even other examples of great engineering organizations like that, they're probably one of the best engineering organizations in the world. And if they're running into this problem, clearly, it's a problem that's going to essentially impact everyone if they can't figure this thing out. 

[0:03:09] AG: Yeah. And just to be clear, I do think that Stripe did the best they could at that time because that was really the only way for them to run in the cloud reliably and scalably. But as technology changed, as containerization took hold, it became clearer to me. And I'm talking about the 2017-2016 era when a lot of people were containerizing their apps, but then they had to deal with Kubernetes complexity to actually run these containers in production in a way that was scalable, or secure, or reliable. 

It became clear to me that you could give app developers and specifically app developers, not DevOps engineers, because Render has always focused on application developers. You could give application developers the same powers that they would get from the most accomplished world-class internal DevOps team, and you could do it in a way that was entirely self-served for them. And they could simply focus on pushing their code and then get out-of-the-box primitives for scaling, for self-healing, for all kinds of state management. And they would get effectively one of the best DevOps teams in the world productized, and that's what Render ended up becoming. 

[0:04:34] SF: Mm-hmm. Yeah. I guess before kind of getting into specifics on Render, what kind of breaks down - you have people using containers, using containerized, or orchestration platforms are well sort of established in the industry, like Kubernetes. But at the same time, it seems at scale that's a very hard thing to just manage. Given that there's all this industry investment into Kubernetes, what is it that specifically kind of breaks down as teams start to try to scale the management of that? 

[0:05:04] AG: Yeah. We do manage a lot of Kubernetes clusters ourselves, and we see this first-hand. I think it all depends on what kind of application architecture you're working with. If it's a really simple application, then it can run anywhere. It can run on Kubernetes, it can run on Heroku, it can run on other cloud providers. But as you start to become bigger, if your business is growing, you start needing more configuration around which applications can talk to each other. You start needing the notion of CI/CD needs to work in a certain way. You need to have certain environments be protected. You need certain services to be not available to the internet. You need observability across all of this. And then you need to be aware of when something goes down. You need to get alerted, and then you need to go solve that problem yourself because you have to then understand, well, you stood up on Kubernetes, and you need to understand sometimes exactly how Kubernetes works under the hood to know, well, this network policy change is what caused this DNS error. 

And with Kubernetes, you have to manage all of these things yourself. You spin up even on "managed Kubernetes clusters", you have to write a lot of YAML by hand that describes how to deploy your applications. But really what that YAML is doing is describing a lot of the internals of the Kubernetes architecture and the Kubernetes concepts themselves. And then as your application scales, things become bottlenecks, and then you have to kind of manage those bottlenecks by understanding exactly what that is. You might never have encountered it, but suddenly you have a lot of internal DNS traffic because your application grew and now your core DNS isn't working anymore. Well, who takes care of that? And then you have to go figure out how to configure core DNS to serve all that traffic. 

It's every layer of the infrastructure stack within Kubernetes and even below it because you also have to figure out how to keep your VMs patched when things happen, and you have to deal with node pools, and you have to configure different nodes for different things, and you have to make sure that your nodes are also well utilized. You have to pay for a lot of extra capacity because that's what Kubernetes likes to do. And you end up spending way more on just managing lots of unused Kubernetes capacities just so you can deploy your application the next time. 

[0:07:34] SF: Yeah. And then I think companies end up spending a lot of time on COGS optimization because their cloud bills grow, escalating and getting out of control. I made this point recently about sort of data infrastructure where we have all these great data tools today, but the complexity of actually managing our data has not decreased as we've gotten better tooling. It's actually gotten harder because there's just simply more data; there's more complexity involved. And now we have a bunch of tools that we also have to kind of understand how those things fit together. 

That kind of sounds like the same problem when it comes to managing network infrastructure. We have all these great tools; we have elastic scalability, but there's a lot of complexity making this sort of juggernaut and different services work together at a reasonable way, essentially at scale. 

[0:08:23] AG: Yes, exactly. And different parts of your application might scale differently, and so you just have to manage all of that across the board. And even understanding Kubernetes is not something you can sort of just do. You can't really build your Kubernetes YAML using AI because AI makes mistakes, and you have to understand when it does make a mistake because something will stop working at 2am at night, and then AI won't really be able to tell you what it should change because you just wrote it with AI. You have no idea how the thing works. And then you don't really want to be vibe coding your infrastructure when something's down. 

[0:09:01] SF: Yeah. Yeah. And I would think that I'm sure we'll touch on AI because you can't really have a conversation in technology without talking about AI these days. But as people are using AI to generate more code, we're creating essentially more abstraction from the details of the code. There's going to be, I think, more buffer between really understanding the deep internals of how that thing was built and run in the interest of essentially speed, which then, when things go wrong, of course, makes it even harder to kind of debug and understand what's going on. 

[0:09:31] AG: Exactly. 

[0:09:31] SF: I've heard you mention that you've observed that every company that runs on Kubernetes ends up building some version of an internal pass that all kind of look roughly the same. Why is it that teams end up insisting on building their own thing? It kind of reminds me a little bit of in the early days of Auth: every engineer wrote Auth eight different times across every company. And eventually services came out that take that thing off of people's plate. But why is it that we're still in this place where people are writing these internal passes?

[0:10:03] AG: I think there's a little bit of, "Well, this is how we used to do it. So why change?" And there's also a generational thing. A lot of people learn to build cloud infrastructure using the tools that AWS gave them. And then Kubernetes was sort of this state that we ended up in. And you just sort of assume that that is how you always do it or that's how you will always do it. But I also now see from Render's perspective, we actually see teams moving from large Kubernetes clusters to Render because they get all the functionality that they're looking for without having to deal with the complexity of Kubernetes. 

And interestingly, that's happening more and more now, just partly because - and I'm sorry to bring up AI again, but so many more people are building so many more applications with AI that this whole notion of statically managing your cluster using a DevOps team is breaking down. It's breaking down very quickly because the DevOps teams are stretched thin beyond capacity everywhere. And they're just trying to keep up with the core application, but then everyone else is like, "Well, I have this other application I want to stand up." Well, good luck because you can only do so much with a small DevOps team or even a large DevOps team. 

[0:11:20] SF: Yeah. I mean, I think that if you look at sort of the traditional software development life cycle of discovery, design, implementation, testing, productionization, that kind of thing running in a loop. If historically the coding part, the implementation piece, was like kind of slow and hard, the other things around it could kind of be relatively slow because it was not as slow as the thing in the middle, which was actually writing the code. But now we've compressed that time. If people generating, instead of having two apps, they're generating two apps a week, the crippling slowdown, the company suddenly becomes the DevOps team. And how do you actually run the platform? 

[0:11:56] AG: Yeah. And that's exactly what we're seeing. And it's why Render has grown more in the last 2 years than in the previous six. It's actually really interesting to see so many more companies come to us now that already have existing DevOps teams. That was not the case 2 years ago. 

[0:12:13] SF: Yeah, it's interesting. I mean, you mentioned that in terms of why is it that companies are still continuing to build their own internal paths is perhaps because of the history essentially of people being kind of trained to do it. And this becomes sort of the default of like, "Oh, this is how you have to do it." 

One of the knocks I've heard historically against platforms as a service that have tried to ease the challenge of kind of running infrastructure has been that at some point the company outgrows that and you have to get to a place where you're managing the knobs directly. Do you think that is going away, or do you think that's an unfounded reflection on the reality of a platform as a service? 

[0:12:50] AG: Yeah, for the majority of applications out there, you really don't need something like Kubernetes. And Render, especially as we've continued to add more functionality, more customization, more flexibility, more power to Render, we've continued to raise the ceiling on what's possible. And we continue to do that as a platform. 

Now, I know I've seen other platforms where you hit that ceiling much, much, much sooner. For example, with Heroku, you can't get more than 14 gigs of RAM if you wanted to build an application that did that, or your application was restarted every 24 hours. And there was just a very small number of compute plans that you got out of the box. Private networking isn't available in the self-served version. There's no way to store data on a disk. There were so many reasons for why you grew out of Heroku really quickly. And Render has always built for people who are building complex, ambitious applications. And we want to make sure that you never outgrow the platform because we think that we can continue to raise the ceiling on what a platform can do. 

And we've been able to do that with a lot of our customers and some of our - I mean, OpenAI and Stripe are amongst Render's customers. Obviously, they use other cloud providers. But we also have companies Base44, which is one of the largest bike coding platforms in the world. They're running all of their compute for their web apps on Render. And they're able to scale with Render. They're now part of Wix. And Wix has some infrastructure on AWS. But Base44 runs really well on Render, and they want to stay on the platform even though now they have access to this massive DevOps team inside Wix that has access to AWS. 

[0:14:41] SF: Mm-hmm. What are the things that you have to do specifically to make it so that people don't outgrow you? And how do you think about sort of balancing, I guess, blurring the lines between automating it, making it really easy, and hiding some of the complexity while also giving enough controls to your customer to not outgrow you or not get frustrated with some opinionated view of how this should be done? 

[0:15:05] AG: Yeah, that is really the crux of how we think about product and specifically progressive disclosure of complexity. To give you a really simple example, something that happened recently, we gave a customer a specific control that was only available in our REST API because they were creating services through the REST API. They're not using the dashboard. Their use case is actually quite complicated, and they want to use Render just like they would use AWS, where they would spin up a VM and install things on it and spin up an application there. With Render, you can do all of that in a single API call. But most of our users don't need that specific thing that they want. And so we're not going to expose it to everyone in the dashboard. 

And so it's stuff like that where you kind of think about who needs something, and what's the surface area of how they're using Render, and how do you expose that feature in a way that is fully productized, fully supported, but it may not be something that everyone has to think about all the time. 

[0:16:09] SF: Mm-hmm. I guess it's a little bit like you mentioned, sort of progressive disclosure. It's kind of a little bit how video games work, where you start on level one, you have kind of limited amount of functionality. And then over time, as you get more comfortable to controls, they add more and more complexity to it. And by I don't know, level 15 or something like that, you're an expert. But not everybody's going to get there. And some people just want to come in at level one and have a good time. 

[0:16:33] AG: Yeah, exactly. And the other thing that is changing is a lot of people are now using Claude or Codex to manage their Render deploys. And we have skills and MCP servers that allow them to do that. And the complexity is hidden away a little bit further from them. Even though Claude and Codex can actually look at all the different things in our API and make the right calls, and they could create our infrastructure as code format called blueprints, and they can describe the application of blueprint. So you don't have to understand what a blueprint even looks like. 

But the main thing is that Render operates at a much higher level than, say, AWS. We operate at the level of the application. Even if you're using Claude and Codex, you don't really need to understand a lot of complex infrastructure concepts. You really need to focus on how really your application runs on Render, which is a very small surface area, typically depending on the complexity of your app. And you can debug it fairly easily given the tools that we have. And these days, again, because of the tools we've built for AI agents to debug Render, people are able to do a lot more themselves. 

And again, I should clarify that we're building all of this for application engineers. We're not building for DevOps people. The kind of tools that DevOps engineers might want, we don't worry too much about not having them. But if you're building a standard AI native company, or a SaaS, or whatever it is, there's a 95% chance that you don't need to go to AWS. And there's a smaller number of companies if you're building an infrastructure company yourself. If you're building, say, a database company that needs to really go down to the metal and figure out exactly how the database clusters are going to work together and use some esoteric AWS incantation, then you should not be using Render. It's not for you. But if you're an application developer, you can really use Render and continue to use Render as your application grows. 

[0:18:35] SF: Yeah, it makes sense. I mean, I think that there's always going to be a spectrum, right, of the types of applications that we're building. Are you building core infrastructure? Are you building more of an application? And do you need scale for users? You mentioned AI management of infrastructure there. How do you think about as people leverage tools like Claude Code, Cursor Antigravity, whatever it is, more and more, I think the tools that are going to be really successful in kind of this agentic engineering era are the ones that are easy to use as a default experience from the agentic engineering experience itself. Has that been something that you've thought about at Render? How do we make ourselves essentially usable by AI and AI agents to be successful in this new wave? 

[0:19:17] AG: Yeah, we think about it a lot because our users are already using us with Claude, and Codex, and Antigravity. They prefer it because they're already in there. They're already coding using these tools. And so why not deploy using these tools? And why not debug that your deploys are using these tools? 

We've made it so that our MCP server can give you all the information that you need that we expose the right kind of tools that allow you to spin up new applications. But we're also now thinking about how you can build systems that can be reverted if your agent makes a mistake without losing data or without causing some sort of massive disruption to your infrastructure. 

We're also thinking about how, if we can identify that it's an agent user, then you can say, "Well, if it reaches this level of severity or this level of cost, then I need a human-in-the-loop to approve it." Those are some things that I think not just Render, but everyone will have to build as agents start using these applications more and more, using their API, or CLI, or MCP server. 

[0:20:23] SF: Yeah. I mean, a lot of people talk about guardrails around these things. But I think from infrastructure, guardrails around the cost as well, because you don't want to accidentally spin up something that suddenly you have a huge bill for because some agent made a decision that was not necessarily the right decision. For MCP, was there specific things that you had to do design-wise that was above and beyond what the Render APIs were capable of? 

[0:20:46] AG: Yeah. When we first launched our MCP, there were certainly some things that we did not put into the MCP that you could use our API for. But in general, our MCP is able to do a lot that Claude and others wanted to do. One of the big things that we did was the ability to really pull logs and deploy data in a way that can then help you troubleshoot failing deploy. And you can get metrics from the MCP as well. 

And so what we find is that a lot of people use our MCP to debug what's going on, especially when they're developing the application, and they're in this loop of quickly pushing code and seeing what happens. And so it makes it really fast for them to develop on Render because all of that stuff is available as tools in Claude, and Claude can correlate deploys with what happened in production. 

[0:21:40] SF: Mm-hmm. Yeah. I mean, that's a common pattern that we see at Confluent, which is where I work. My day job as well is I think, the number one use of our MCP servers, probably outside of exploring the data that you have, would be around debugging. And I've even seen recently some clients out there putting into their contracts with vendors that they're considering purchasing from within the contract essentially need to know what is their support for agent debugging. 

[0:22:08] AG: Yeah, makes sense. 

[0:22:09] SF: Yeah. I mean, it's just the way the world's kind of going. Why leave the tool that you're in all day to go into login some dashboard? 

[0:22:16] AG: Yeah. Exactly. And I think dashboards are great for maybe when you're first trying to explore a new tool, and you want to understand the different concepts. But once you have a good sense of what's going on. And maybe these days you don't even need that because you can build the exploration into your API or your MCP server just like any MCP server can expose the tools that are available to the LLM. 

[0:22:43] SF: Mm-hmm. How do you think about balancing, just from a product standpoint and a resourcing perspective, where to put your resources if the world is kind of largely going towards some sort of unified experience from the terminal, from a CLI interacting through these agents? Does that mean that you put less time and effort behind the user interface, your web-based interface into Render to put more time behind your MCP and your APIs, which are going to be more of the native experience that agents are interacting with you? 

[0:23:14] AG: I don't think that we're treating it that way. We still want to continue to improve our dashboard because I think people do like a visual experience for certain things. And again, if you want to see a lot of information in a very specific way, then often very purpose-built info-dense views that are designed with that workflow in mind might be more efficient than using Claude or MCP, and might be faster. So, I don't think that we can do either or. 

We're actually increasing our investment in both. We're hiring people. We're hiring design engineers to continue to grow the dashboard and with all the new tools that we're supporting. And I don't think developers are saying, "Look, I never want to use the dashboard." They're just adding another interface. And it depends on maybe where they are in their journey. If they're coding and pushing code, then sure, they need that MCP server. But sometimes when something goes wrong, sometimes they do need to go into the dashboard, or they do need to see all the metrics in one place, or they do need to look at all the logs manually. So, that's not going away. And there's an element of discovery that I'd say is still a lot easier to do visually than through Claude or through tools that are fundamentally text-only. 

[0:24:38] SF: I agree. I mean, I still think the UI is the store window of the application where people kind of discover things. And the other thing, too, is sometimes an open-ended chat is not necessarily the best user experience. It's great if you kind of know what you're looking for. But if you don't, then it's easier to be sort of prescriptive and point people in the right direction when you have a user interface. 

[0:24:59] AG: Yes, absolutely. And you can really focus on the workflow that the user is trying to go through and make your dashboard very specific to that. And that's a lot easier to do, and it makes the user more productive than giving people a generic MCP server to do whatever. 

[0:25:18] SF: Mm-hmm. Yeah. You started moving workloads to bare metal, I think in mid-2025. And I've heard you say that it was more about control than necessarily cost. Because in that scenario, what do you mean by control? 

[0:25:35] AG: Yeah. I do want to maybe issue a correction there. So we didn't actually move customer workloads to bare metal until just a month or so ago. Yeah. So we've been waiting, but it's happening now. And the cost versus control thing is really interesting because we are finding more and more reasons to run things on metal itself because of the nature of untrusted code and its need to run in micro VMs. And microVM certainly run better on metal. Even though they can run in a nested VM scenario, the performance characteristics are different. And they're almost always going to be much more performant running directly on metal. In the case of Firecracker with a KVM hypervisor, it's a lot easier to do that on bare metal than on some nested port situation. 

The control that we get is we are able to tweak the hypervisor. We're able to control the different elements of the machine in a way that is very specific to the kind of workloads that Render runs. And you could get metal machines in the cloud from AWS or others. And I'm pretty sure we're going to utilize those machines as well. But in the long run, I think that we want to be able to look at even things like placement of your application and your database. Maybe if we can, even on the same rack. Now, you don't get rack-level placement controls as far as I know on AWS. 

It's stuff like that where you can really hyper-optimize things and go down to the level of, "Okay. Well, this is the best possible performance, or cost structure, or the kind of CPU." That's really the kind of control you get when you own your own metal. And with AWS metal, I think you get some, but it's the metal that AWS has. And you don't get, for example, a concept of different machine sizes. AWS machines are all the same size. The largest possible plan is the metal plan. And you can't get a metal plan that's either larger than that or smaller than that. 

[0:27:51] SF: Mm-hmm. Okay. And you also recently launched Render Workflows, which is durable execution for long-running stateful processes. What was the motivation around that? I feel like durable execution, probably in the last year, is finally having its moment. 

[0:28:05] AG: Mm-hmm. 

[0:28:06] SF: Is that being driven in part by the investment companies are making around AI? Or is this something else that's sort of driving this interest in durable execution? 

[0:28:15] AG: Yeah. What we're seeing is applications themselves are now very dynamic in nature. When you build an agent, for example, and your user asks the agent a question, the first question might pull up 10 records, the next one might pull up 400. And then the tasks themselves could also be really diverse. It could be a web scraping task, or a headless browser thing, or maybe just data crunching that requires 128 gigs of RAM. 

Instead of what used to happen, where these asynchronous tasks were as simple as sending an email or processing a payment, our asynchronous tasks have become very, very diverse and heterogeneous. And as a result, it's become very hard to build these asynchronous processing systems using standard background workers and queues. And that, I think, is why durable execution is becoming really popular. People want to run a series of tasks. And then they also want to be able to provision different kinds of compute for each task. 

And with Render workflows, all you need to do is define your task in code. And so any task that you want to run, you can define it in code, and then you can trigger it in code as well using Render's SDK. And Render just takes care of the execution without you having to provision any compute yourself. So you don't have to stand up workers; you don't have to stand up queues. And we give you all the flexibility around how many times you might want to retry the task or the concurrency level for each task that you want. 

And in many ways, when you try to do this with a queue-like system, you end up building very diverse sets of worker pools, each with its own memory or CPU requirements so you can process the diversity of your tasks. And with durable execution on Render using workflows, you don't need to worry about any of that; it's much simpler. And we take care of the compute for you. We give you a great observability view into exactly how your tasks are running, which ones are failing, which ones are being retried, the inputs and output to each task, for each task. And it's a really great experience for people who are simply trying to run non-deterministic flows in response to user requests. 

[0:30:44] SF: Would this be something that's directly competitive with the durable execution frameworks that are out there, like a Temporal, Restate, Orkes? Or is it more aligned with both GCP, AWS have as now like stateful functions, for example, where I can call a function and it can control the state and recover from failures and so forth? 

[0:31:04] AG: In some ways I think it's the best parts of both. Because for Temporal, for example, yes, you have the control plane. But the biggest issue that we hear about from people who have used Temporal is that first it's really hard to get into. That's a very steep learning curve for Temporal. You have to change your application to match exactly how Temporal works, when really all you need is retries, or you need a certain level of observability. And you need to make sure something runs, and then you just need to be able to define a sequence of tasks. 

Temporal can also just really become overkill. And then Temporal doesn't actually manage the compute for you. You have to spin up your own worker pools, and you have to design your worker pools so that, again, you kind of almost run into the same problem. How big should your worker pools be? And if you're keeping them running, are they being utilized or not? And so it's the same problem that you run into with Kubernetes, where you just have these things running all the time, but it's not clear if they're being utilized. 

There's fundamentally some of the same issues with Temporal that you see in some ways with Kubernetes. And with Render, it's different because Render is executing your tasks. And behind the scenes, Render is making sure that we only charge you for the task execution time. You don't have to worry about worker pools. You don't have to worry about running out of memory. You can define your memory at the task level, and that's what you get. 

And over time, the other thing we want to do is also allow you to scale up in memory dynamically. So you don't have to predefine it. So let's say you're processing a really large document for a task that typically takes 6 gigs of RAM. You might want it to spike up to 12 gigs of RAM, and Render will do that for you for that task and only charge you for that task consuming 12 gigs of RAM. It's much more flexible. It's a lot more accessible as well because you define your tasks in code simply by adding a decorator or a pure wrapper over your existing function. So in that way, it's actually as simple as something like Celery or BullMQ management, but you don't have to manage queues, obviously. 

We've tried to build something that is incredibly accessible but still gives you what you want out of durable execution, which is this notion of maintaining state across a sequence of tasks that could execute for days or weeks. And then also letting you make sure that it is actually durable, that you can retry these things, you can define concurrency. You can define the inputs and outputs in a way that are all typed. I think it's going to be really interesting to see how people prefer. And we already have people moving to us from Temporal. And I think it's going to be really interesting to see when we launch workflows in GA in a couple of weeks. By the time this comes out, maybe it's already in GA. What people use Temporal for versus Render workflows? 

[0:33:57] SF: Right. And then do you think as you support this and even the hyperscalers are supporting some version of durable execution, at least like a lightweight version, is this something that becomes kind of like the default experience for developers building any of these types of applications, where regardless of where they're building, there's some form of durable execution available for them out of the box? 

[0:34:20] AG: Yeah. In many ways, it becomes like Postgres database. So you just have to have a primitive in whatever cloud you're using to do this kind of work. Because it is becoming so common now and it's a completely new pattern of how people are building applications, which is why we invested in it so early. And we think that it's really important to offer it as a platform primitive as opposed to you trying to glue together open source things to run them on Render. 

[0:34:49] SF: Mm-hmm. And then was this from a ground-up project? Not forked from anything? 

[0:34:54] AG: No. No. Everything was written in-house. We haven't used anything else. We're not even using, like a Temporal or anything underneath. Everything is built end-to-end using our stack. 

[0:35:04] SF: What are you using for state management, if you can share? 

[0:35:07] AG: In some cases, we're using Postgres. And I think so far, Postgres has actually been relatively good for what we need. We haven't had to use a more complex state management primitive yet. 

[0:35:26] SF: Mm-hmm. Okay. 

[0:35:27] AG: And then, yeah, there are places where we use Redis as well. But really, I think Postgres is the bulk of it. 

[0:35:32] SF: Mm-hmm. We touched on this earlier, but the idea of as agents start to use infrastructure, you need guardrails, you need these like cost controls. And you mentioned undo mechanisms as part of this as well. What are some of the new things in terms of being able to undo stuff? And how does that work in like a safe way so that agents can actually start to manage infrastructure in a way that you could trust? 

[0:35:57] AG: Yeah, that's an interesting one. Because let's say that an agent wants to delete a database. If the database isn't around, no one's using it, you could show the agent that the database has been deleted, but then you keep the database around for 30 minutes or maybe 24 hours, so that if someone decides that the agent makes a mistake, then the agent can recover and issue a recover command on the database. Just keep things around longer. That's the simplest example I can think of for undo. 

There are other patterns. Okay, well, what if the agent decides to delete your web service? And this web service has a custom domain on it. And suddenly, your traffic is gone. I think even there, you can make recovery a lot easier by having this notion of application infrastructure state that you can replay back really quickly. That's where infrastructure as code becomes really useful. And so Render's infrastructure as code format lets you define all your services in just a few lines of code, and the agent will then be able to simply add the service back. In some ways, it's very similar to making a code change that leads to a bug and reverting the code change. 

[0:37:11] SF: Right? Do you have to also think about - obviously, this is something that you'd probably want to do anyway, but does it become even more something you have to think about is the speed with which you can stand up pieces of infrastructure and tear it down when you might have agents that are trying something, deploying it, realizing it's not the right deployment model, tearing it down, and then redeploying and doing that sort of continuously almost in a loop. 

[0:37:36] AG: Yeah, absolutely. I think the reason we've invested so much over the last year in making builds and deploys much faster is partly this, because these things need to be able to come up much faster when agents are trying them. And it's good for humans too. But agents are just operating at a very different speed, right? And so the faster you can make actions in your system, the more agents are going to prefer it. 

This is also why I think even with agents and maybe agents writing Terraform, agents will always prefer higher-level systems like Render to spin up a web service or spin up a workflow. Because trying to do that on AWS will take much longer because you have to wire up a bunch of things together. And each thing takes a while to come up. And you might even need to spin up a whole Kubernetes cluster to do what you're trying to do on Render, especially if you're doing some kind of like private networking. And so I'm not worried about agents when people say, "Oh, agents are just going to make AWS easier to use." Well, guess what, I think agents are going to prefer the most token-efficient way to get to a certain outcome. They're outcome-driven. 

And if Render can serve that outcome in a way that is much faster, it's a single call, it's much more deterministic for the agent because it doesn't have to configure 5,000 variables, then that's what they're going to prefer over something that operates at a really low level, at the level of a VM, where the agent might need to decide what kind of VM it needs to spin up. And then what kind of plan on the VM? And then what kind of - there's a lot of stuff that the agent would have to do on AWS. 

[0:39:10] SF: And maybe more back and forth with asking the - 

[0:39:13] AG: Much more back and forth with the user, many more chances of error, because there's so many more steps. And so the more steps it has to go through, the more likely it is to make an error in any one of those steps. 

[0:39:25] SF: Yeah, I think that's definitely true. And especially, I think that this might not be the case for every company right now, but you mentioned the token cost. I do think the kind of free lunch era of tokens is going to be coming to an end relatively soon. 

[0:39:39] AG: Oh, it has already. Yes. 

[0:39:40] SF: Yeah. Yeah. You see this in the news now: companies are blowing through their yearly budget of tokens in like a month and then not necessarily being able to map that to the ROI of what value they're getting out of it. I think companies are going to be looking for ways of how do we optimize our token costs. And the things that are greedily chewing up tokens. People are going to be looking for alternative ways to solve those problems. 

[0:40:03] AG: Yeah, I think token economy combined with correctness makes the case for much higher level interfaces, which is why I think Render is seeing the growth that it is. 

[0:40:14] SF: Mm-hmm. Yeah. If you're right about a lot of this, and the next version of the cloud doesn't necessarily look like AWS, agents really change our interface to infrastructure, what do you think things look like if we fast forward 3 or 5 years, which is a long time in our industry? But what is your sort of vision of where we're going with all this? 

[0:40:34] AG: It all starts from the applications that people are building. And these days, a lot of applications are AI native, and they're agents. And agents require a lot of different primitives. I think a lot of code being run in the cloud is already untrusted. I think more code - 3 to 5 years, there'll be more code running in the cloud that has been generated on the fly without any human input, which means that it'll need to run in sandboxes or isolated environments all the time. And you will require much more governance across the board. 

And I think that in our current cloud, because of humans trusting other humans to kind of do the right things, we just don't have governance across the board. And the kind of abuse mechanisms that exist today, this is changing, but they're still limited by human actions. But that's going to change as well. And so, it's just going to become everything is just going to operate at a much faster rate. And it's going to become much more dynamic. 

And what that means is that the infrastructure underlying all of this has to become more dynamic. As a result, it has to become more maneuverable by agents, obviously. And it has to also become more resilient against abuse and security issues. Because again, we're seeing that today a new kernel exploit is coming out every week. And you really can't protect yourselves against AI-driven exploits unless you have AI-driven protections yourself. That's kind of where we are. And that's going to become a much bigger deal. 

I mean, we already see all the supply chain attacks, but what we're not seeing is the next level of dynamic network-level attacks or some kind of other attack that hasn't even been invented yet that attacks a different part of the infrastructure stack. The cloud is going to become more scary, but there will be good actors as well. And a lot of the code that's being executed in the cloud is going to be generated on the fly. And people are not going to understand it all the way they understand it today. And I just hope that it all still works somehow. 

[0:42:55] SF: Yeah. Yeah. Absolutely. Well, Anurag, this has been fantastic. Anything else you'd like to share? 

[0:43:01] AG: Well, I can talk a little bit about Render. We're seeing just the most growth we've ever seen in our history in terms of revenue. As of June, we have more than 400,000 developers signing up every week. We have nearly 10 million live services on the platform. And we're able to help so many more people and organizations move faster and bring their applications and grow their applications and make them really capable in the cloud. And I hope that if you've never tried Render, that you will. It's just render.com. And we're looking forward to helping the cloud evolve in this new era that I just talked about. 

[0:43:38] SF: Yeah, fantastic. Actually, one question follow-up of that. With all this growth in the signups and obviously more people building applications, are you also seeing a persona change in terms of the types of people that are building applications? Is this truly democratizing access to anybody with an idea essentially being able to actually build something, at least PSE or experiment with it? 

[0:44:00] AG: Yeah, there's definitely a huge movement of people who are not quite the consumer vibe coder, the people who are technical and who can kind of understand pseudo code, which means they can kind of understand what's happening with Claude. But then we're also seeing people using Claude and Codex to teach themselves coding because it's now become a lot easier. You can just ask Claude, "Hey, you did this. Explain this to me." And I think Codex also has, or maybe Claude 2, they have like a learning mode in them, where instead of just coding it, it'll actually teach you along the way. 

In many ways, I think the definition of a software developer is expanding. And I'm not talking about people who just want to vibe code on places like Lovable or Bace44. I'm talking about people who want to build apps for their business, or internal apps for their business use case, or even external apps. Product managers are the perfect example, where they're technical. They've had maybe a computer science degree, but they haven't been coding professionally. Well, now they can, and they are. And they're building applications that would be impossible for them to build earlier. The whole industry and the nature and the number of applications is expanding really, really rapidly. And I think Render is actually kind of fortunate because we're in the right place at the right time to take advantage of this wave of people who just want an easy place and a fast way to deploy these applications and bring them to the people who want to use them. Because none of these people are actually going to use AWS to deploy their applications. That's not what they're looking for. So many new developers are really being trained on a new kind of cloud as opposed to AWS back in the day. 

[0:45:39] SF: Yeah. I mean, I think that's exactly right. Even within the organization I work for, well, one I'm generating more code than I have in a very long time. And then I think that's across the board with all the PMs that I work with. But also, I think that we're kind of creating a world where a lot of software is ephemeral because it's easy to spin up stuff. 

I created like a dashboard the other day to measure engagement with a particular product that I could have had someone within the company build in Tableau or something like that at some point, but I can just spin that up easily using something like Claude Code, run it on Render, and have that thing ready to go for two days. And then when I'm done with it, I can throw it away. And it's not this heavy investment that I spent time on. 

[0:46:24] AG: And it's interesting we're seeing that what you just said about ephemeral applications. We're seeing that people are creating a lot of apps that live for shorter durations. And Render is obviously great for that because you only pay for when the application is live. You don't have to worry about all this other infrastructure just sitting around waiting for you to deploy another app on it. But then a lot of people are also able to create long-running applications that are helping their businesses. And it's really great, really exciting, motivating to be at the center of all of it. 

[0:46:58] SF: Mm-hmm. Yeah, absolutely. Well, again, thank you so much for being here. This was fantastic. 

[0:47:04] AG: Thank you for having me. This was a great conversation. 

[0:47:06] SF: All right. Cheers.

[END]