Connect over the internet with IP allowlisting

✦TL;DR

The fastest path to connect Atlan to PostgreSQL - Atlan connects to your database's public endpoint over TLS, and you allowlist Atlan's fixed egress IPs. Five phases, each labeled with who performs it.

||

|Connect

The fastest path: Atlan connects to your database's public endpoint over TLS, and you allowlist Atlan's fixed egress IPs. Five phases, each labeled with who performs it.

New to this?

Read How database connectivity works first (5 minutes). It explains the three gates - firewall, pg_hba.conf, authentication - that this guide configures one by one.

Prerequisites

• Your database has a public endpoint (RDS "publicly accessible", a public listener, or a routable address) on port 5432 or another port you know.
• Someone who can create database users and grants (your Postgres admin).
• Someone who can edit the firewall/security group (your cloud/network team) - may be the same person.

Five phases at glance

Phase	What happens	Owner	Typical time
1. Create the user	Service user + read grants in PostgreSQL	Postgres admin	15 minutes
2. Get Atlan's IPs	Request your tenant's egress IPs	Atlan User + Atlan support	1 business day
3. Open the firewall	Inbound rule for Atlan's IPs on your port	Your cloud/network team	15 minutes
4. Configure pg_hba and SSL	Make sure PostgreSQL itself accepts the connection	Postgres admin	15 minutes
5. Connect and verify	Create the connection in Atlan and test	Atlan User	15 minutes

Phase 1 - Create service user and grants

Owner: Postgres admin

From Set up PostgreSQL - create a dedicated user and grant it read access to the metadata you want cataloged:

CREATE USER atlan_user PASSWORD '<strong-password>';
-- Minimum: schema access, so INFORMATION_SCHEMA metadata can be fetched
GRANT USAGE ON SCHEMA <schema> TO atlan_user_role;
-- Optional, for sample-data preview in Atlan:
GRANT SELECT, REFERENCES ON ALL TABLES IN SCHEMA <schema> TO atlan_user_role;
GRANT atlan_user_role TO atlan_user;

Repeat the grants for each database and schema you want to crawl - a connection sees one database at a time.

Planning to use the miner (lineage from query history)?

Have the admin also enable the query-history extension now - it needs a server restart on self-managed servers (on RDS/Aurora it's a parameter-group change):

CREATE EXTENSION IF NOT EXISTS pg_stat_statements; then GRANT pg_read_all_stats TO atlan_user;

Skipping this is a recurring cause of miner preflight failures - see troubleshooting.

Phase 2 - Get your tenant's egress IPs

Owner: Atlan User + Atlan support

Raise a support request from within Atlan with your tenant URL: "Please share the public egress (NAT) IPs for my tenant, for allowlisting a PostgreSQL source." Values are tenant-specific - don't reuse IPs from another tenant or an old ticket. See Atlan Network Details for what else to ask for in the same request.

QA and production tenants have different IPs

If you run more than one Atlan tenant (for example, a QA instance), each has its own egress IPs. A real support pattern: production connections fine, QA connections all timing out - because only production's IPs were allowlisted. Ask for the IPs of every tenant that will connect.

Phase 3 - Open firewall

Owner: Your cloud/network team

• AWS RDS/Aurora: add an inbound rule to the database's security group - source = Atlan's egress IPs, port = 5432 (or yours), protocol TCP. The instance must be "publicly accessible" for the internet path.
• Azure Database for PostgreSQL: add Atlan's IPs under Networking → Firewall rules.
• Self-managed / on-prem: open the port on every firewall between the internet and the server. If a proxy or load balancer sits in front, it must forward the PostgreSQL port - see Special cases for the reverse-proxy pattern.

Phase 4 - Configure pg_hba.conf and SSL

Owner: Postgres admin

Gate 2. Even with the firewall open, PostgreSQL itself must accept the connection:

# TYPE   DATABASE      USER         ADDRESS            METHOD
hostssl  analytics     atlan_user   203.0.113.10/32    scram-sha-256
hostssl  analytics     atlan_user   203.0.113.11/32    scram-sha-256
# hostssl = SSL required. Place these BEFORE any broader reject/catch-all rules.

• Self-managed: add a rule per Atlan IP (or the CIDR support gave you), for the right database and user, then reload PostgreSQL. Rule order matters - the first matching rule wins.
• RDS/Aurora: you can't edit pg_hba.conf; AWS manages it. What you control is the parameter group - notably rds.force_ssl (when 1, all connections must use SSL) - and the authentication method per user (password vs. rds_iam).
• Decide your SSL stance now. If the server requires SSL (a hostssl rule or rds.force_ssl=1), the Atlan connection must be configured with SSL mode require or stricter in Phase 5. Mismatch here is the single most ticketed failure.
• If the user authenticates via PAM/LDAP rather than a normal database password, verify that stack accepts non-interactive service accounts - or switch this user to scram-sha-256, which is cleaner for service accounts.

Phase 5 - Connect and verify

Owner: Atlan User

1. In Atlan, open New workflow → PostgreSQL Assets and choose Direct extraction.
2. Enter Host (the database's DNS hostname - prefer it over a raw IP, which can change on restart), Port, Database, and your credentials. Auth options per Crawl PostgreSQL: Basic (username/password), IAM User (AWS access key + secret + database username), or IAM Role (AWS Role ARN + database username + optional External ID).
3. Set the SSL mode to match Phase 4 (see the caution below).
4. Click Test connection, then run the preflight checks when configuring the crawler.

If you can't find an SSL setting

The connector has historically defaulted to a permissive SSL mode with no obvious field in the setup form, causing rejections against SSL-required servers. If your server requires SSL and you don't see an SSL mode field in your tenant's form, raise a support ticket and ask for the connection's sslmode to be set to require - reference "PostgreSQL sslmode configuration."

Success checklist

• Test connection passes in the Atlan UI
• Preflight checks pass when you configure the crawler
• A crawl scoped to one small schema completes
• A full crawl (and miner run, if configured) completes on schedule at least once

All green? You're done. Any step failing - see Troubleshooting PostgreSQL connectivity.

Next steps

Crawl PostgreSQL: Configure and run the crawler to extract metadata from PostgreSQL