Your Enterprise Customer Needs a Static Destination IP. Here Is the SaaS Architecture

If an enterprise prospect says, “Give us one or two IP addresses to allowlist before our network can reach your SaaS,” put a managed static inbound proxy in front of the application. The customer connects to a small, stable destination list. QuotaGuard forwards the request to the cloud endpoint you already operate. Your application can redeploy, scale, or move without forcing the customer's security team to rewrite its firewall rule.

This is not an invented edge case. Keygen's own documentation says it uses QuotaGuard to provide dedicated static IP addresses to Keygen Cloud customers on an Ent tier. Keygen keeps its licensing API on dynamic cloud infrastructure while QuotaGuard supplies the fixed destination enterprise networks require.

The Enterprise Deal Stalls at One Network Question

The application demonstration works. Procurement approves the commercial terms. Then the customer's security team asks:

Which public IP addresses should we allowlist so our servers can reach your service?

A hostname is not always enough. Some enterprise outbound firewalls, private networks, regulated environments, factory systems, and long-lived installed applications permit connections only to approved destination IP addresses. If your SaaS sits behind a cloud platform, CDN, serverless endpoint, or shared load balancer, those addresses may change or span a range the customer refuses to approve.

The problem is not authentication. The customer may already have an API key, OAuth credential, client certificate, or signed request. The problem is that its network will not open the connection until the destination has a stable identity.

First Determine Which Side of the Connection Must Be Static

“We need a static IP” can mean two opposite things:

This article covers the second case. From your SaaS company's perspective, the traffic is inbound. From the customer's firewall perspective, it is an outbound connection to an approved destination.

That directional distinction prevents a common mistake: putting an outbound proxy in the application and expecting it to change the IP address customers use to reach you. It cannot. A fixed customer-facing destination must sit in front of the application.

The Architecture Is Simple

Enterprise application
  -> two allowlisted QuotaGuard static IPs
  -> QuotaGuard inbound proxy
  -> your existing HTTPS application endpoint

In the QuotaGuard dashboard, configure the public HTTPS endpoint that should receive the forwarded request. QuotaGuard issues a stable hostname backed by the static IP pair. Give the hostname and both addresses to the customer's network team.

The customer sends requests to the QuotaGuard-facing hostname. The customer's firewall sees the approved destination addresses. QuotaGuard forwards those requests to your application.

Your origin can remain on Heroku, Render, Vercel, AWS Lambda, Azure, Google Cloud, Kubernetes, or another reachable cloud platform. The enterprise-facing identity no longer depends on the address currently assigned to that origin.

Keygen Proves This Is a Product Feature, Not a Workaround

Keygen sells a cloud software-licensing and distribution API. Some Keygen customers operate in environments where the licensing client cannot reach a dynamic cloud destination. Keygen's documented answer is direct:

“Keygen uses QuotaGuard to offer dedicated static IP addresses to Keygen Cloud customers on an Ent tier.”

Keygen provisions a replacement QuotaGuard-backed hostname with up to two static IP addresses. The customer changes the Keygen API base URL and gives the supplied addresses to its firewall team. Keygen remains the product vendor; QuotaGuard operates underneath as the managed network layer.

That model is commercially useful for other SaaS companies:

• Most customers continue using the normal cloud endpoint.
• Enterprise customers with strict networks receive the static-IP option they require.
• The SaaS vendor does not move its entire application onto bespoke infrastructure.
• The feature can be packaged with the enterprise plan that creates the requirement.
• QuotaGuard, not the SaaS engineering team, owns the proxy infrastructure pager.

For the Keygen-specific configuration and buying path, see the Keygen static IP integration page and the existing article about Keygen's QuotaGuard-backed Ent option.

Why Not Give the Customer Your Current Cloud IP?

Because “current” and “contractually stable” are different things.

A cloud hostname may resolve to different addresses after a deployment, platform maintenance, capacity event, region change, or infrastructure migration. Even when an address remains unchanged for months, that history is not a guarantee. The enterprise customer is asking for an identity it can approve and retain, not a snapshot you copied from DNS today.

Publishing a broad cloud-provider range is not equivalent either. A range can contain infrastructure operated by unrelated tenants, change over time, and be too large for the customer's security policy. The clean answer is a small address set attached to the integration the customer is actually approving.

Why Not Build the Static Front Door Yourself?

You can. A cloud load balancer, network appliance, pair of virtual machines, or custom reverse-proxy deployment can provide fixed public addresses. That decision also creates a production network service your team now owns.

The real comparison is not the hourly cost of an IP address. It is responsibility for:

• Redundant hosts and removal of single points of failure.
• Health checks, failover, capacity, and connection limits.
• Operating-system and proxy maintenance.
• TLS configuration and certificate lifecycle.
• Monitoring, alerting, incident response, and after-hours pages.
• Regional placement and future migrations.
• Customer support when a firewall rule or route behaves differently than expected.

QuotaGuard exists so the SaaS team can sell the enterprise capability without quietly becoming a network-appliance operator. The stable destination remains portable even if the application moves to another hosting platform later.

Implementation Plan for a SaaS Team

