The QuotaGuard Engineering Blog

Koyeb runs your containers on shared infrastructure with dynamic IPs. When you need to connect to a database or API that requires IP whitelisting, you need a proxy. This guide walks through the setup in about 10 minutes.

Render provides shared CIDR ranges for outbound IPs, but many firewalls and databases require individual static IPs. This guide compares native options with proxy services and shows how to connect Render apps to MongoDB Atlas and other firewalled resources.

Learn how to get a static IP for Fly.io apps. Compare native egress IPs vs QuotaGuard proxy. Includes code examples for Node.js, Python, Elixir, and Go.

Is your n8n AI agent getting blocked? If you are seeing 403 Forbidden or ECONNREFUSED errors, the problem isn't your code, it's likely your IP address. Learn why "noisy" cloud IPs get flagged and how to fix it in 2 minutes using n8n's native proxy settings.

Non-marketplace customers can now add multiple users to their QuotaGuard accounts directly from the dashboard. Learn how to invite team members via email and securely manage shared access to your static IP subscriptions.

QuotaGuard is testing early access to Heroku's next-gen Fir platform. We are ensuring full compatibility so you can migrate your static IP workflows seamlessly as Heroku modernizes its infrastructure for better scalability and performance.

Meet strict localization requirements with our new U.S. Data Residency option. Route all proxy traffic and logs exclusively through U.S. infrastructure to align with government contracts, HIPAA, and SOC 2 standards.

QuotaGuard is now live in 10 AWS regions, including new launches in Singapore and Mumbai. Reduce latency and improve performance for your global workloads by routing static IP traffic through infrastructure closer to your data.

Render is updating its outbound IP ranges starting October 2025. If your app connects to databases or APIs that require allowlisting, these changes could break your connectivity. Learn how to use a static proxy to decouple your app from Render's changing infrastructure and maintain a stable, maintenance-free allowlist.

Does your security team prohibit traffic from leaving the EU or US? Learn how QuotaGuard’s Data Residency add-on locks your static IPs and logs to a single region, simplifying your audits for SOC 2, HIPAA, and GDPR.

QuotaGuard prioritizes production uptime by manually managing "Soft Limits" instead of implementing automated hard-stops when customers exceed their plan usage. Choosing the unscalable task of human intervention over programmatic suspension prevents critical service failures and accommodates the administrative delays of enterprise upgrade cycles. This policy has generated significant long-term revenue and trust by treating infrastructure connectivity as a shared business goal rather than a metered utility.

Hard to believe it’s been 11 years that the QuotaGuard service has been alive and kicking.Hard to believe it’s been 11 years that the QuotaGuard service has been alive and kicking.Technology companies that survive over 10 years are rare. Especially ones that are self-funded with no outside investment.

Direct QuotaGuard customers can now enable Multi-Factor Authentication (MFA) for enhanced account security. Follow this quick guide to activate 2FA in your dashboard using your preferred authenticator app.

QuotaGuard has launched a new, highly accurate Health & Status page powered by Instatus. You can now subscribe to proxy-specific alerts via Email to get real-time status updates only for the infrastructure you use.

Understand the critical differences between SSL Passthrough, SSL Offloading, and SSL Termination. Learn which method ensures end-to-end zero-knowledge encryption for compliance versus which optimizes performance by decrypting traffic at the load balancer.

Getting a static IP for Digital Ocean using QuotaGuard Static IPs

If PythonAnywhere sent you to QuotaGuard to connect to a MySQL database, the fastest path is our example Python app. It demonstrates using mysql-connector-python through QuotaGuard by monkeypatching it to route via PySocks. Install PySocks and mysql-connector-python, set the QUOTAGUARDSTATIC_URL environment variable, then follow the example app’s README.md to test locally before integrating into your real app. If it fails, Support can help debug.

