Ep. #53, Render and the New Cloud Stack with Anurag Goel

Benjie De Groot: Hey guys. We're back at it with Anurag, CEO and founder of Render. Very excited to talk about Render. We've been following it for years and obviously there's some really cool momentum happening now. So welcome, Anurag. How's it going?

Anurag Goel: Thank you for having me, Benjie and Marc. It's going great. It's great to be here and hang out with you guys.

Benjie: Very excited about this one. We've been following Render from afar for a very long time. But before we get into that, we'd love to just kind of hear about your background. Like, when's the first time you touched a computer? What got you into it? And then just a little bit of an early career arc and then we're going to get to the meat of Render.

Anurag: Absolutely. I think my first computer class in school was in, I believe, sixth grade. And I wasn't really spending a ton of time on programming until college. And I really got into building things for fun when I got really bored of my day job.

And my day job was all about building Enterprise JavaBeans. And that was not fun for anyone who is old enough to understand that. And I wanted to use software for more than that. And I taught myself other languages that were more fun to program in and just started building things on the side because I had time from my day job.

Benjie: What was your day job?

Anurag: My day job was I was a software engineer at a public company that is still around, but I was mostly getting my green card there.

Benjie: Okay.

Anurag: I grew up in New Delhi in India, and I came here right after college to work at a startup that hired me from campus. But then that startup was acquired by this large company. And this large company was all about Enterprise JavaBeans, or somewhat boring software.

Marc Campbell: And you were like, "ooh, this is going to be great." Haha.

Anurag: Well, I did have to get my green card and the United States does make you work for it, especially if you're from India and you don't have a master's degree. So that's what I did for a lot of my twenties.

But then there came a point when I was building this stuff and I needed payments for one of these projects. And no one would give me payments for a side project in 2010 except PayPal. And I didn't really want to use just a PayPal button on my site.

I wanted to look professional, even though it was a side project. And I heard about this company that was still in private beta, and they were looking for early users. And I signed up and got my first invite to this company called /dev/payments, or Dev/Payments.

In December 2010 I signed up, accepted my first payments for my side project in January. I gave this team a lot of feedback, product feedback, because I thought that the product was lacking a few things. I also ended up becoming the first person to churn from that product to a competitor.

But I still stayed in touch with the team, and after interacting with them a few times, I think they were convinced that I was going to be a good addition to the team. They tried to hire me, I said no. But then things happened and my wife decided to go to grad school for a year. And I don't want to work from home by myself.

So I was like, I don't want to interview either, but these guys already kind of offered me a job, so I'm going to go join them. And that is how I ended up at Stripe in July of 2011.

Benjie: Okay, so that company turned into Stripe.

Anurag: Well, yeah, /dev/payments was the original name, and then it became Stripe.

Benjie: So I'm pretty sure Stripe wasn't using Java.

Anurag: No, it wasn't.

Benjie: Wait, so you started at Stripe in 2011, is that right?

Anurag: Yes. Yeah, in July 2011, I was the eighth employee there.

Benjie: Wow. Okay. So that was an exciting time there. Out of curiosity, what was the stack at Stripe then?

Anurag: It was Ruby, largely, and we kind of had our own web server. And then we were also just, in the end, we ended up using Sinatra a lot. And we were using Mongo in 2010 and we didn't like to talk about it. And I don't know if Stripe is still on Mongo. I haven't been there in a while, but at the time, I think Mongo was definitely coming up on Hacker News as a database with issues.

Benjie: There's some growth issues happening there. Hey, I just remember the first time. I think the first time I used Mongo was right around then. And I remember the database IDs had the timestamp in them, and I thought that was the coolest thing ever.

Anurag: But I will say for Mongo that it was perfect for moving quickly because you didn't really need to deal with what, pesky Postgres schemas. Who does schemas? Well, you just like, shove anything into there and you don't need to do a whole migration just to add a new field and just do whatever you want.

Marc: It's tomorrow's problem.

Anurag: Yeah, exactly.

Benjie: And it worked. It worked like, half the time, too. It was great. Well, it worked.

Marc: Haha.

Anurag: Haha. So it worked most of the time, I'd say. I think people gave it a little more grief than it deserved because Stripe was able to scale on Mongo for a really long time despite having some issues along the way. But the Mongo team worked with us pretty closely. And so I think we just didn't want to tell the world that we were running this massive payments infrastructure on--

Benjie: Yeah, in those days, being on Mongo for a financial company is quite an interesting juggling of communication there.

Anurag: That is absolutely right.

Benjie: And I just need to be clear. I'm a huge Mongo fan. Very proud. That was New York's first unicorn. Everyone knows I'm a New York guy. And so we love you, Mongo. You've done great. You're doing great.

Anurag: Yeah, no, Mongo's great.

Benjie: But in 2010, it was a little...

Anurag: In 2010. Haha. In 2010. Yeah.

Benjie: Yeah. Okay, cool. So then, how long were you at Stripe for?

Anurag: I was there until sometime in 2016. So I was there for almost five years. And I held a bunch of different roles. I joined as an engineer. I became, somehow, because no one else wanted to do it, Stripe's first growth person. And then I moved back to engineering and also ended up building out the financial risk engineering and operations team.

And so towards the end of my tenure there, that's what I was doing. And as the head of Risk, Financial Risk, doing a bunch of fraud, abuse mitigation, making sure that Stripe lost just the right amount of money. Because you lose too much, then your margins are pretty low to start with. At least back then they were. And you lose too little, then you're probably being over aggressive with your fraud assessments and you're losing business.

