This guide walks you through setting up PTD to deploy Posit Team products on AWS or Azure.
| Tool | Version | Description |
|---|---|---|
| Go | 1.21+ | For building the CLI |
| Python | 3.12+ | For Pulumi IaC |
| uv | Latest | Python package manager |
| Pulumi | 3.x | Infrastructure as Code |
| just | Latest | Command runner |
| goreleaser | Latest | For building releases |
For AWS:
- AWS CLI v2
- AWS Session Manager Plugin
- AWS credentials configured (via
aws configureor environment variables) - Route 53 hosted zone for your deployment domain (e.g.,
example.posit.team). PTD uses ExternalDNS to manage DNS records automatically, and it requires an existing hosted zone in the target AWS account. Create one in the Route 53 console before runningptd ensure. admin.posit.teamIAM role deployed to each AWS account PTD will manage. Seeptd admin generate-roleand IAM Permissions for details.
For Azure:
- Azure CLI
- Azure credentials configured (via
az login)
git clone https://github.com/posit-dev/ptd.git
cd ptdjust depsThis installs:
- Python dependencies via uv
- Go dependencies
- Required CLI tools symlinked to
.local/bin/
just cliThe CLI binary is created at .local/bin/ptd.
Copy and edit the account configuration:
cp accounts.env.example accounts.env
# Edit accounts.env with your AWS account IDsThis step is optional - PTD can auto-detect your AWS account via STS.
PTD organizes deployments into "targets" - either control rooms or workloads.
mkdir -p my-infrastructure/__ctrl__/my-control-room
mkdir -p my-infrastructure/__work__/my-workload# Copy control room example
cp examples/control-room/ptd.yaml my-infrastructure/__ctrl__/my-control-room/
# Copy workload example
cp -r examples/workload/* my-infrastructure/__work__/my-workload/Edit the configuration files with your actual values:
Control Room (my-infrastructure/__ctrl__/my-control-room/ptd.yaml):
- AWS account ID
- Domain names
- Trusted principals (users who can manage)
Workload (my-infrastructure/__work__/my-workload/ptd.yaml):
- AWS account ID
- Control room reference
- Cluster configuration
- Site domains
Site (my-infrastructure/__work__/my-workload/site_main/site.yaml):
- Authentication (OIDC/SAML) configuration
- Product versions
- Replicas and scaling
Tell PTD where your configurations are:
# Option 1: Environment variable
export PTD_TARGETS_CONFIG_DIR=/path/to/my-infrastructure
# Option 2: Config file (~/.config/ptd/ptdconfig.yaml)
echo "targets_config_dir: /path/to/my-infrastructure" > ~/.config/ptd/ptdconfig.yaml
# Option 3: CLI flag (per-command)
ptd --targets-config-dir /path/to/my-infrastructure <command># Deploy the control room first
ptd ensure my-control-room
# Then deploy the workload
ptd ensure my-workloadNote: For workloads, the first step (
bootstrap) creates the Pulumi state backend (S3 bucket and KMS key on AWS, storage account on Azure) and initializes secrets. If you use--start-at-stepor--only-stepsto skip bootstrap on a fresh deployment, subsequent steps will fail because the state backend does not exist. Use-v(verbose) to see the expected resource names if you encounter state backend errors. See Ensure Command Flow for details on each step.
PTD deployments consist of:
Organization
├── Control Room (1 per org)
│ ├── EKS cluster
│ ├── DNS management
│ └── Shared services
│
└── Workloads (1+ per org)
├── AWS Infrastructure
│ ├── VPC
│ ├── EKS cluster(s)
│ ├── RDS PostgreSQL
│ └── FSx for OpenZFS
│
└── Sites (1+ per workload)
├── Workbench
├── Connect
└── Package Manager
# Start a proxy to the cluster
ptd proxy my-workload
# In another terminal, use kubectl
export KUBECONFIG=./kubeconfig
kubectl get pods -Aptd workon my-workloadEdit the configuration files, then re-run:
ptd ensure my-workload- Configuration Reference - Detailed configuration options
- CLI Reference - All CLI commands
- Examples - More example configurations