localhost: Our First User Conference, And Why The Cloud Needs To Get Out Of Your Way

Render started eight years ago, and June 18 was our first user conference, localhost. A few hundred developers showed up in person, thousands more watched the livestream, and for one day we stopped shipping features long enough to talk about why we're building them in the first place.

The obvious question is why it took this long. As founder and CEO Anurag Goel put it while opening the day: Render only started building out a marketing team about a year ago, and asking a hundred engineers to help organize a user conference before that wasn't a risk he was willing to take. Building for customers has always come before sales and marketing at Render; that's core to the company's DNA. It just also means the first user conference arrived eight years in.

Before Render, Anurag was the fifth engineer at Stripe. He watched a world-class engineering org spend a growing share of its best people on infrastructure that had nothing to do with payments: provisioning VMs, patching them, load balancing, CI/CD pipelines, database replicas, private networking, metrics, alerting. None of it was the product. All of it was the cost of building the product.

People who hear that he was early on Stripe, tend to ask him why he isn't on a beach somewhere instead of building an application platform. His answer: he wanted to solve a large, ambitious problem and play his part in the evolution of technology, and infrastructure was the common thread slowing down builders everywhere. He wanted to give them superpowers.

"Application developers should not have to think about any of this," he told the room. The bet behind Render was that if you could design a cloud where the infrastructure just worked, without forcing teams into a specific framework or a specific architecture, adoption would follow. Eight years later, that bet looks great: 400,000 developers now join Render every month, nearly 10 million services run live on the platform, and collectively they handle over 200 billion requests a month.

Until a couple of years ago, infrastructure was mostly static. An application enabled a fairly deterministic set of things — create something, send a message, buy something — and you deployed it with exactly the infrastructure that it required: web services, APIs, databases, caches, workers. You configured it once, scaled it with simple primitives, and moved on. The shape of your infrastructure was a reasonable proxy for the shape of your code.

AI-native applications break that assumption. An agent answering a single user question might decide, on its own, to scrape a handful of pages or run a search across a hundred thousand records. One task finishes in milliseconds; the next takes hours. One question might call for lightweight web scraping or a headless browser; another might need 128 gigs of RAM to crunch a massive dataset. The application is no longer just consuming infrastructure; it's deciding, at runtime, what infrastructure it needs.

Push that onto a typical serverless platform and you hit its ceiling fast: execution capped at a few minutes, memory capped at a few gigabytes, application size capped at a few hundred megabytes, and an inflexible runtime underneath all of it. Try to build the same thing yourself on real servers, and you're now responsible for provisioning worker pools for every task type, queues and caches and storage to orchestrate them, state management for long-running processes, and observability so you know exactly when and how something broke. The more capable you want the agent to be, the more complex that system gets to build, run, and grow.

"When I look at this, I see the same thing that I saw in 2018," Anurag said, a new class of infrastructure toil, slowing application developers down again.

Render's answer is a model we call Application-Defined Compute: instead of defining infrastructure ahead of time and hoping your application fits inside it, the application defines what it needs, when it needs it, and Render provisions accordingly, with the right guardrails. It's an entirely new set of primitives that let AI applications run on Render as easily as web apps do: push your code, and it works seamlessly with the rest of the stack: builds, deploys, logging, observability, all of it.

Three properties have to hold for that to actually work:

• Instant execution. An application can't wait 45 seconds for a task to start. It needs to feel like a function call, not a deployment, and billed accordingly.
• A flexible runtime. No 30-minute timeouts, no one-size-fits-all specs. The full flexibility of long-running environments, a full range of compute sizes, any app bundle size, and real concurrency.
• Managed, stateful orchestration. Long-running chains of tasks, sometimes spanning hours or days, need their state maintained automatically and throughout, not stitched together with your own queues and glue code.

Render Workflows is the first primitive in the Application-Defined Compute stack: define tasks in your own TypeScript or Python code using the Render SDK, and Render handles the queuing, worker pools, state management, retries, and observability behind them. You pay for compute only while a task is actually running.