Until now, QuotaGuard has allowed for TLS1.0, TLS1.1, and TLS1.2 support on Inbound Proxy connections from clients to the proxy servers. However, security experts are recommending TLS1.0 and TLS1.1 be deprecated on servers. Therefore, TLS1.0 and TLS1.1 will be deprecated on QuotaGuard Static inbound proxies by March, 31st 2019.

A Ruby app can talk to corporate LDAP easily with net-ldap, until it’s deployed on Heroku and the LDAP server sits behind a firewall. Heroku does not provide a fixed outbound IP, so corporate allowlisting breaks. QuotaGuard solves this by routing outbound traffic through a load-balanced pair of static IPs via a SOCKS5 proxy that supports LDAP. After provisioning QuotaGuard, there are two integration options: 1. SOCKS wrapper script: forces outbound TCP through the SOCKS5 proxy (optionally masked so only AD traffic goes through). It’s quick to set up, but the masking can become maintenance if AD hosts change, and the wrapper is Linux-only so local dev on macOS or Windows is awkward. 2. Patched gems: use QuotaGuard’s patched socksify and net-ldap to route LDAP through the SOCKS proxy directly via Gemfile entries. This works cross-platform and avoids per-host masking work, but it depends on custom forks that may lag upstream updates.

If you are currently seeing this error when making a request through QuotaGuard Static, you need to contact our Support to get it resolved, as this is usually a result of a manual pausing of your QuotaGuard subscription.

We’re pleased to announce the Beta launch of our Inbound service which allows you to access your website via a Static IP address. This allows you to access web applications running on dynamic cloud platforms like Heroku, Gigalixir, or GCP from within a corporate environment with strict firewall controls.

One undocumented feature is its ability to route all requests through a proxy server. This can be very useful when trying to use Ruby Geocoder* with Heroku or other PaaS that hide behind shared ip addresses as it allows you to reclaim your daily request usage from Google.

We are deprecating non-Shield support for the HTTPS proxy by September 2021 for security reasons. All customers using https:// connections must migrate to the QuotaGuard Shield service. This guide provides the simple steps to move your subscription and secure your traffic.

Seeing QuotaGuard Error 1222 or 2297? This indicates your account is suspended due to exceeding usage limits or an inability to contact you for quota upgrades. This guide provides the exact steps to upgrade your plan across Heroku, AWS, and Azure, and prevent future service interruptions by updating your contact email.

Need a static IP for your Heroku app to access firewalled databases or APIs? This guide compares the two main options: building your own Squid proxy on AWS (high maintenance) versus using a hosted add-on like QuotaGuard Static for zero-config, load-balanced egress.

Hitting Google's "OVER_QUERY_LIMIT" on Heroku? Shared cloud IPs often exhaust Google Maps' free tier limits instantly. Learn why this happens and compare four solutions: client-side geocoding, retrying requests, building your own proxy, or using QuotaGuard to get a dedicated static IP.

How to Find and Download Historical QuotaGuard Invoices

Learn how to migrate from a marketplace add-on (like Heroku) to QuotaGuard’s direct service without changing your static IPs or proxy URL. Our support team can seamlessly transfer your existing configuration to a new direct account with zero downtime.

Getting a static outbound IP on Azure can be difficult since deployment IPs are often dynamic. This guide explores three solutions: pinning Azure VMs (risky), building your own EC2 proxy (complex), or using QuotaGuard Static for a load-balanced, zero-maintenance static IP available directly from the Azure Marketplace.

We cancel services when we do not need them anymore, and I hate when SaaS companies make that painful. So we keep cancellation simple and self-serve. If you subscribed directly through quotaguard.com, cancellation is permanent and you will likely get new IPs if you ever come back since canceled IPs get rotated. To cancel: • Log into your QuotaGuard account • Click Edit Account (top right) • Click Billing • Scroll to the bottom and click Cancel Account If something is unclear or you ran into an issue, email Support.