So there was a lot of just tweaking and human review and building tools that help people without LLMs decide how to score accounts. And it was a good time, and we hired some great people, and I learned a lot. But in 2016, I felt that it was time for me to move on and do something different and solve a different problem, something that I felt more personally motivated by than how I felt about payments.

So I spent about a couple of years, almost a couple of years, just figuring that out. I was at the South Park Commons at the very beginning and hanging out with a lot of other people who were also trying to do the same thing, just figuring out what they wanted to do with their lives next.

And it was early on, it was just a great group of people who've all gone on to do amazing things. And it was a great way for me to try a lot of stuff and get feedback and really take the time to understand what I would be excited by, for, ideally the rest of my career. And that's really what I was looking for.

Because when you're the fifth engineer at Stripe, you are not worrying about money after a certain point. And so what you're really thinking about is, okay, I have all this life, ideally left ahead of me and work and career. Like, what do I do? Do I just retire? That would basically make me just die early. Do I solve a problem that I'm excited about?

And so I wanted to solve a big, hairy problem that I could also be excited about for decades. And through a lot of trial and error, that led me to starting Render, where I brought my affinity for infrastructure and my desire for developer productivity together. And that's how Render started in 2018.

Benjie: Okay, so you're at South Park Commons for two years. I do have to correct you. You were worrying about money every day of your life when you were at Stripe, for the record.

Marc: Haha!

Benjie: So I'm just saying. Obviously, that was like, your whole thing.

Anurag: Other people's money. Other people's money. Yes.

Benjie: No, of course. Okay. So you start Render, and I would imagine that being at South Park Commons, you're around a bunch of builders and they all have this common problem it turns out of, how do we get this really cool thing that works on my laptop into the world?

Anurag: Yeah.

Benjie: So what was the first version of Render? What was the very first version of Render?

Anurag: So interestingly, the very first version of Render that is still in our repo was actually a functions as a service product where you could code in the browser and you would get an HTTP endpoint and changes would get reflected instantly. And I guess one way to think about it is maybe there's a company called Runbook, which was acquired by Stripe. And I think Replit was kind of this for a while before they pivoted to vibe coding.

So I was doing that for Python and a lot of people, a lot of my friends found it interesting and cool and they tried to build some stuff with it. Some of those things were helpful, but I quickly realized that I wasn't actually solving real production problems.

And so within a few months, actually towards the end of 2017, I decided that I would just go take on the whole problem of, all right, well, let's just go build the thing that you can deploy to no matter what you're building. And yeah, AWS existed, was doing well. Kubernetes was around.

A lot of people thought it was kind of insane to be launching a new platform in 2018. But I also knew that I had the luxury of time, to be completely honest, to build this into something that could one day take on these larger players. And here we are eight years later, and we've got more than 6 million developers on the platform and we're making a lot of money, much more than we made in the first five years. And I think that the eventual bet is starting to show results.

Benjie: I mean, yeah, sticking to that and like you said, having the space to explore and get it done right and take on the big problems is really cool. Okay, so 2018. You were doing this solo for a while, I would imagine. And then did you end up raising money? Did you end up hiring out a team? How'd that work out?

Anurag: Yeah, so I ended up hiring three people over the course of that year. I raised some money from General Catalyst and a few other angels and Addition, which is a New York firm, they actually ended up investing in our, leading our series A.

Benjie: Okay, so tell us about, 2019, how, as a developer, do I use Render. Like, I mean I know it's evolved, but like, is it Docker? Is it API? How do I interface with Render?

Anurag: Yeah, in 2019 you sign up and connect your Git repo and we kind of just take it from there. So we don't require you to use Docker, although we support Docker and we've built our own managed Postgres by then and we haven't yet built in 2019 our managed Redis solution.

But especially for this audience, it's important to note that a lot of our substrate was Kubernetes under the hood and in a lot of ways we were making the power of Kubernetes, the stability, the scalability of Kubernetes , accessible to the average developer without them having to know anything about it.

And that I think was a big differentiator for us especially as maybe some newer players came on and it helped us stay much more reliable and scalable as we continued to grow compared to our smaller competitors.

Benjie: So are you guys running GKE and AKS and EKS under the hood or you run your own manage?

Anurag: We run our own full management, our own control planes.

Benjie: At the time and back then as well.

Anurag: Yeah. So actually what happened was in 2019 I started off with GKE because we just wanted to move faster, but then we quickly realized that the kind of control that we needed was not going to be possible by using an off the shelf managed control plane. We also had, happy to say this on a podcast, but we also had issues with Google's support and sales teams. And I'm sure I'm not the only one with that kind of experience.

Benjie: Well, also 2019, that's when they went from the control planes were free to they cost money because I don't know if you guys remember that like yeah, yeah, AWS EKS cost like a hundred dollars for the control plane.

Anurag: Yeah, something like that.

Marc: It was, it was relatively inexpensive but--

Benjie: Well, but if you're doing a bunch of fleets, that was not helpful for Shipyard at the time. Maybe that was 2020, but I hated when they changed that pricing.

Anurag: I think it was later. Yeah, but I like that was for us that was not a huge issue. The bigger issue was when a CVE was announced not being able to patch it fast enough because Google would kind of take their own sweet time. And there were just other issues with the managed control plane. So this one time--