To make the idea concrete, a PM at Render, Yaroslav Borets, walked through a live example: an internal analytics agent. Render's own data science team built an internal analytics agent to answer basic business questions, then pushed it well past basic analysis; it now generates reports, runs on a schedule, and does heavy data crunching, with individual tasks ranging from seconds to hours and compute needs that swing depending on the question asked. That unpredictability made the system hard to architect at scale.

Before Workflows, the stack looked like a typical web service plus a background worker to offload complex compute, backed by a queue, autoscaling logic, and a lot of retry logic to make it reliable. A lot of complexity that nobody on an internal team particularly wanted to own. Workflows replaced the entire background stack. Enabling it took one decorator around the core agent loop. From there, every time the loop runs, Render provisions the stack, gives full observability, and hands the application what it needs on the fly; each task in its own container, so a filesystem-first agent can do its work without tasks running over one another.

In a live demo, Slav asked the agent a simple question about May signups. Compute was provisioned in under a second, and every task the agent ran was visible on the dashboard in real time: inputs, outputs, and logs for each one, retryable if something failed. The agent found a spike in signups on May 20, and because Workflows maintains state across the conversation, Slav could ask a follow-up question without the agent needing to re-pull context from scratch. The answer: organic search and referral traffic spiked because a competitor had an incident, and a number of their customers switched to Render.

As Slav put it, the data science part is the easy part to demo; the real power is scaling the agent, which is exactly where the complexity lives. Render's goal is to remove infrastructure from that equation entirely, whether the agent in question is doing data science, coding, or something built on a net-new agent harness. Application-Defined Compute is the umbrella; Render Workflows is the first product shipping in it, with Sandboxes to follow.

Next up was Render's Tej Chilukuri, on what it takes to build, debug, and scale applications on Render using AI tools. "Literally on the walk over here, I think I saw half of you with Claude Code open on your laptop," he said. Agents write a lot of code now, prompt to a working full-stack app, running on localhost, in minutes. Getting from that locally working code to a real, distributable application still requires CI/CD, infrastructure, and observability that the agent doesn't have context on, which is where the human becomes the bottleneck again.

Render CLI and MCP give agents that missing context directly, instead of a developer bouncing between dashboards across providers to gather it by hand. Tej walked through a live example: a basic full-stack app (web service, Postgres, background workers for billing, email, and syncs) gets a bug report: a user can't upgrade their billing plan. He reproduces it, takes a screenshot, and drops it into a coding agent with instructions to go fix it. The agent loads Render's debug skill over MCP, pulls logs, metrics, and current production state, and forms a hypothesis: shared storage is needed between the worker and the API service, solved with Render Key Value. With approval, the agent edits the render.yaml file, updates environment variables across both services, and pushes to GitHub, which automatically spins up a full-stack preview environment so the change can be tested in isolation before it ships.

Three things came out of that demo, in Tej's framing: context, through the Render CLI and MCP, so an agent understands production well enough to form a real hypothesis; control, since teams that don't want full YOLO-mode autonomy can require agent-proposed infrastructure changes to go through blueprints and code review; and confidence, since previews aren't limited to the frontend: they cover Postgres, Key Value, workers, and everything else the change touches, all in one isolated environment.

Hundreds of thousands of teams are already shipping this way. Customers like Ferndesk migrated their entire production stack within hours using the Render MCP, work that would have taken days or weeks before.

Tej also previewed what's next: granular permission controls over exactly what an agent can and can't do, audit logs and agent identity so teams can federate access consistently across their agents, infrastructure time-travel to revert to an exact configuration from days ago in 30 seconds, cost controls, and remote dev environments so an agent can work in a cloud setting without a laptop needing to stay cracked open. The goal, as he put it, is a safe, intelligent cloud where agents do more of the work and teams keep all of the control.

Anurag closed the keynote by introducing two of what he called the most prolific and effective AI builders in the industry: Ben Broca, solo founder of Polsia, who has scaled the product to more than $10 million in ARR as its only employee; and Kieran Klaassen, creator of compound engineering, who built Cora (an AI email assistant) without writing a single line of code himself.

If you missed localhost, keynote and session recordings will be posted as they're ready. And if you want to start building on Application-Defined Compute today, Render Workflows is live now.