Connect a source

Portward reads each source where it is, with a login that can only read, and never writes to it. The gateway turns the values your admin marks as sensitive into tokens before the AI sees them, and records every answer in your cloud.

Each database has its own page with the exact grants to run. Files and business apps have a page each. Get started, step 8 walks through connecting one from the chat.

Source, as setup names it	Page	What setup asks for
PostgreSQL	PostgreSQL	Host, database, a read-only login
MySQL	MySQL	Host, database, a read-only login
SQL Server	SQL Server	Host, database, a read-only login
Oracle	Oracle	Host, service name, the tables’ schema, a read-only user
Snowflake	Snowflake	Account, warehouse, database, schema, a service user’s key
Google BigQuery	Google BigQuery	Project, dataset, a service account
Amazon Redshift	Amazon Redshift	Endpoint, database, schema, a read-only user or IAM
Databricks SQL	Databricks SQL	Workspace host, SQL warehouse, catalog, schema, a service principal
Amazon S3, Google Cloud Storage, Azure Blob Storage and Data Lake Gen2	File stores	Bucket or container, folder, a read-only key
Microsoft 365 (OneDrive), SharePoint document library, Google Drive	File stores	A Microsoft or Google sign-in, and a folder
HubSpot, Salesforce	Business apps	A read-only key or app

Files can be Parquet, CSV or Excel (.xlsx, the first sheet), and Google Sheets in Drive.

Allow the host

The gateway makes tokens inside each database, so it sends its token key to that database. That is why setup connects only to database hosts the gateway’s operator has allowed, in setup_hosts. Where to change it:

• AWS: the stack’s Database hosts parameter (Install on AWS).
• Azure: setup_hosts in the VM’s portward.toml (Install on Azure).
• Google Cloud: setup_hosts in your Terraform values (Install on Google Cloud).
• Your own server: setup_hosts in portward.toml (the install guide).

Rules for the list:

• A host on a domain other companies share needs its exact name, never a wildcard. That covers Amazon RDS, Aurora and Redshift endpoints (*.amazonaws.com) and Databricks workspaces. A wildcard there would let anyone’s database on that domain receive your token key.
• Snowflake needs your account’s host, such as orgname-accountname.snowflakecomputing.com.
• An S3-compatible or Azure storage endpoint you type in setup needs its host on the list.
• Amazon S3, Google Cloud Storage and Azure Blob Storage on their own endpoints, BigQuery, Microsoft 365 and Google Drive need no entry.

When you take a host off the list and restart the gateway, the connections to that host stop.

Network access

The gateway connects out to each source. Nothing connects in to the gateway from your sources.

• AWS. The gateway runs as an ECS task in the VPC and subnets you chose. On the database’s security group, allow its port from the gateway’s security group (its description starts with “Portward gateway”). That works when the database is in the same VPC or a peered one. If the database is only reachable over the internet with an address allow-list, put the gateway in private subnets behind a NAT gateway and allow the NAT gateway’s Elastic IP. The task’s own public IP changes each time the task restarts.
• Azure. The VM sits in portward-vnet (10.40.0.0/24). Peer that network with your database’s network, or allow the VM’s static public IP, portward-ip, in the database server’s firewall.
• Google Cloud. The machine runs in its own network unless you give a subnetwork. To reach a database by its public address, allow the machine’s external IP. With your own domain that address is static (<name>-ip); with the relay it can change when the machine is replaced.
• Your own server. Allow the server’s address on the database’s firewall.

Encryption in transit

Every connection to a host that isn’t on the gateway’s own machine uses TLS, and the gateway always checks the server’s certificate and host name. There is no “encrypt but don’t verify” option. The certificate is checked against, in this order:

1. The server CA certificate pasted in setup’s optional Server CA certificate (PEM) field, if there is one. Only that CA is trusted for that connection. Use it for a company CA or Google Cloud SQL’s server CA.
2. For Amazon RDS and Aurora hosts (*.rds.amazonaws.com), Amazon’s RDS CA bundle for every region. The bundle ships with the gateway. The public roots are trusted too, because RDS Proxy endpoints use public certificates.
3. The public CA roots, as a browser would.

A pasted CA must be PEM certificates (-----BEGIN CERTIFICATE-----), at most 64 KB and 20 certificates. Setup refuses a paste that holds a private key and drops any text around the certificates. The CA is never logged.

Query time limits

Each query has a time limit that the source itself enforces. Databases, files and business apps get 5 seconds (timeout_ms in the gateway’s [gateway] settings). Snowflake, BigQuery, Redshift and Databricks get 60 seconds (warehouse_timeout_ms), because a warehouse may queue the query or start up from suspended first. A source in the config file may set its own timeout_ms. Each limit is between 100 ms and 15 minutes.

What setup checks before it saves

Setup tests the connection before it saves anything. For a database it signs in with the login you gave, refuses a login that is an administrator or can change the tables, and lists the tables the login can read. For every database but PostgreSQL, it also checks that a token computed inside the database matches the gateway’s own. Tables the login could change are listed but can’t be exposed to the AI. Each page says exactly what its check tests and what it says when it refuses.