Download your QGTunnel config from the QuotaGuard dashboard as a .qgtunnel file and store it in your project root so your app startup does not depend on our site being reachable. For multiple environments, you now have two options: keep using a launch script that selects the right .qgtunnel file, or set the QGTUNNEL_CONFIG environment variable to point to the correct config per environment. QGTUNNEL_CONFIG requires the April 2021 (or later) qgtunnel release. Update via: curl https://s3.amazonaws.com/quotaguard/qgtunnel-latest.tar.gz | tar xz

QuotaGuard Static and QuotaGuard Shield are now available on the Microsoft Azure Marketplace. To sign up, find the QuotaGuard Static IP listing in the marketplace and follow the Azure signup flow. If you need a walkthrough, we have a short video showing how to add QuotaGuard Static IPs to Azure. Support can help if anything doesn’t match your account or portal view.

We’re live on AWS Marketplace. QuotaGuard Shield and QuotaGuard Static are both available there now. Same products and team. The difference is you can buy and run QuotaGuard through AWS. If you need help getting a static IP working on AWS, contact Support.

QuotaGuard Shield is now generally available on Heroku. It’s QuotaGuard Static with a key difference for inbound traffic: SSL passthrough. Incoming SSL is not decrypted at our load balancer. It’s passed to your Heroku app to decrypt, which matters when certificate handling and security controls need to stay on your side. By contrast, QuotaGuard Static uses SSL termination, which requires certificates on our infrastructure so we can decrypt and forward requests. Shield removes that requirement. SSL is configured entirely in Heroku, and you can use Heroku ACM. QuotaGuard Shield on Heroku is also positioned as HIPAA compliant for securely transferring sensitive data.

Do you need to change your credit card for your QuotaGuard subscription? It’s pretty simple and available in our dashboard.

Azure makes canceling QuotaGuard weird because the QuotaGuard resource page often has no delete action. The reliable workaround is to use All resources, find the QuotaGuard subscription in the list, select it using the checkbox (do not click into it), then delete it from the list view. If Azure changes the UI again, support can help. Credit to Dan Kroymann at RecRoom.com for the workaround.

To change your QuotaGuard plan on Azure, log into the QuotaGuard admin panel, open the account menu on the right and choose Edit Account, then go to Billing. Under Subscription Plan, click Change Plan, pick the new plan, and confirm. Plan changes do not change your IPs or connection URL, and they should not interrupt service.

We regularly get asked how to attach QuotaGuard Static or QuotaGuard Shield to a specific Heroku app. Process: open the target app in the Heroku dashboard, go to Overview, find Installed add-ons, click Configure add-ons, search for “QuotaGuard,” pick the add-on and plan, then click Provision. After provisioning, use the arrow next to the add-on to jump into the QuotaGuard admin panel and grab settings and connection details. Heroku also emails the connection info.

If you find yourself trying to route through QuotaGuard from the Azure function App, we wanted to post this sample code as a possible solution.

We updated QuotaGuard inbound proxies to support the same load-balanced setup as our other proxies. Instead of a single static IP, load-balanced inbound proxies now use two static IPs behind a load balancer. What changes on your side: • Update IP allowlists to include both inbound proxy IPs (two addresses). • If you use a custom domain, switch DNS from an A record to a CNAME pointing at the provided hostname. Example: • dae5060e659305e4-us-east-1.getstatica.com allowlist: 10.10.10.1, 10.10.10.2 • test-inbound.quotaguard.com set as CNAME -> statica.quotaguard.com, allowlist: 10.10.10.1, 10.10.10.2 We can enable the load-balanced setup for your existing inbound proxy, or keep you on the prior single-IP setup.

Quick update regarding the forthcoming GDPR Privacy law going into effect in the EU region.