Well actually 2019, the day we were demoing on stage at TechCrunch Disrupt, our control plane just started crashing. And I'm like, what's going on? We had no visibility into it. Got on call with Google support multiple times. They kept restarting the control plane and saying it would be fine.

And I was on a call with some Google support person in Canada who was like, "I guarantee it that you're not going to run into this issue again." And I'm like, I can tell you, I was thinking, I didn't say this to him, but I was thinking to myself, well, I think when someone says this in infrastructure, I can guarantee that we will definitely run into this issue.

Benjie: Yeah, it's the opposite. Haha.

Anurag: Yeah, it's the opposite.

Benjie: It's like for infrastructure people, it's like if they guarantee it's going to be fine, then it's going to be a disaster. Same thing with engineers. "Oh, it's going to take me a week."Okay, it's at least like two months. It's the same thing.

Anurag: It's the same. Yeah. So then they again restarted it and sure enough, we crashed in the middle of TechCrunch Disrupt and there were a bunch of people trying to sign up and spin up apps and it just didn't work. And we later found out that there was a bug in GKE that was spewing a ton of logs onto the control plane nodes and the nodes were running out of space.

And so the restart just fixed that problem temporarily until the next time the logs built up and then eventually fixed the bug. But it cost us a lot of signups during TechCrunch Disrupt when we were the winners. So anyway, that and other things led us to conclude that GKE was not a long term thing for us and we really wanted to control things end to end.

And so we switched to AWS for all new clusters going forward and we built our own from the ground up. And that's what we still do. And we just started using bare metal. And even there we're sort of doing our own thing and we'll see how that whole thing goes. But so far, so good.

Marc: Bare metal that you own in rack and stack and servers? Or bare metal you're getting from some--

Anurag: No, we bought the servers.

Benjie: Wait, before, by the way, we're going to get there. Believe me.

Marc: Yeah, we're going to go into that.

Benjie: Okay, okay, calm down, Marc. We're going to get there.

Anurag: I mean, I know, Replicated, of course.

Benjie: Yeah, no, we love, we love, we love talking about bare metal these days. Okay, so to understand this, to make sure I understand. So you guys have your own control plane that you guys have been running since 2020?

Anurag: Yeah, yeah.

Benjie: And so what about isolation? If I have an app and Marc has an app, is it containers or are we in the same name space? Like at that level, how does isolation work, at least back then. Maybe today is a little different.

Anurag: Yeah, I think we've always held this view of, you know, isolation is not one thing, it's multiple layers and those layers are things like Seccomp those layers are different namespaces. They're obviously removing Linux capabilities. They're also now these days there's user namespacing, which is really interesting. There's the ability to run as root in a container or not. There's the ability to use host path or not.

There's you know, all of those things that you want to do to run multi tenant applications in that setup without worrying about container escapes and then continuing to be really vigilant and making sure that every layer that you have allows you to run a secure installation. And so that continues. That work continues.

And now we're experimenting with micro VMs as well as we think about sandboxes. So it's a constantly evolving thing and it's really interesting to see how the space has evolved and it's also interesting to see how Kubernetes is trying to account for some of the changes that are happening in the ecosystem.

So they now have a sandbox CRD which is interesting and there's a sandbox working group. It's not quite there yet, but it's coming. We're building our own because we can't wait. But I'm curious to see what happens there.

Benjie: Yeah, I'm pretty sure GCP last month launched a sandbox product using the Kubernetes SIG for the agent sandbox thing. So it's crazy times, but I'm curious about this. Are you running just one massive cluster for everybody with different nodes or are there multiple clusters? Multiple fleets of clusters?

Anurag: Yeah, there's multiple clusters, multiple regions, there's lots of clusters. But each cluster also has a lot of namespaces and there's like dedicated nodes for certain customers, there's mixed nodes for other kinds of customers. And so there's sort of segmentation based on what people want.

Benjie: Right. And so early on people go into Render and it just works. You connect it to your Git and it works. And then obviously that's evolved where you have some enterprise customers now, but so you guys were like a legit PLG, bottoms up.

Anurag: We still are. We have grown to, you know--

These days we're adding over 400,000 developers a month just through word of mouth.

Benjie: Wait, did you say 400,000 a month?

Anurag: Over 400,000. Yes.

Marc: That's crazy.

Benjie: Well, how do you have time to be on this podcast? Get back to work. What are you doing? Haha.

Anurag: Well, this is my job. I need to go tell people that we're adding 400,000 developers a month so they feel good about using us.

Benjie: Okay, so that's pretty cool. So you said that the team, the initial team, was like four people, including you. Let's talk about some milestones. You raised a B, you raised a C. How far have you guys gotten at this point?

Anurag: Yeah, so we raised a C at the beginning of 2025, and then the company did really well over the subsequent months, much better than anyone expected. And so we actually ended up extending the C and added another 100 million to that round at a valuation of $1.5 billion. So that's where we are right now.

Benjie: Not bad. So how many employees in total, and then also how many developers you guys at this point?

Anurag: Yeah. So, you know, the numbers we share publicly are largely around, you know, the number of folks on the platform, which is 6 million and growing by 400,000 plus every month. And in terms of employees, we're hoping to get to about 200-ish people by the end of this year.

Benjie: Okay, so things are taking off. Okay. I think the obvious thing is that AI stuff might have been helpful for Render.

