Render networking
Designing four networking features that gave Render customers a way to see, route, and control traffic the platform was already carrying.
The network was real, expensive, and missing from the product
Render hosts over 6M developers’ applications and services with billions of network calls daily, and rapidly increasing. You connect your code, and Render builds and runs it without you managing servers. That works for most of what a developer does. It works less well for the network, where a database lives somewhere else, when a payment processor decides whether to trust the address your traffic comes from, and a customer’s security team asks who can reach a service.
In early 2025 the dashboard had little to no networking information for customers to analyze or observe. A service had one bandwidth chart that measured roughly 40% of its outbound traffic. A private connection to a customer’s own AWS or GCP resources took a support ticket and five to seven days to connect. Web services were either public to the entire internet or unreachable from outside Render, and outbound IP addresses were shared across thousands of customers and could change without notice.
Between March 2025 and May 2026 I was the sole designer on four features that addressed this: self-serve private connectivity, bandwidth metrics and observability that supported a pricing change, inbound IP rules, and dedicated outbound IPs. Each one took behaviour the platform already had and gave it a name, a state, and a place in the product. None of them had formal user research, so the evidence I designed against was support tickets, sales calls, incident reviews, and internal bug bashes.
Deciding what each surface should leave out
Ship a read-only version of Private Link first
Customers who already had a Private Link couldn’t see it, and the manual setup depended on values that only exist inside Render’s infrastructure. We shipped a read-only networking page first, with a single contact support link we measured. It reached customers four weeks before self-serve workflow did, showed us that awareness was holding adoption back more than capability, and created the section in our Information Architecture the next three features were added to.
Name every traffic type, but only show the ones that apply
I replaced the single bandwidth line with four named traffic types and coloured them in two dataset groupings, so the chart reads as two categories before it reads as four lines. Each chart only shows the types of bandwidth a service can produce, so a static site shows HTTP responses and nothing else.
Hold back the per-service invoice breakdown
A week before the pricing change, the team wanted to show bandwidth per service on invoices, the most requested item in support tickets. I recommended we wait, because our attribution wasn’t accurate enough yet, and a wrong number on an invoice turns a billing question into a trust question. Pausing to do this right allowed us to ship five days after launch with accurate traffic and bandwidth numbers.
Scope dedicated IPs to environments, not services
The original proposal assigned dedicated IPs per service, which matches how the infrastructure works. Customers think about production, not individual services, so we scoped them to a workspace or environment and one purchase covered everything in it. Beta testers named environment scoping as the part that made immediate sense for their infrastructure management.
A networking section built one feature at a time
Self-serve Private Link moves back and forth between the Render dashboard and the AWS console. I placed Render’s AWS account ID inside the step where it’s needed, and showed Render’s provisioning status next to the AWS connection status, because a single combined status would read “pending” at the moment the customer needed to act in AWS. We called it Private Link rather than AWS PrivateLink, which left room for us to extend to other cloud providers once customers started asking for them.
Inbound IP rules let customers restrict access to their resources at the workspace, environment, and service level, and blocked requests are logged with the level that blocked them. This rule model was designed by our network engineering team. It was right for the system, but rules add together within a level and must all pass across levels, and nothing in the interface shows which is which. After a year of support conversations, I built an updated prototype and proposal of an evaluation chain showing where a request passes, gets blocked, or is never evaluated. That proposal hadn’t shipped at the time of writing, but reviewers found it explained the rule relationships more clearly than the mockups had.
A networking section that didn’t exist before
All four features are in production. Private Link went from 17 workspaces, all set up by hand, to 34 within three months of self-serve launch, carrying about 27% of daily inbound traffic to the platform at 20% the cost per GB compared with public egress costs. The bandwidth metrics shipped on the date of our platform-wide pricing change, so customers could see the traffic they were being charged for, and compare how the repricing impacted their costs. This let customers make an informed choice about how to configure networking, nudged them toward cheaper and more secure options, and significantly improved our networking margins.
Two issues throughout this process taught me the most. The billing page calculated bandwidth from cost instead of reading it directly, so when a pricing bug appeared in the first month, the page stayed consistent while showing the wrong numbers, which made it slower to diagnose. Dedicated IPs also required a completed billing cycle before purchase to avoid abuse and bad actors on the platform. It was a reasonable policy for platform security that never went through design review and became the most common support question after launch.
Due to resourcing constraints, none of these projects had a usability measure we could track effectively, only revenue, adoption, and traffic figures.
Each feature was right on its own, but together they ask a customer to learn four ways to answer one question: what does the network do for this service? The next step I’ve proposed is one networking model rather than more features. Policies are defined once and attached to a workspace, environment, or service, with one view per service showing who can reach it, where its traffic exits, and which private path it uses. Private Link and dedicated IPs already work this way, so the model extends a pattern already in the product.