QuotaGuard Dynamic IPs are meant to make Google Maps Geocoding API usable from platforms like Heroku by spreading requests across many proxy machines. That avoids OVER_QUERY_LIMIT from per-IP throttling until you hit Google’s daily cap (2,500 as of Nov 2013). But Google also rate-limits per second. If you exceed roughly 4 requests per second, you can still get temporary OVER_QUERY_LIMIT responses. The practical fix is retries with backoff, which usually shows up during bulk geocoding jobs (often a Ruby rake task). The example approach is: geocode each record, check whether it actually geocoded, and if not, sleep briefly and retry a few times. Caveat: the Ruby Geocoder gem does not reliably raise on failures, so the “not geocoded” check can trigger retries for bad addresses too.

cloudControl is a Berlin-based European PaaS that supports Java, PHP, Python, Ruby, and Node.js, and it’s a solid Heroku alternative for EU-focused apps. We released a beta cloudControl add-on for QuotaGuard Static. It routes outbound traffic from your app through a fixed, load-balanced static IP so third-party services that require IP allow-listing work even when your app scales horizontally and its instance IPs change. cloudControl users can enable it in one click from the add-ons page. Everyone else can use the standalone QuotaGuard Static service.

To upgrade or downgrade QuotaGuard Static or QuotaGuard Shield on Heroku, open your app in the Heroku Dashboard, go to Resources, and click the QuotaGuard add-on. Use the menu on the right to choose Modify Plan, select the plan you want, then click Provision. Plan changes do not change your IPs and should not interrupt service.

Today we are pleased to announce our arrival in South America with our first QuotaGuard Static instance available in the Amazon Web Services Sao Paulo region. As with all our QuotaGuard Static instances you get access to a pair of load balanced, low latency static IP addresses supported round the clock by our industry leading engineering team. This new offering significantly reduces latency for customers with data centres in South America and allows those needing to keep all data transfer within Brazil to do so. To access our Sao Paulo service just select sa-east-1 as your preferred proxy region when signing up.

I wanted centralized logs I could search by user, so I spun up a self-hosted Elasticsearch cluster on EC2 and wired Logstash into it. Setup was easy and I quickly had a real-time log viewer for QuotaGuard. Operating it was the disaster. Unassigned shards, stuck initialization, cluster health stuck RED or YELLOW, and I could not get it stable without wiping everything. Then AWS flagged one node as part of a DDoS and told me to terminate it. I gave up on self-hosting. I moved to Elastic Cloud. In minutes I had a working two-node cluster, pointed Logstash at it, and everything stayed GREEN. Lesson: when a specialist runs something critical as a service for a reasonable cost, pay them. It is usually cheaper than becoming the on-call expert yourself.

Fog is a solid Ruby library for working with cloud services, but its documentation gets thin fast when it comes to testing. While building QuotaGuard, I ended up relying on Fog’s built-in mock mode and a few RSpec habits to keep the test suite sane. The first habit was treating Fog’s mock state like a database. In every spec, I enabled mocking and reset Fog’s in-memory model before each example. If I did not, tests would silently leak state into each other and failures would show up far away from the cause. The second habit was accepting that Fog mock mode starts as a blank cloud. It does not know anything about my real AWS setup. No buckets, no keypairs, no load balancers, no instance IDs. That means any dependency my production code assumes exists has to be created in the mock environment first. A simple example is creating an EC2 instance with a :key_name. Fog validates that the keypair exists. In production it already does, but in mock mode I had to import that keypair before calling the code under test. The third habit was being intentional about Fog’s simulated delay. Fog can mimic the real-world lag between “resource created” and “resource ready,” which is useful when testing code that waits or polls. But across a large test suite it can be unnecessary drag. When I wanted speed and determinism, I set Fog::Mock.delay = 0. When I wanted to exercise readiness assumptions, I left the default delay in place. The basic pattern was consistent: reset mock state, build only the cloud resources the test needs, then choose whether I care about readiness timing for that specific test.

We have performed routine server management and deployed logging for all types of proxies. With this we have implemented graphs for all types of proxies and will deploy today.