Anurag: Of course.

Benjie: So say we're in 2024 and there's a bunch of developers using this platform. People use this for production, obviously, and it's going well. What does the early days of, you know, Replit, Lovable, vibe coding, the early days being like a year ago or whatever, a year and a half ago. How does that start affecting you guys? What changes are you guys making to the platform?

Anurag: So we're aware of all these vibe coding platforms growing really quickly, growing revenue really quickly, and it brings up a reasonable strategic question: Should Render be getting into vibe coding? And we at the time, and still, believe that--

The right thing for us to do is to stay true to our original mission, which is to build for application developers. And while the number of application developers is growing and the definition of an application developer is changing, our platform is still built for people who fundamentally understand lines of code.

They can go in and debug things when something goes wrong. We're not today building for people who just type English and assume that the platform will take care of things for them. So we still expect you to understand Git. We expect you to be able to set up webhooks. It's actually built for like real production software teams of application developers as opposed to the individual vibe coder.

And while that means that our revenue might not have grown by $500 million over the last year, we're again building very much for the long term. And now we're really focused also on agents spinning up infrastructure. And agents increasingly being in the flow of not just deciding where to spin up infrastructure, but then managing that infrastructure as well. And I think in the long term, focusing on agents is a much, much, much bigger market than focusing on vibe coders.

And when we build these interfaces and capabilities for agents, we make Render much more attractive to agents than say, AWS and like to do the same thing on Render vs. AWS, you end up spending many more tokens. You end up with lots and lots of potential issues when you try to configure the same thing on AWS.

Whereas on Render it's just like one call. And so naturally agents are going to prefer a higher level, more deterministic interface to do the same thing. And that's where we think we can genuinely take market share away from AWS. Although AWS is going to be just fine and I'm not worried about them.

Marc: Yeah, that makes sense. I also think like, that, you know, true to the original mission, it makes a ton of sense. I actually think that you see these vibe coding platforms out there right now, and that's really great. It might take somebody who's a very inexperienced or not a developer and they're able to ship code than they weren't before.

But like, it's almost like a different set of tools and trying to like build one platform that works for them and also works for a team of experienced engineers, you kind of solve neither thing really well if you try to fit in one solution.

Anurag: Exactly.

Marc: That's really cool. I mean, so like, let the other folks that are actually solving that, you know, like, hey, vibe coding platform, some AI engineer who's like typing stuff in, you know, they can handle that just well.

Anurag: Yeah, but the good thing is people are building really popular vibe coding platforms on Render. So Base44, which is one of the top five vibe coding platforms in the world, runs everything on Render.

Marc: That's cool.

Anurag: And like literally every website that people build on Base 44 is hosted by Render.

Benjie: Right. So you're like the backend for Base44 and a bunch of other folks. So that's pretty cool.

Now you mentioned that you have a managed Postgres service, you have a managed Redis service. I assume that as the things have, as things have grown, you've had to add other-- Like, what other services besides those do you guys have? What other stuff can we leverage at Render?

Anurag: Yeah, so one of the most interesting things that we've launched recently is directly in response to what we were seeing as an issue with customers who were dealing with LLM calls and trying to build agents where you really needed a reliable orchestration mechanism for agents executing a series of steps, or you needed a reliable orchestration mechanism for a payments flow or for a data pipeline ETL.

And Background Workers was the way people were doing it before. But like Background Workers fall on their face when you have tasks that are likely to fail and you have to retry them multiple times. And you also have tasks that are very different in terms of their compute requirements. And then there's dependencies between tasks. You just have to build a whole thing on top of Background Workers.

So we saw a lot of our users trying to do that and we were like, okay, well I think the answer to this is to build our own workflows product. And so that is a primitive that we've launched and it's still in early access. It's open early access and it's going to be in GA very soon. But it is doing incredibly well based on early usage because a lot of people who were just struggling with trying to make these things work with Background Workers find workflows just so much easier.

They're able to eliminate tons of code and it's the first time they're including Render code in their own code. Which is really interesting because workflows has an SDK is and you can spin up tasks using the SDK. You can define tasks really easily, almost like with a Celery like definition. So I'm really excited about this new primitive.

Benjie: It's kind of like a Temporal, like a hosted Temporal kind of thing?

Anurag: Yeah, that's one way to describe it. It's solving a lot of the problems that someone might reach for Temporal for. But the problem with Temporal that our customers face is the learning curve is incredibly steep. And then you have to change your application significantly to mold it to the Temporal way of working. And then you still have to manage the workers yourself.

And with Render, really all you need to do, it's basically the same philosophy for everything that we do, which is like you focus on the things that are domain specific to you, so you define the task and each task can get just a little decorator which can say how many times you want to retry it, what kind of compute that task needs. And if it has subtasks, they can go just in the function and you can sort of just chain them and that's all you need to do.

And Render takes care of the entire pipeline for you. It also more importantly shows you exactly what's happening with each parent task and subtask and the inputs and outputs. And we're making those things durable in the sense of you can repeat tasks with the same inputs and outputs if they fail, and so on.

So it's a really interesting product. I think that it's how most asynchronous compute is going to run in the future. People are going to really stop using Background Workers. They were great when all they needed to do was send email and process payments, but now you have to do a lot more. And I think you need a different primitive.

So we've seen a few people move to us from Temporal of course, but certainly other providers like Trigger or there's other durable execution players, but we're actually just calling it Workflows because that's how people think about it.

