Static IPs for browser checks.

[pshanoop]

💡 For general support requests and bug reports, please go to checklyhq.com/support

Is your feature request related to a problem? Please describe.

• I would like to browser-checks for our internal tools (Blocked IPs, Some in private network). Which is not open public? I don't have much control on web server level to these tools. Currently, there is no way to have checks to these.

Documentation suggesting whitelisting AWS-IPs doesn't make sense, this basically means opening to internet.

Describe the solution you'd like

• Static IP sets. I don't know how your infrastructure looks like, if it's possible to run check runners behind few NATs. We can have IPs sets which can be whitelisted in our LB/firewalls. Any ways these IPs can be changed if your infra needs some update, So an API endpoint which list current IPs help more, to automate IP whitelisting.
• If NAT is not a possible solution, having an open AWS SNS, Even-Bridge some sort where I can subscribe in our AWS accounts to load new IPs to SGs using lambda.
• Having private-link or VPC peer to our VPC. This can help to have checks on private network itself.

[tnolet]

Hey @pshanoop thanks for reporting this. Solid write up. We are actively looking at some different flavours of running Checkly for more private workloads.

1. On premise runners. This means you install the our runner (using probably Docker) on your own machines inside the firewall.
2. Your suggestion would be BYOC, or Bring Your Own Cloud. In this case AWS, as we run on AWS.

You are correct that white listing IP's makes no sense when using ephemeral resources like we do. I don't have any hard data on when we would deliver something like this, but I'm pretty sure we will dive into either or both use cases when the time comes.

[pshanoop]

Hey @pshanoop thanks for reporting this. Solid write up. We are actively looking at some different flavours of running Checkly for more private workloads.

1. On premise runners. This means you install the our runner (using probably Docker) on your own machines inside the firewall.
2. Your suggestion would be BYOC, or Bring Your Own Cloud. In this case AWS, as we run on AWS.

You are correct that white listing IP's makes no sense when using ephemeral resources like we do. I don't have any hard data on when we would deliver something like this, but I'm pretty sure we will dive into either or both use cases when the time comes.

Thanks for the reply, I really appreciate it.

Runner solution sounds nice, especially for enterprises with high security standard etc. and for checking things available only on internal network.

In our case, we are opting for ChecklyHQ instead of AWS synthetic Canaries, was to avoid having to maintain our monitoring system and have a second eye on our infra. So having to maintain runners would be a pain.

For things in public network with IP restriction, I would say whitelisting IPs are simpler and easy solution. Is NAT off the table for you guys?