[HN Gopher] Render raises $80M in Series C financing
___________________________________________________________________
Render raises $80M in Series C financing
Author : ro_arepally
Score : 76 points
Date : 2025-01-26 18:47 UTC (4 hours ago)
(HTM) web link (render.com)
(TXT) w3m dump (render.com)
| tadeegan wrote:
| Google will buy them to reduce chance of legitimate competition
| probably...
| srameshc wrote:
| What customer base will Render bring to them ? Google directly
| competes with AWS and Azure and it need the big enterprise
| customers if any .
| 9283409232 wrote:
| Companies will make acquisitions as a means of preventing
| competition. It might not be about bringing a new customer
| base but protecting the one you already have.
| XorNot wrote:
| Also all those services basically just sit back and wait till
| a company gets big enough to have in-house
| SevOps/SRE/whatever and the inevitable cost optimising
| migration gets demanded.
| scirob wrote:
| or maybe Salesforce will buy them as they have an appetite for
| breaking nice things
| sebmellen wrote:
| What differentiates Render from Railway and Fly.io?
| tonyhart7 wrote:
| I use railway but have experience on both render and fly io
| (not to a degree of railway, so take it as grain of salt)
|
| just an UI??? for the most part like deploy postgress, deploy
| Go webserver etc like 80% of the work is SAME, they don't have
| moat
| anurag wrote:
| Fully managed Postgres with high availability and point-in-time
| recovery is a big reason developers choose Render.
| pm90 wrote:
| Is this a better heroku?
|
| My experience is that anything outside of the standard process
| for deploying apps is actively frowned upon by everyone except
| startups that need to move extremely quickly to create PoCs. So
| unless this platform is much much cheaper than the public clouds
| it seems like a limited market.
| gkoberger wrote:
| Yes, and I say this as someone who used Heroku for over a
| decade and recently switched to Render.
|
| The Heroku platform has recently gone downhill. There's a ton
| of downtime, minimal improvements, no communication via their
| status page, and incredibly bad support. They once shut off
| GitHub deploys for months with no explanation, because of a
| security incident they seemingly couldn't fix... we had no way
| to deploy!
|
| Heroku was amazing, but it's dying rapidly. Render isn't a huge
| departure from Heroku, but it's solid and the team is very
| responsive.
| latchkey wrote:
| If this tells you anything, the CEO of Heroku (who was ex
| AWS), just left for Nvidia. I asked him directly before he
| left if he was interested in GPU compute and his only answer
| was basically... "only what it is available on AWS"... which
| is where all their stuff is hosted now.
|
| https://techcrunch.com/2024/11/14/heroku-ceo-bob-wise-
| depart...
| gkoberger wrote:
| Oh thank god. I had the displeasure of meeting with him
| once, and it was so bad that when we hung up I had our team
| to start planning a migration off of Heroku.
|
| The crux of the issue was that he told me that he
| philosophically didn't believe Heroku should put up status
| notifications about downtime or performance issues until
| AFTER they fully understood the problem and had a fix. (My
| theory was actually that no engineers worked there and they
| didn't have on-call rotation anymore)
| latchkey wrote:
| Wow, only one open job req and I can't figure out who is
| going to replace Bob. Seems like the platform is dead.
|
| https://salesforce.wd12.myworkdayjobs.com/en-US/Heroku
| jacobsenscott wrote:
| As a long time heroku user, I'll never go back to heroku.
| They've been working on wild card ssl for _years_ and can 't
| get it done. I finally hacked it into our app with about 100
| lines of ruby. They are literally doing nothing but keeping the
| lights on until the last customer drops off.
| tyre wrote:
| I gotta say, reading this I have no idea what Render actually
| does or how it's different from AWS or Heroku. They say they've
| threaded the needle between the two to provide a new way of
| deploying infra, but what that is...who knows! Naturally a
| paragraph on AI.
|
| At some point companies lose the ability to say, "We are X. It
| used to be that Y, which had issues of A, B, C. Instead, X does
| Z, so $USERS can now D, E, F." Where the letters are specific
| (not empty words like "innovative").
|
| As they grow, these companies add additional products, which is
| one reason I think they lose this. That's okay! Add one or two
| sentences (max) that say, "Once we solved Z, we kept building to
| offer L, M, and N. We expanded from serving $USERS to supporting
| $EXPANDED_USERS who need O and P."
|
| It's kind of wild how rare that clarity of communication is.
| Stripe still does a pretty good job despite the _huge_ range of
| products, complexity, customer profiles, abstractions, and
| interfaces.
|
| You can definitely tell when companies are either parroting what
| they've read other splash pages say or are using LLMs to say a
| bunch of empty platitudes. Good writing is really fking hard.
| anurag wrote:
| Hello fellow Xtripe! This blog post wasn't meant to focus on
| differentiation, but you might find this useful:
|
| https://render.com/docs/render-vs-heroku-comparison
| JTyQZSnP3cQGa8B wrote:
| It's not helping me. All I understand is that you provide
| some stuff for Docker, static web sites, and databases.
| That's good, but it seems very specific. So specific that, as
| a former devops, I don't understand why you could be useful
| to me or why I would need your help.
| anurag wrote:
| We need to improve our product marketing! Render focuses
| exclusively on application engineers who need to run things
| in the cloud without worrying about devops; this also means
| we don't focus on the needs of devops engineers.
| verdverm wrote:
| It also means that when an application reaches a certain
| maturity or complexity, they have to leave platforms like
| Render to clouds where they can do the things they need
| to operate with efficiency. There is a tradeoff point.
| Platforms like Render are small team efficient, clouds
| are organization efficient
| anurag wrote:
| This is the narrative we disagree with most people on and
| are focused on disproving: multiple unicorns have started
| and stayed on Render, and our platform continues to add
| capabilities as their needs become more complex.
| verdverm wrote:
| Exceptions to the rule (some unicorns, a crude measure
| for tech needs) do not break the rule. If anything, the
| trend is shifting back to self-hosting instead of running
| on any vendor.
|
| If you add the same capabilities you end up becoming the
| cloud provider concept you wish to "disprove", and I
| would posit that feature creep reinforces the concept
| jacobsenscott wrote:
| A lot of apps never grow to that size, and can run on
| services like render or heroku forever, saving millions
| of dollars in devops cost (the most expensive part of
| devops is the devops engineer).
|
| A good number of companies out there move to google scale
| infrastructure and spin up whole devops teams when they
| would be fine without all that out of fear of having to
| move later. That later might never come.
| verdverm wrote:
| A good devops engineer or team will pay for itself, so it
| becomes an asset rather than a liability. A certain
| amount of scale or complexity forms a baseline. I get
| consulting / contracting gigs for this very reason,
| granted what I do goes beyond just cloud infra & costs,
| devops/dx as a philosophy rather than a job title. It is
| valuable to an organization to have some(one|people)
| thinking about these problems from a global & holistic
| view
| scirob wrote:
| nothing that you can't do in AWS but generally Render tries
| to do things in less clicks and have less advanced clicks
| for you to accidentally press. Thats pretty much it nothing
| fancy.
| tyre wrote:
| Every announcement, _especially_ huge press events like
| fundraising, should be clear on value prop and
| differentiation. I'm a potential user. You had my eyeballs,
| but missed the opportunity to sell me. And if you can do it
| in 3-5 sentences, you can put that _everywhere_.
|
| It's so, so, so important to repeat your message at every
| opportunity; particularly at moments, like fundraising
| announcements, where you'll have access to new potential
| users (vs. something like a feature release where the readers
| are far more likely to be existing users.)
|
| Additionally, another group of readers here would be
| potential hires. They probably want to know why you're
| different!
| netswift wrote:
| I really love Render.
|
| AWS is too low level for me. Render helps us spin up new
| applications in a few clicks. Kind of like Vercel for backend.
|
| Might just be a skill issue but I can definitely see the value
| from using the product.
| ignoramous wrote:
| > _AWS is too low level for me_
|
| We had good success with Lightsail; but then moved to Fly.io
| & the Cloudflare platform and spend ~zero time on sre &
| devops.
| RainyDayTmrw wrote:
| I'm curious what you use for a database on Fly.io. When I
| last looked into it, a proper managed database option was
| the last thing that they were missing from what I wanted.
| SOLAR_FIELDS wrote:
| I'm not skin in the game on either company but I know
| that they partnered with Supabase for awhile on this. I'm
| not sure if that partnership is ongoing or not.
| alexeldeib wrote:
| Supabase would be a good pick. Vercel and Cloudflare both
| do SQL DBs now too, curious how they are. Neon seemed
| interesting, haven't heard much about them in a while.
|
| None of those integrated of course, but easier than going
| big cloud or self hosted
| serjester wrote:
| We use Render for our startup and I think it's major value add
| is the simple deployment story. We had a database go down for
| really strange reasons, and the render technical support was
| incredibly helpful to work with and resolved the issue in
| hours.
|
| The major cloud providers are quite intimidating to work with
| and frankly we have much bigger problems to spend our time on
| than (potentially) saving a couple grand a month. Heroku was
| nice but it's been abandoned for years. Fly is a similar
| competitor but they seem to have monthly outages. We find
| Render simple, boring and dependable - for us that's worth the
| premium they charge.
| lamename wrote:
| Good writing is hard, but it's also very easy to just
| regurgitate patterns of nonsense buzzwords you see everywhere
| else. I've seen many people hear that and just nod their head.
| Sadly it convinces some.
| RainyDayTmrw wrote:
| There's some anecdotal accounts that, through the mismanagement
| of its acquirer, Heroku is slowly dying after the acquisition.
| If Render so much as provides the Heroku experience at its
| peak, that would already be valuable, and many of us would
| already be happy.
|
| Of course, if Render directly says, "We're going to be like
| Heroku before it went off the rails," that's not compelling to
| media or investors. So, instead, they've got to fluff it up a
| bit with marketing buzz. Throwing in some AI won't hurt,
| either.
| didgeoridoo wrote:
| Heroku was acquired in 2011, so to be fair it did take
| Salesforce quite a long time to screw it up.
| SOLAR_FIELDS wrote:
| Taken more charitably from the business' perspective, the
| playbook you outline that you wish businesses provided is
| outright giving away some of the R&D that they took to arrive
| at those conclusions, which has some nonzero value to
| competitors. I would love to go ask some incumbent exactly the
| playbook of what worked and what didn't on their voyage to the
| market so that I could just skip all the things that don't work
| loktarogar wrote:
| I have a lot of data-heavy websites that are completely
| automated on Render. I don't need to care about them day to
| day. Render abstracts a lot of work away from me.
|
| Before this I used Heroku. Heroku basically filled the same
| role but nowadays it's less flexible and after all the issues I
| couldn't wait to get away from them. Render feels like a better
| Heroku for my specific needs.
| infecto wrote:
| Just in response to some of the other comments here. Render has
| been around for a bit, I always saw it as a better Heroku. Not so
| sure they need differentiate themselves, they have been around
| for a while. IMO they are a nice fit because AFAIK they have not
| invested any new paradigms and really built it up as a Heroku
| 2.0.
| mrits wrote:
| elb,ec2,s3 is still my favorite
| adenta wrote:
| I've been pretty vocal about using http://kamal-deploy.org/ more
| and more, and Render less.
|
| Kamal really is fantastic, PaaS niceties w/o the PaaS tax.
| jasoncartwright wrote:
| Fan of these PaaS-like tools on BYO servers. See also Coolify,
| Dokploy. Best of both worlds.
| braden-lk wrote:
| I run all of LegendKeeper's infrastructure on Render, save for a
| few serverless functions. It's been convenient; I rarely think
| about infra at all anymore.
| anurag wrote:
| (I'm Render's founder) What should we build next, HN?
| raywu wrote:
| Congrats on the raise and building something people love!
|
| If I could make a suggestion - make it clear you are the
| founder of Render instead of using these parentheses "(Render
| founder)"!
| rvz wrote:
| Buy Replicate [0].
|
| [0] https://replicate.com/
| scirob wrote:
| lol while your at it could you please also buy
| https://rendernetwork.com/ just becuase the name conflict
| gets confusing :)
| christophilus wrote:
| We currently use Render, Wasabi, and BunnyCDN. It's a great
| combo. If you offered a low-price object store with a CDN
| layer, that would be swank.
| serjester wrote:
| It's probably low margin but it'd be nice to see object
| storage. We host almost everything on render, and use digital
| ocean for storing assets. It leaves a ton to be desired - I
| wish it had simple object versioning, backups, even a nicer
| search tool would be awesome.
| anurag wrote:
| Object storage is a major missing piece. Stay tuned.
| scirob wrote:
| Why not compete a bit with Supabase its all opensource outside
| the OAuth integration I'm sure you can code it fast. I love the
| workflow of coding frontend and just changing the database as I
| am thinking of what data model i need and then
| https://docs.postgrest.org/en/v12/ automatically changes the
| API. (One could also say firebase competition but I highly
| prefer the postgres oriented supabase strategy)
| Sytten wrote:
| Honestly as a long term customer please polish what you have.
| By that I mean:
|
| - Teams are still the only proper way to segment environments
| and access control. Yet you charge team member, I am still mad
| about that because even after 1+ year we need to use multiple
| teams.
|
| - Metrics are still locked to your platform, I want to use my
| telemetry provider because you guys dont have alerts, dashboard
| creation, etc.
|
| - Control over the subnets, we use tailscale to give access to
| private services right now its all 10.205.X.X and we dont
| control it
|
| - Allow us to turn off cloudflare. You said during last outage
| that being reliant on cloudflare was an issue and we are yet 1+
| later without progress.
|
| I could go on. I do like the product and simplicity but it is
| lacking control when you actually outgrow the "get it out the
| door fast" phase. I am not even sure one could pass an ISO27001
| by being on Render.
| scirob wrote:
| I agree here. Render is nice now, not bloated.
| anurag wrote:
| * You can now block private network traffic from crossing
| environment boundaries
| (https://render.com/docs/projects#blocking-cross-
| environment-...). We also just launched an invite-only
| feature that creates a high-level Organizational structure
| with multiple teams, where each team member is only charged
| once.
|
| * Otel exports are in development and should be live in early
| access in a few weeks!
|
| * Heard on subnet IPs
|
| * There's ongoing work to remove a major Cloudflare
| dependency; it should also go live in a few weeks.
|
| We'll keep polishing and pushing the envelope on control and
| flexibility. Thanks for being a vocal customer.
| Sytten wrote:
| Thanks for the reply. I never understood the appeal of the
| network traffic split since it didnt come with user access
| control. Not everybody in a team needs access to all
| environments and even within an environment not everybody
| needs access to every service and/or secrets of those
| services.
|
| Couple of other things while I do have you:
|
| - More control on the instance sizing similar to how you
| have us control of the postgres instances
|
| - A proper write-only secrets system ala AWS Secret
| Manager. The current environment variables isn't passing an
| audit for sure if anybody on the team can log in and see
| them plaintext
|
| Your support team is really good I do want to say, it is
| probably the one thing that kept me a customer.
| stringtoint wrote:
| Agreeing with your points, especially regarding Cloudflare!
| For the record: we did pass ISO 27001 and we use Render.
| bambax wrote:
| You could start by explaining what you do. I still have no idea
| (better Heroku?) and judging by the comments here I'm not
| alone...
| mrdependable wrote:
| I'm trying to switch to using preview environments right now to
| optimize my git workflow and it is a bit of a bummer that I
| can't just assign preview environments their own environment
| group. I am still trying to wrap my head around the best way to
| do this because I have a lot of environment variables.
|
| I also have my object storage with Digital Ocean at the moment.
| Would love to have that all under one roof.
| woodhull wrote:
| We launched our company on Render. It was great for going from
| zero to one very quickly but we had many problems and ended up
| migrating to AWS as we scaled.
|
| * Poor visibility into detailed metrics, especially when
| problems happened in the render load balancer / routing mesh.
| We had a specific issue where a small number of requests were
| failing somewhere in render's infrastructure before reaching
| our application, and at the time there was no visibility to
| allow customers to know about requests that timed out or failed
| within render's infrastructure rather than our application. We
| collaborated with your team to surface and replicate the issue,
| but it was frustrating. I had a very good set of conversations
| with a product manager on your team about what we needed and
| why it was important in early 2024.
|
| * At the time, the hosted postgres implementation was immature.
| I think this is an area you've already improved dramatically.
|
| * Maybe you could add support for something like AWS
| PrivateLink so customers can run parts of their workloads on
| AWS securely over a private network. This would be a neat way
| to allow customers to stay on Render longer as their needs
| grow.
| jboggan wrote:
| I'm currently building on Render and I concur with the third
| point. Render is great right now but I know I'm going to need
| a more sophisticated backend data environment and analytics
| workloads in the future.
| wslh wrote:
| Is the Render token [1] somehow related to Render?
|
| [1] https://coinmarketcap.com/currencies/render/
| theodoretliu wrote:
| Was loving the ease of deployment on render but had to move off
| for lack of BAA and HIPAA compliance. Any timeline for support?
| MrAlex94 wrote:
| IPv6 support would be ideal :)
|
| https://feedback.render.com/features/p/ipv6-support
| 3m wrote:
| Object storage would be good.
| chachra wrote:
| Scale to 0 services. Might mean less money for Render but would
| be awesome. Gets a lot of side projects hosted on fly because
| if it.
|
| Partnership with Neon would be great too, I run 6 dbs there for
| $69 with auto scaling (and scales to 0 too if needed for non-
| prod envs). Render would be 3-4x that price for those many dbs.
| chachra wrote:
| Transactional email service.
|
| S3 backed object storage (too risky to use anything else or
| even learn anything else for it).
| duxup wrote:
| As an end customer these things area always mixed feelings.
|
| I'd rather hear that the company I use is profitable and
| sustainable.
| wiley1454 wrote:
| Nice.
|
| ...I remember when they won TC Startup battlefield a couple of
| years back.
|
| https://m.youtube.com/watch?v=J4Vn64_CnDg#
| asim wrote:
| Congratulations to the team at Render. I'm not a user but good to
| see some competition in the cloud space. DigitalOcean was the
| last great developer focused effort IMO. Things at a higher level
| helped various communities but nothing has really attempted to
| compete with cloud providers themselves. So good on you and keep
| going.
| anurag wrote:
| Cheers!
| lvl155 wrote:
| Congrats to the Render team. One of my favorite products.
| anurag wrote:
| Thanks!
| thundergolfer wrote:
| > we've surpassed 2 million developers ... 100,000+ developers
| who sign up for Render every month
|
| There's something like 2 million software engineers in the entire
| USA. There's no way their penetration is significant (>25%) in
| the USA, so where are these developers coming in from? India,
| China, LATAM?
| vishrajiv wrote:
| Been on Render for a few months now. Its main value prop is clean
| UX for infra, which ended up mattering a lot more than I thought.
| AWS generally induces way more cognitive load than I care to give
| it (except for S3).
|
| Congrats on the raise!
| harrisonjackson wrote:
| Render is great.
|
| Very easy to launch any docker image, script, stack etc.
|
| You can templatize any repo for a 1-button deploy with a
| render.yaml and a link in the readme. More products offering
| "self-hosted" should do this.
| kertesz01 wrote:
| Rantothus
___________________________________________________________________
(page generated 2025-01-26 23:01 UTC)