Benjie: Right, okay, so, but the theme here is managed, simple, "it just works" services that your customers need. That's kind of the theme of what you guys are building over at Render.

Anurag: Yeah, the theme is, well, what do application teams need both when they get started and when they truly scale? And we want to be with you throughout your journey. Base44 started on Render with just the founder spinning things up by himself. And then he got acquired by Wix for 80 million and now he has a large team.

The team is still smaller than what it would be if they were not on Render. And this product has, I think they just announced that they crossed $125 million in ARR. And it's massive. So many people using it. And I love that Renders supporting their scale and their ability to scale.

Benjie: Yeah, being a pick and shovel for those guys has got to be exciting for you right now.

Anurag: Yeah, it's not just them. I mean Cognition is using us for a bunch of things. OpenAI is actually using us for a bunch of things which is really interesting. So we're just seeing more and more usage by not just early stage startups, but also larger companies and teams within larger companies. Because what's happening, and this is the biggest change that has happened over the last two years, is because many more applications are being generated, the old way of managing an internal platform team is breaking down.

Platform teams were built to maybe support one or two new applications a quarter, and now there's one or two new applications every day. And how are you going to support that? How is this one team going to handle all of that?

And so we're seeing these larger companies come to us and say, actually Render is the best place we've found for us to manage all of these applications being built by our teams. And our IT team doesn't want to be completely clueless about what's going on, so Render gives them the tools that they need to sort of see what's happening and create the right controls. So that's a really interesting vector of growth that we're seeing just now, which obviously did not exist even a year ago.

Benjie: Okay, so first off, that's super cool. Second off, I'd imagine scaling is interesting for you guys.

Anurag: Oh, scaling is really interesting. That's what makes the whole thing really interesting.

Benjie: All right, so let's dig into what it looks like today, whatever is appropriate to share. So you're running a whole bunch of Kubernetes. You're still doing Kubernetes, you have your own control plane?

Anurag: Mhm.

Marc: On bare metal now though, that you're racking and stacking servers.

Anurag: In addition to also running on hyperscalers. Yes.

Marc: Are you kind of just like arbitrarily splitting that workload between the two of them or are there specific types of workload that runs on bare metal versus hyperscalers?

Anurag: So right now we're in the very early stages and so we want to test bare metal at scale. And the way we're doing that is we have a massive free tier. And no offense to the free tier people, but they give us a great testing ground for something like bare metal.

And we want to make sure that we are as reliable and scalable as our reputation is right now, even on bare metal. Because we've seen other companies falter when, if and when they move to bare metal. And so we really want to move the free tier to bare metal first and learn and make sure that we understand where the bottlenecks might be, how we can continue to make the system really, really, really reliable, including stateful systems like including running Postgres on bare metal.

And once we get there, then we'll start thinking more about bringing paid workloads onto bare metal. And so the long term goal is very much to use bare metal for most of our work and then use the clouds for spikes.

Benjie: So today you guys are mostly on the hyperscalers.

Anurag: Yes, and we actually started moving customer workloads to bare metal two weeks ago.

Benjie: Oh, so that was middle of May, you started, you started moving. So we'll see, we'll get back together in six months and I'm curious to see how that's going.

Anurag: I know, yes.

Benjie: So with the existing Kubernetes stuff though, do you have any numbers of like pods that you guys are running or something insane? Do you have any crazy number you can share with us? We'd love to hear that stuff.

Anurag: I can tell you that we have contributed to Calico because we found bugs in Calico at our scale. And the Calico team has told us that we're basically the largest installation of our kind. And I would have to assume that that's true if you look at all the clusters and all the services and all the pods.

And that actually creates a really interesting set of challenges which our team is really well equipped to solve. And I'm really proud of them because as you grow, you realize that your systems need constant investment to keep up with the scale. It's not like you built it once and then it'll just scale.

And you find new ways, new edge cases, ways in which things break, obviously. but you have to try to get ahead of them so you don't actually have incidents that affect real production customers. So that's a constant sort of investment that we're making to stay ahead of our scale so we can remain as reliable as our customers need us to be.

Benjie: Is there like a CDN component that you guys are, just like a managed CDN that you guys have as well?

Anurag: Yeah. So we offer static sites on a CDN, so very much like Netify and Vercel, you can run a static site on Render for free. And we also offer an interesting product where your backend can be fronted by a CDN.

So by default you can actually serve your statics from the backend and Render will automatically put them on a CDN and cache them and bust the cache. And that product has actually become really popular.

Benjie: So you guys are like a full cloud at this point. You can consider yourself a neocloud or you guys don't do Any GPU stuff yet, so--

Anurag: Not yet, no.

Benjie: That's another whole thing.

Anurag: I know. So I think these days all the GPU clouds are being called neoclouds. I don't know what we call ourselves in terms of, are we a neocloud or not? But really we call ourselves an application cloud. Right?

And so if you're an application developer, it doesn't matter what you're building. Maybe you're building traditional web apps, or maybe you're building agents and AI native applications. We want to help you bring them online quickly, maintain them, scale them confidently and securely. And it doesn't matter what you're building and how you're building it.

Benjie: What about the observability stack? Because you talked about how you give access to folks that need to monitor what's going on. You're running big production sites for folks. Do you integrate with Datadog? Do you have your own kind of version of it? What does your observability stack look like?