1. Confirm the Customer's Exact Rule

Ask whether the firewall controls destination IP, destination hostname, port, protocol, or all four. Confirm whether the customer accepts two addresses for availability and whether the addresses must be exclusive to your company.

Do this before provisioning. “We require a static IP” is not precise enough to design the route.

2. Choose Shared or Dedicated Infrastructure

QuotaGuard documents inbound proxy capability on all direct Starter plans and above. Standard subscriptions use managed shared proxy infrastructure. If the contract or security review requires customer-only addresses and dedicated proxy resources, choose an Enterprise dedicated configuration.

Do not imply that a standard shared pair is exclusive. Sell the architecture the customer's policy actually requires.

3. Configure the Origin

Provide the reachable HTTPS endpoint that QuotaGuard should forward to. Keep the origin protected with normal application authentication and authorization. A hidden or difficult-to-guess URL is not a security boundary.

Place the QuotaGuard region near the origin to reduce the additional network leg. QuotaGuard operates in 12 AWS regions, and the region is selected during signup.

4. Choose the Customer-Facing Hostname

You can use the provisioned QuotaGuard hostname or configure an approved custom-domain path. A branded hostname is usually the better long-term product experience because the SaaS vendor retains control of the name customers configure.

Follow the QuotaGuard dashboard instructions for DNS and certificate configuration. Do not publish an endpoint until HTTPS, origin forwarding, and error behavior have been checked.

5. Give the Customer Both Static Addresses

The customer should allowlist both addresses assigned to the inbound route. A successful test against one address does not make the second optional. The pair exists so the service can remain available when traffic moves between healthy routes.

Provide the hostname, both addresses, port, protocol, expected request path, authentication method, and a named support contact in one implementation sheet. That is easier for the customer's network team to approve than a sequence of partial answers.

6. Test the Security Control, Not Just Connectivity

Confirm that an approved customer network can reach the new hostname. Also confirm that the application still enforces its credentials, authorization, rate limits, and request validation after the proxy is inserted.

If the customer's policy requires exclusivity, verify the dedicated infrastructure requirement in writing before go-live. If the workload carries regulated or especially sensitive data, use the QuotaGuard product and configuration approved for that security architecture.

A Static Destination Is One Layer, Not the Whole Security Model

A destination allowlist controls where the customer's system may connect. It does not prove who sent a request once it reaches your application.

Keep the controls that make the API secure:

• HTTPS for the complete external path.
• API keys, OAuth, mTLS, signed requests, or another appropriate authentication method.
• Least-privilege authorization.
• Replay protection and timestamp validation where the protocol supports them.
• Rate limits, request logs, anomaly alerts, and credential rotation.
• Origin controls that prevent unintended bypass of the approved customer-facing path when required.

The strongest sales answer is not “the IP makes us secure.” It is “we can meet your fixed-destination network control without removing any of the application controls already protecting the service.”

Turn the Firewall Requirement Into an Enterprise Feature

When a security review asks for static destination IPs, the wrong response is to tell the prospect that cloud addresses change and hope the requirement disappears. The better response is to make the network identity part of the enterprise package.

Keygen has already demonstrated the model. Its customers get a Keygen feature. QuotaGuard supplies the static infrastructure behind it.

Your SaaS can do the same:

• Keep the existing cloud application.
• Give approved customers a stable enterprise-facing hostname.
• Provide a small address pair for the firewall change request.
• Use dedicated infrastructure when exclusivity is part of the contract.
• Let QuotaGuard manage availability, maintenance, and the network pager.

Frequently Asked Questions

What is a static inbound IP for SaaS?

It is a stable public destination address placed in front of the SaaS application. Enterprise customers connect to that address, and an inbound proxy forwards the traffic to the application's actual cloud endpoint.

Is an inbound proxy the same as a static outbound IP?

No. An inbound proxy gives customers a stable destination for reaching your application. An outbound proxy gives your application a stable source identity when it connects to another system.

Why are there two IP addresses?

The pair supports availability and failover. Customers should allowlist both supplied addresses so either healthy route remains usable.

Can I use my own domain?

QuotaGuard supports custom-domain inbound configurations. Follow the current dashboard and DNS instructions for the selected product because the certificate and setup process differs by architecture.

Does the customer need a QuotaGuard account?

No. The SaaS vendor operates the QuotaGuard subscription and presents the stable endpoint as part of its own product. Keygen follows this model for its Ent static-IP option.

Are standard QuotaGuard addresses dedicated?

No. Standard subscriptions use managed shared infrastructure. If the enterprise customer requires customer-only addresses and dedicated proxy resources, use QuotaGuard Enterprise dedicated infrastructure.

How much does inbound proxy capability cost?

Direct QuotaGuard Static plans start at $19 per month and Shield plans start at $29 per month, with inbound proxy capability included on direct Starter plans and above. Dedicated Enterprise architecture is priced separately according to the required capacity and isolation.

Does a static destination replace API authentication?

No. Keep TLS, credentials, authorization, rate limits, logs, and other application security controls. The static address satisfies the customer's network destination requirement.