Static outbound IPs for Laravel Cloud
Give selected API requests from Laravel Cloud a stable IPv4 source pair without moving your application or routing unrelated traffic through a proxy. QuotaGuard works at the HTTP-client boundary, so the integration that needs an allowlist can use it from a controller, queue worker, or scheduled task.
Keep the platform and simplify the API allowlist
When a partner accepts a small fixed set of source addresses, configure the Laravel HTTP client making those calls to use your QuotaGuard connection. The partner sees one of the two addresses assigned to your subscription. Register both addresses so either connection path can be accepted. Learn why both addresses matter.
The change stays focused on the integration. Unrelated requests retain their existing route, and your application’s inbound URL does not change.
Built around Laravel deployment behavior
The implementation guide covers the details that a generic PHP proxy example leaves to your application:
- Read the proxy URL through a Laravel configuration file so cached configuration behaves predictably.
- Link the secret to the intended Cloud environment, check overrides, and redeploy after changes.
- Reuse an explicit client factory in web requests and background jobs.
- Check deployed egress with an Artisan command, then verify the actual provider request path.
- Keep credentials out of IP probes, logs, browser code, and support screenshots.
Start with the Laravel Cloud technical guide, then use the runtime examples and troubleshooting reference during rollout.
Compare the native option
Laravel Cloud publishes regional outbound IP lists. Those may be sufficient if your provider accepts them and your team can maintain changes. Dedicated Private Cloud organizations have their own onboarding addresses.
QuotaGuard provides another route for selected requests when the assigned pair better fits your provider’s allowlist. Confirm the accepted source region and whether shared or account-exclusive addresses are required. Shared and dedicated proxies are different arrangements; choose the one your provider accepts.
Use the right transport
The reference Laravel factory uses QuotaGuard Static’s HTTP proxy. Requests to an HTTPS API retain destination TLS through CONNECT. If your application-to-proxy hop also requires TLS, review Shield with the actual PHP, cURL, and Guzzle configuration. Compare the two proxy hops.
This setup covers the HTTP requests you configure. An independent SDK, native database connection, browser request, or unrelated process needs its own supported configuration.
Configure the proxy for a specific API
Collect the connection URL and assigned addresses, configure one protected request path, and confirm the source from the deployed environment. Then extend the same approach to the workers and scheduled tasks that call that API.
Does setting the proxy URL route all requests through QuotaGuard?
No. The HTTP client must use the proxy setting. The guide uses a selected factory so the scope is visible in code.
Do queue workers need their own proxy settings?
Cloud workers share their environment’s variables. What matters is that their jobs construct the intended client and run the deployment with the updated configuration. Cloud worker behavior covers the platform details.
Is one successful IP check enough to confirm the setup?
It verifies that check’s observed route. Validate the actual provider paths too, and keep both addresses on the provider allowlist.
Guides and examples
- Technical guide
- Runtime examples
- Troubleshooting
- Operations runbook
- Downloadable examples and reference
Table of contents
- Laravel Cloud example code and offline checks
- Laravel Cloud runtime examples
- Manage static outbound API routing on Laravel Cloud
- Static outbound IPs for selected Laravel Cloud API calls
- Troubleshoot Laravel Cloud API allowlisting