Anurag: Yeah, both. So we have our own dashboards for people, but, I mean, you can run your own Prometheus and Grafana instances on Render, and some people do, but then we also allow hotel stream exports to whatever provider you're using. And that includes Datadog, it includes Honeycomb, it includes others. And so a lot of people end up using those as a way to get complete observability into all their systems.

Benjie: I'm curious about egress, because you guys are using the hyperscalers, so that's gotta get expensive.

Marc: Yeah, everybody's thinking about egress costs these days.

Benjie: All I think about is egress. I go to bed, I think about egress, I wake up, I think about egress. Any insights on how you handle that? Or it's just baked into pricing, or how does that work?

Anurag: I mean, it is baked into the pricing. The one thing I will say is because of our security posture, we made sure from the beginning that none of our machines that are running user workloads have public IP addresses. So they all had to go behind a NAT. And we started out using AWS managed NAT. And you can probably see where this is going.

And I think AWS's managed NAT product is, and I'm not the first person to say this, but it is one of the biggest scams perpetrated by the pricing team at AWS. You're charged for both incoming bandwidth and outgoing bandwidth, and you're charged for egress, and you're charged for hours for how long the NAT has been running.

And so it just so happens that our massive, massive AWS bill, about a third of that is networking. And we reached a scale where it just didn't make sense to pay AWS that kind of money for NAT. And so we actually built our own NAT on AWS. At our scale, that becomes really interesting.

We've launched it, it's been running in production for a while and we've let it bake and I think it's going to increase our gross margins by like, I don't know, 10 percentage points or something, which is just--

Marc: But you're still paying, even on that though, like AWS charges something still exorbitant.

Anurag: We're paying AWS egress.

Marc: Yeah.

Anurag: And we're paying for instance costs for running our own NAT machines, but we're not paying the exorbitant NAT bandwidth cost, which was just insane.

Marc: And that's probably one of the advantages you also get on bare metal is, you know, you're racking and stacking servers and you have bandwidth you're not paying per terabyte, you're egressing.

Anurag: Yeah, the egress on bare metal is fixed. Yeah. I mean all of that just like a third of our costs on AWS become basically non existent on bare metal because of the networking.

Benjie: But to be fair, you guys have scaled so much so quickly because you don't have to worry about capacity planning of hardware and now there's supply chain.

Anurag: Yeah.

Benjie: So I will, just in case Jeff is listening. We're trying to call it balls and strikes. Haha.

Anurag: No, look, look, Render would not exist.

Let me be very clear. Render would not exist without hyperscalers like AWS and GCP giving us the access to the kind of compute we've needed. Right? And a lot of companies, a lot of startups would not exist. But we're now at a scale where we've grown up and we can move out of the house, so to speak. And that's what we're doing.

Benjie: Yeah, absolutely. So we've had some folks on that orchestrate a lot of EC2 nodes or VMs, a lot of any, any fun stories about running into like edge cases at massive scale on AWS or GCP or Azure, Oracle and any funny stuff where you're like, well, "this one time I clicked this one button and all of the US power grid went out," or something.

Anurag: I think we're definitely at the scale where we find bugs in AWS and Cloudflare and GCP that just no one else has run into before. And that's not fun, but it's just part of it. I will say that AWS has been better than GCP at fixing those issues and building a relationship with us in a way that is actually cooperative versus sort of somewhat semi adversarial on the GCP side.

And so I like AWS, and if their pricing was more reasonable for what we're trying to do, I think we stay on AWS. but it's not. And so there we are. And there's also, I mean, bare metal, by the way, bare metal isn't just about cost for us. In fact, it is more about control than it is about cost.

And when you think about things like sandboxes, which we're launching soon, when you think about micro VMs, when you think about a lot of the other stuff that's coming down the pipeline, bare metal is the only way for us to get that kind of control. And yes, AWS has bare metal machines, but you only get them in the most expensive sizes and they're also limited.

So we realized that we actually are able to do more for our customers by managing bare metal and managing eventually things like Ceph on bare metal ourselves. So we can offer new kinds of storage products, we can offer instant database forking. And we've actually built those prototypes internally. And I think EBS leaves a lot to be desired in those cases.

Benjie: Yeah, absolutely. So, okay, you're basically building out these primitives and they're just kind of like opinionated and what people need. It's very interesting because you know, a lot of people might not-- Like you didn't build your own Dynamo, right? You're just like, hey, we're going to do a host of Postgres. You didn't build your own key value store. You use Redis Temporal, that's another one.

And you're talking about Blobstore and you're talking about micro VMs and sandboxes. So it feels like you guys are trying to build the primitives for the next generation, I guess for agents or AI, whatever you want to call it.

Marc: Certainly. Yeah.

Benjie: That's pretty smart. on your micro VM stuff, are you guys using Firecracker? Are you guys trying to do gVisor stuff? Kata containers? What are you guys looking at as you evaluate this?

Anurag: We're looking at all of them right now. We're actually right in the middle of deciding the direction we want to go in, and it's quite possible that we'll offer different kinds of isolation levels with different properties. Because it's not like Firecracker is always better than Kata or gVisor. I think it does depend on the workload a little bit.

And so if you wanted to mount GPUs onto micro VMs, well, Firecracker is probably not ready for that, but Cloud Hypervisor might be. So I think it's sort of thinking about the use cases thinking about which ones we want to go out to market first with. And, and how do we phase these investments, how do we stage them? That's sort of the decision making process that's happening on our infrastructure team right now.

