Database allow-listing
Connect applications, jobs, and administration tools to IP-restricted databases through a dedicated static public IP.
Add the assigned IP to the database access list once, then manage each connecting system as a separate peer.
Plans from $15/month.
Use WireGress when the database accepts connections through a public IPv4 address and your applications run across changing hosts, CI environments, offices, or clouds.
Atlas, managed PostgreSQL or MySQL, Redis, Elasticsearch, Snowflake, partner firewalls—any service that takes a public IPv4 in an access list. Not a native integration.
Use the provider's private endpoint, peering, or private-networking option when the application and database can connect privately and that architecture meets your requirements.
Create a peer for each application, runner, or administrative tool.
Route only the database prefixes, or send all outbound traffic if split routing is impractical.
Confirm that the connection exits through your assigned WireGress IP.
Add that IP to the database access list.
Revoke a peer when that system should no longer use the trusted route.
Important: IP allow-listing is not a substitute for TLS, database credentials, or least-privilege roles. Traffic is encrypted to the WireGress gateway; continue using the database service's TLS connection from the gateway to the service.
A static public IP is useful, but it is not the right answer for every database.
| Situation | Usually consider |
|---|---|
| Systems span clouds, offices, CI environments, or customer networks | A portable static egress IP such as WireGress |
| A partner accepts only a public IP and does not offer private connectivity | Dedicated egress with an IP allow-list |
| Application and database are in the same cloud and private connectivity is supported | Private endpoint, peering, or provider-native private networking |
| Policy prohibits database traffic over public networks, even when encrypted | A private connectivity design reviewed by your security team |
A practical fit for development, scheduled jobs, administrative access, and workloads that can tolerate a gateway interruption.
Review the Core plan →Better suited to production database connections where the egress identity must remain available through a WireGress gateway or facility failure.
Applications should still use sensible connection timeouts, retry logic, and connection-pool recovery. Network failover cannot preserve every existing database session.
Review the HA plan →Operated by APYL Inc.
ARIN Member since 2010 • AS53628 • 30+ years infrastructure experience • Operating production infrastructure for businesses worldwide
Create a dedicated egress gateway, connect the systems that need database access, and manage their peers from one dashboard.