Enable Native Static Outbound IPs | Feature Requests | Render now says:
For Oregon, all accounts created on or after January 23, 2022 can use the following stable outbound IPs: 44.233.151.27, 35.160.120.126, 34.211.200.85
For existing Oregon users: if you create a new team without transferring existing services to it, you can use the static outbound IPs above.
That’s awesome! I’m an existing Oregon user and would like a static IP for some, but not all of my services.
I considered setting up a new team, launching a service in it, and then communicating from my existing service to the new service via its external web address. This new service would have a fixed IP, and all would be well.
Except, I think if I did this, I would run afoul of Cloudflare’s 100 second timeout. My use case is to permit my customers to run scheduled queries against their databases. Some of these queries can exceed 100 seconds.
Is there a workaround here? Some possibilities that I can see:
- Being able to opt out of the 100 second Cloudflare limit
- Being able to use an internal/non-Cloudflare IP when talking to the second service from the first service, despite them being in different teams
- Rewrite the seccond service to offer an asynchronous/polling-based endpoint so that the first service never makes a long-running request to the second service. I’d prefer not to add this complexity yet.
Thanks for any guidance you can offer!
Hi @cldellow,
Glad to hear you’re excited about this change! You are correct in assuming that if you chose to connect as a web service, you would run against the Cloudflare 100 second timeout. At the time, we unfortunately do not have a way to opt users out of Cloudflare or adjust this limit on a per-user basis. We’re also unable to have services on different teams communicate via a private network at the time, so unfortunately, that rules out options 1 and 2 here.
If you are able to create a new team and migrate your services over (note that this would have to be done manually and not via the in-app option to transfer all services over), then this would allow you to have your services communicate via private network and get around the Cloudflare timeout. I understand there’s a considerable amount of overhead with this option as well. Otherwise, looking into making the endpoint asynchronous may be the way to go.
Thanks for the response.
If I created a new team, would all external traffic go via those 3 fixed IPs? Some of the services that I use have IP-based rate limits, and it’s actually useful to draw from a larger pool of IPs, even if they’re not fixed, when communicating with those services.
Hi @cldellow,
Sorry for the delay in response here. That’s right, external traffic for the new team would be coming from one of those 3 IPs.
I did also bring this up internally for discussion and have an update that may be helpful. We’ve increased the Cloudflare timeout to 100 minutes for HTTP requests, so hopefully that helps if you do decide to go through with this setup.