Benjie: So I have to ask, I'm going to ask the Replicated question. Do you have an on-prem offering? Out of curiosity, is there for some of these larger enterprises, obviously, I would think they want your appliance, but maybe they need them on their clouds or something like that. Or is that not? Which totally makes sense if it's not. I was just curious if you have something like that.

Anurag: People have asked for it. Not enough people yet. I think we'd rather develop confidence in running our own workloads on-Prem under our control before we start offering it as an in your cloud thing. I mean, it's not even a bare metal thing. We could offer a thing where Render runs in your VPC.

Benjie: Oh yeah, I meant I'm moving away from bare metal. I just meant--

Anurag: Staying on-prem? Okay, got it, got it, got it.

Benjie: Yeah. I just meant can I have the control plane running in my JP Morgan AWS account or whatever?

Anurag: Yeah. So we've chosen again, it's a question of focus and it's a question of who our customers are. And I think that yes, there's a large market of companies that would want Render to run in their VPC, but there is an increasingly large number of customers who don't care about where their workloads run.

And I think there's almost a generational divide. So we're kind of seeing that newer developers are saying, well, why would I use AWS when I can do all of this on Render? And then there's the sort of, you know. The three of us are kind of from the boomer cloud generation where we are comfortable with AWS.

Benjie: I think that's the first time I've ever been called a cloud boomer. I don't appreciate that. That's very mean.

Marc: Haha!

Anurag: Hey, I'm calling myself the same.

Benjie: I mean, come on, cloud boomer. Haha. "In my day, I racked and stacked my own servers."But yes The three of us are like, oh, yeah, AWS, that's kind of an answer.

Anurag: Exactly.

Benjie: I was a big Linode guy. So like, if I want to date myself, yeah, oh no.

Anurag: I ran my first side projects on Linode myself. So there's this generational shift that's happening in front of us as we see more people develop apps and the 20-year-olds are saying, why the hell would I use AWS? My agents are saying, ChatGPT says, actually you're getting started. Just do this on Render. I know how to deploy to Render. I can tell you how to deploy to Render. Really, don't worry about AWS.

And so that's how we're growing as fast as we are. And AWS is losing the battle for the hearts and minds of the younger developers because that's not who they think about. Because all the younger developers are more application developers as opposed to like systems and infrastructure geeks.

Benjie: I mean, most of the young kids are big Azure fans. Right? That's what I see.

Marc: Haha!

Benjie: Oh, okay. At least we're all elitist cloud boomers. Haha.

Marc: I think that's really right. We work pretty closely and we've hired from this program here down in Austin that like, you know, trains engineers with AI and they go through this intensive bootcamp and this intensive program and you know, you watch what they're deploying and half the projects end up deploying to Render.

And like, these folks maybe have some AWS experience. They have a variety of experience. Right? But like at the end, exactly what you said, ChatGPT, Claude, whatever it is they're using is like, let's just deploy this to Render and be done with it. And they don't care. They literally have no--

And then they get like, really like, wow, Render just works. I can get this thing deployed and like, I can push this off to the last five minutes before I have to demo it. And I don't have to worry it. No stress. I got a lot of other stuff to deal with.

So that's cool. I think there is an advantage to-- I mean, all three of us have built software and platforms that existed pre-AI and so we're kind of like baked into the model's training data to some degree, which helps.

Anurag: It does help, certainly.

Marc: Yeah. I'm curious, when you think about the newer stuff you're building, I actually do want to spend some time talking about the roadmap and what you're planning to launch, but how you actually think about building it in that you mentioned before, building it for agents and building it for a world where you can actually leverage that same pattern where you launch something. Maybe it's sandboxes, maybe it's whatever and you're like, but ChatGPT and Claude is going to quickly learn and know about it to create that adoption.

Anurag: Yeah. So it's something we think about a lot.

And I think agent experience, the ways in which agents can self serve into your platform is perhaps one of the biggest things that's going to shift companies away from putting things behind "talk to sales" buttons. Like if you're still trying to preserve features behind "talk to sales" then you're going to lose out on how agents are going to use your software.

And especially for something like Render, it's not even agents, like developers-- I don't want to talk to sales if I can just self serve my way into something. And I think sales becomes interesting when you do have a need to build a relationship.

And those are very discrete points and they're certainly very, very good reasons to have a closer relationship with your cloud provider, which is why we have sales, which is why we have account managers and technical account managers and sales engineers.

But even then the fact that an agent should be able to perform all the actions in your system that are available with guardrails, with sort of undo mechanisms with very real audit logging, with cost controls. And you know.

Humans can be blamed and agents can't. And so I think you need to build systems, especially infrastructure systems that allow people to use agents in a way that helps them achieve their goals while minimizing risk. And that's really important for a company to work on. And that's something that we are thinking about pretty deeply right now.

Benjie: I mean it's pretty insightful. The whole point of DevOps, the whole point of SRE, the whole well maybe platform was to just make it so that developers don't need the think about how to host things, how to run things. That promise is kind of never quite really materialized. Some, some exceptions obviously.

And now that we have put the gas, like agents are basically like on fire developers that are just churning 24/7 now those promises become all the more important and human in the loop for a lot of decision making for infrastructure is just kind of foolish at this point.

