Which does absolutely nothing if your device or the app in question is permitted or otherwise not prevented from making DNS-over-HTTPS (or, less commonly because of its discrete port, DNS-over-TLS) queries.
I'm referring to devices and apps that are 'hard-coded' to query specific DoH servers/providers, therefore bypassing and regardless of any user-configured DNS server/s. And because DoH operates on outbound TCP/443, the lookups are indistinguishable from any other 'web' traffic.
Even some of the most popular desktop web browsers are configured to utilize DoH by default nowadays.
The most that a network administrator can do to prevent this is configure firewall IP blocklists of known DoH servers and NAT all outbound 53 (and 853) traffic to a desired resolver (like a local Pi-hole instance, for example).
ignoramous probably meant that in order to block access to all IP addresses that it has not recently resolved, the firewall must also host or communicate closely with a resolver. This is a tautology, not a spec.
Facebook hard-code IP addresses when their domains are blocked. I found this out while using NextDNS alongside that logging functionality that iPhones have. It’s insane the lengths that they go to.
It's not insane at all. It is the entirety of their business model, so it makes sense that they will do everything possible to keep that sweet surveillance cash flowing.
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.
We launched HTTP request logs early in 2024, which would have made things easier to debug. Similarly, we're launching full OpenTelemetry exports in a few weeks.
Deep observability is critical for more complex environments, and things are improving dramatically on this front just as they have on Postgres.
We already support AWS PrivateLink! Reach out to support@render.com.
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.
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.
* 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.
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.
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.
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)
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.
Our team considered Render but dropped for the same reason. We’re looking into Aptible right now, not as well known but seems focused on HIPAA compliance.
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.
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!
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.
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.
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
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.
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
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.
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
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.
