Prefer Terraform? Open the “Add connection” page in the Trigger.dev dashboard and use the
Terraform wizard to generate a ready-to-apply script. The wizard creates everything described
below and pre-fills our AWS account ID for you.
Prerequisites
Before you start you’ll need:- An AWS account with permission to create VPC, EC2, and ELB resources
- A resource in a VPC subnet that you want to expose (RDS instance, ElastiCache cluster, internal API, etc.)
- The Trigger.dev AWS account ID — find this on the “Add connection” page in your Trigger.dev dashboard, in the “I have my details” or “Step-by-step guide” cards
- A VPC that contains the resource, with at least one private subnet per Availability Zone you want to serve from
PrivateLink connections are zonal. If your resource lives in a single AZ, your connection will
only be available from that AZ. For higher availability, ensure target groups can route to
multiple AZs.
Step 1: Create a target group pointing at your resource
The target group is how the NLB will know where to forward traffic. AWS requires a target group when creating a load balancer, so we’ll set this up first.Choose a target type
- IP addresses for RDS, ElastiCache, or any resource you can reach by IP
- Instances for EC2 instances you own
- Application Load Balancer if your resource sits behind an ALB
Configure the target group
-
Name: e.g.
trigger-postgres-tg - Protocol: TCP
- Port: the port your resource listens on (5432 for Postgres, 6379 for Redis, 3306 for MySQL, etc.)
- VPC: the VPC where your resource lives (this must match the VPC you’ll use for the NLB)
-
Health check protocol: TCP

Register your targets
Add the IP addresses of the resource. For RDS, look up the writer endpoint’s IPs (
dig <endpoint> from inside the VPC).
For ElastiCache, use the primary endpoint IPs.
Step 2: Create an internal Network Load Balancer
The NLB is what PrivateLink exposes to Trigger.dev. It must be internal (not internet-facing).Open the EC2 console
Go to EC2 → Load Balancers → Create load balancer and choose Network Load Balancer.
Configure the basics
-
Name: something descriptive, e.g.
trigger-postgres-nlb - Scheme: Internal
-
IP address type: IPv4

Choose VPC and subnets
Pick the same VPC as your target group. Select one private subnet per AZ that should serve traffic.
Each subnet you select adds an availability zone to the endpoint.

Add a TCP listener forwarding to your target group
Under Listeners and routing, configure:
- Protocol: TCP
- Port: same as your target group port (5432 for Postgres, 6379 for Redis, etc.)
-
Default action: forward to the target group you created in Step 1

Step 3: Create a VPC Endpoint Service
This is the resource that PrivateLink consumers connect to.Confirm the NLB from Step 2 is in the Active state before starting this step. It won’t appear
in the Available load balancers dropdown until it has finished provisioning.
Configure the endpoint service
-
Name: optional, but useful for identification, e.g.
trigger-postgres-endpoint - Load balancer type: Network
- Available load balancers: select the NLB you created
-
Require acceptance for endpoint: No (recommended)

If you set “Require acceptance” to Yes, every connection request from Trigger.dev will
sit in a pending state until you manually approve it. Setting it to No lets connections
come up automatically once the principal is allow-listed.
Skip private DNS
Leave the “Private DNS name” option disabled. Trigger.dev tasks dial the endpoint by its
private IP, so private DNS isn’t needed.
Configure cross-region access (optional)
If your Trigger.dev tasks run in a different AWS region from your endpoint service, expand
the Supported Regions section and add the region(s) where Trigger.dev should be allowed to
create the VPC Endpoint from (for example, add
eu-central-1 if your service is in
us-east-1 but tasks run in eu-central-1).If your tasks and resource are in the same region, you can skip this — same-region access is
enabled by default.Cross-region PrivateLink adds AWS data-transfer cost and ~10–30ms of latency depending on the
region pair. Prefer same-region when possible.
Step 4: Authorize the Trigger.dev AWS account
By default, no one can connect to your endpoint service. You need to explicitly allow Trigger.dev’s AWS account.Add Trigger.dev's account
Paste the principal ARN in this format, replacing 
<account-id> with the Trigger.dev AWS
account ID shown in your dashboard:
Click Allow principals
The principal is now authorized to create a VPC Endpoint targeting your service.
Step 5: Add the connection in Trigger.dev
Open the dashboard
In Trigger.dev, go to Organization Settings → Private Connections and click Add
connection.
Pick the I have my details card
Then fill in:
- Friendly name: a short, human-readable label for this connection.
- VPC Endpoint Service name: paste the
com.amazonaws.vpce.<region>.vpce-svc-...value from Step 4. - Target region: the AWS region your endpoint service lives in.
Submit
Submit the form. The connection’s status moves through Pending → Provisioning → Active.
Provisioning typically takes 30–90 seconds.