And so that seems like you guys have caught this the thing that I look at when I talk about Render and it's one of the things that we focus on at Shipyard too is being opinionated about this stuff. And just like, you know what, I don't need to look at the entire CNCF landscape and pick one of the 35 meshes.

Like, I shouldn't be thinking about that as an application developer. And frankly, I don't know if I should be thinking about it as a DevOps person, if those even exist. So you guys have really caught this tailwind of being on top of that stuff. So that sounds kind of amazing. What other stuff do you have on the roadmap that you want to talk about?

Anurag: Yeah.

So certainly agents need sandboxes to operate in. And I think we're one of the only companies in the world that has not launched a sandbox product.

That's probably not that much of an overstatement because there's probably like, I don't know, literally everyone has some sort of sandbox product and we want to do it right, we want to do it in a way that makes sense for our customers. But that's coming and I expect that the first version is gonna be available for people to test in just a few weeks.

The thing about sandboxes is that they're very different from your traditional web app scaling characteristics. People need them to spin up really fast. People want to be able to spin up a ton of them at the same time, and they need them to spin down and just be done and only pay for like the short amount of time they were up. So it's somewhat like serverless, but it's serverless. It's not serverless because you need all the capabilities of a VM and Lambda is not that. Right?

And so it's a really interesting problem for a variety of reasons, and it's still evolving. But then you also have to think about how people are building agents and should Render, offer a simple agent harness that people can use that uses our workflows product, that uses our sandbox product at the same time adding observability?

So that's, you know, agent observability is actually one of the biggest issues that we hear about from our customers. So how can Render help there? Because we see kind of all the calls that your agent makes. We also host your database, we host Redis. And so we're actually really well equipped to see end to end observability because we also see when the request comes in the websocket, all of that.

So our goal is to try to help developers who are building these things get more insight into what they're trying to do. And then I'm sure you all know of AI SRE products and there's a few of them. We think that instead of our users having to use Render's MCP server to debug things, which they do, a lot of people use Render's MCP server very, very actively to debug whatever's going on in their application.

I think we can take our learnings from that and build an agent that allows people to manage their infrastructure and troubleshoot things more easily. There's also things that we want to do that are pure infrastructure and not AI. So we don't yet have an S3 compatible object store.

We don't yet have-- And actually this is driven more by AI and agents. But we want to offer a shared file system, with sort of, I guess, G Drive, like permissioning. So you can have multiple agents operating off of the same set of things, but they also have their own swim lanes because especially when you're processing a bunch of documents and you have intermediate representations, just object storage might not always be enough.

And agents do quite well on shared file systems, as we know from running our own Claudes and Codexes. On a more fundamental level, we think that the ability to spin up an application that comprises multiple services is more complex on Render than it should be, even though it's pretty easy. And so we're rethinking that experience and we're rethinking how agents can spin up apps with multiple services even faster.

And this would involve changing our own or improving our own infrastructure as code format, which we have, which operates at a high level as opposed to like the Terraforms of the world and expanding it to allow agents to do more. So all of that's just stuff that we think about and there's obviously more stuff that we have that I can't talk about yet.

Benjie: Right, so that's the roadmap for June. What about July? No, I'm just kidding. Haha.

Anurag: I know. Yeah, exactly.

Benjie: So wait, and you do have a conference coming up, is that right?

Anurag: That's right, yeah. Actually, our first conference. We're not making a massive deal out of it, but we think that it's a good time to get a bunch of customers together. We have speakers from the usual suspects, OpenAI and Stripe and Anthropic and others. And it's on June 18th. And if you wanted to sign up, you can go to localhost.render.com.

The conference is called Localhost and we are also going to give everyone listening a code for registering. They can use the code Kubelist, one word, K, U, B, E, L, I, S, T. And get a discount on your ticket.

Benjie: Yes, guys, listen to the, listen to the podcast to get discounts to tickets. By the way, "Localhost," you're like the opposite of local host. What is the name? What is this name? Haha.

Anurag: But it's a local, local in-person conference and we're hosting people locally.

Benjie: I get it, but I'm like worried people are going to type in "local host" and it's going to go to like some port and they're like, why isn't this website work?

Anurag: Well, that's part of it. That's part of it. Like, we're being geeky, we're being fun.

Benjie: Okay, so That's San Francisco, June 18th.

Anurag: That's right.

Benjie: We'll put that in the show notes and we're going to get this episode as quickly as possible. We're running up on time. I have to ask you a question though. Render, I love the name. Where did it come from?

Anurag: My wife picked it. Haha. I don't have a better answer for that, but basically we were looking for domains that were available that were single word, common word, inspiring some level of trust and confidence, positive connotation and Render was one of them.

Benjie: Yeah, no, it's great. I've always thought of it as like, oh, you guys render the actual application.

Anurag: People's creations.

Benjie: Yeah, exactly, exactly. I'm sure that Adobe and 3D Studio Max are not happy that you got that domain, but it's fine.

Anurag: Hey, we paid good money for it, so.

Benjie: Yeah, I'm sure. Well, look, it was great to have you on. Learned a lot. Going to be following you guys very closely and genuinely, I'm super excited to get you back on in a year and hear about your 17 million developers a month that you're adding and how you have your space data centers or whatever it's going to be. It's crazy the speed that you guys are going, but thank you so much for coming on. It was great to learn all about Render.

Anurag: Thank you. I had a lot of fun. This was great.