Step 4 of 4 - Deploy

From validated canvas
to live infrastructure.

When your architecture has passed simulation and cost review, deploy it directly to AWS from the pinpole canvas. A secure, four-step guided workflow - no long-lived credentials stored, every action logged.

Start deploying Deployment guide →
Pro, Team & Enterprise · MFA required · AWS STS AssumeRole · No long-lived credentials · Full audit log
prod-api-architecture.ppl - Deploy to Cloud
Pro plan
1
Connect IAM setup
2
Review Infrastructure plan
3
Deploy Provision
4
Live Confirm
MFA is required for deployments
Enable Google Authenticator MFA from Settings before continuing.
Open Settings
🛡
Secure Cross-Account Access
We use IAM Role assumption with STS. A CloudFormation stack creates a least-privilege role in your account. No secrets are stored - only temporary session credentials are used.
US East (N. Virginia) - us-east-1
Generate IAM Setup

Four steps.
No guesswork.

Every deployment follows the same guided flow. Review before anything is provisioned. Approve only when you're ready. The deployment history captures a full architecture snapshot at every step.

01
Connect your AWS account
Link your target AWS account using IAM Role assumption via STS. pinpole generates a CloudFormation stack that creates a least-privilege role in your account. No long-lived credentials are stored - only temporary session credentials are used for the duration of the deployment. Select your target deploy region at this step.
🔒 No secrets stored
02
Review the infrastructure plan
Inspect the generated infrastructure plan before any resources are created. Verify that services, configurations, and connections match your validated canvas. This is the final gate before infrastructure is provisioned - do not skip it.
03
Approve and provision
One-click deploy triggers the STS AssumeRole credential workflow. Monitor provisioning progress live in the deploy panel. No secrets leave your browser session.
04
Confirm live and monitor
Deployment status updates in real time. Success and failure states are logged to execution history with a full architecture snapshot at the moment of deployment. The deployed state is linked to the simulation run that validated it.
IaC export Terraform · CDK
Prefer to deploy through your own pipeline? Export Terraform HCL or AWS CDK from any canvas state - before or after simulation. The export reflects the exact canvas configuration at the moment of export, including any changes applied from recommendations.
main.tf variables.tf stack.ts (CDK)
IaC export guide →
Security model
pinpole uses AWS STS AssumeRole for cross-account access. No IAM access keys are stored. No long-lived credentials are transmitted or persisted anywhere. The IAM role configuration is documented in full in the deployment guide.
Deployment guide →
Execution history
Every simulation and deployment is captured in execution history with a full architecture snapshot. Compare any two states side by side, or roll back to any prior canvas configuration with one click.

No credentials stored.
Ever.

Deployments are a security-sensitive operation. pinpole's security model is designed so that no long-lived credentials enter or leave the platform at any point.

🔐
STS cross-account IAM
pinpole uses AWS STS AssumeRole for all deployments. A CloudFormation stack creates a least-privilege IAM role in your account. pinpole assumes that role for the duration of the deployment - no secrets leave your account.
✓ No long-lived credentials
🛡️
MFA enforced on all deployments
Multi-factor authentication via Google Authenticator is required before any deployment can be initiated. This requirement applies to all deployment targets - development, staging, and production environments.
✓ MFA enforced
📋
Full audit trail
Every deployment action - connect, review, approve, provision - is captured in the audit trail with a timestamp and the architecture snapshot at that moment. Full traceability from canvas state to live infrastructure.
✓ Immutable audit log

Deploy to ST, UAT, or Production.
In that order.

Multi-environment configuration is set once per workspace. pinpole enforces a deployment path that protects production - validate in lower environments before promoting.

ST - System Test
First deployment target
System Test is the first environment to receive a new architecture deployment. Confirms the architecture provisions and operates correctly in a real AWS account before UAT.
Always deploy here before promoting →
UAT - User Acceptance Test
Validation before production
UAT validates the architecture behaves as intended under acceptance conditions. The simulation run number used for the deployment is recorded here, creating a traceable link between validated state and live infrastructure.
Record simulation run number at this stage →
Production
Final promotion target
Production deployments require confirmation of successful ST and UAT runs. The review step in the four-step workflow is mandatory - it confirms the generated plan matches your validated canvas intent at the IaC level.
Review step is mandatory, no exceptions →

Your pipeline.
Your Terraform.

If your organisation deploys through Terraform or CDK pipelines, export the architecture definition at any canvas state and integrate it into your existing workflow.

Export at any canvas state - before or after simulation.

The IaC export reflects the exact canvas configuration at the moment of export, including any configuration changes applied from recommendations. Use it as an additional review layer, or as your primary deployment path.

Export provides an architecture definition compatible with Terraform and CDK. Full Terraform HCL code generation is planned for Phase 1 of the product roadmap (Q2–Q3 2026).

IaC export documentation →
.tf
Terraform HCL
Architecture definition - full HCL generation in roadmap
main.tf variables.tf
.ts
AWS CDK
TypeScript stack compatible with CDK v2 pipelines
stack.ts
soon
Pulumi
TypeScript / Python - planned roadmap item
index.ts

Every deployment linked to the simulation that validated it.

Execution history captures a full architecture snapshot at every simulation run and deployment. Compare any two states side by side, roll back to a prior canvas configuration, or trace a live deployment back to the exact simulation run that cleared it.

Execution history docs →
Execution history - prod-api-architecture live
14:32:07 Deploy complete - us-east-1, 12 resources provisioned success
14:29:44 Deploy approved - infrastructure plan reviewed approved
14:27:11 Plan generated - 12 create, 0 destroy, 2 update review
14:24:58 IAM connected - STS session established, us-east-1 connected
14:18:30 Simulation #47 passed - Spike 1K RPS, 0 alerts sim pass
13:52:14 Recommendation applied - provisioned concurrency enabled config

Deploy with
confidence.

The four steps are a framework, not a formality. These practices make the difference between a smooth promotion and a production incident.

01
Always review the infrastructure plan in Step 2
Do not skip the review step, even for architectures you have reviewed extensively on the canvas. The review step confirms that the generated plan matches your intent at the IaC level - it catches discrepancies before resources are provisioned.
02
Deploy to non-production environments first
Use ST (System Test) or UAT before targeting Production. This validates that the architecture behaves in a real AWS account before it handles production traffic. Simulation is not a substitute for a real environment run.
03
Record the simulation run number before deploying
Note the simulation run number that corresponds to the architecture you are deploying. This creates a traceable link between the validated simulation state and the live infrastructure - essential for post-deployment debugging and rollback decisions.
04
Confirm region settings before deploying
Verify that the deploy region selected in Step 1 matches your canvas endpoint configuration. A region mismatch at deploy time is one of the most common sources of post-deployment routing issues.
05
Use Export before deploying if your org uses Terraform or CDK
If your organisation uses Terraform or CDK as standard IaC tooling, export the architecture definition before or instead of direct deployment. The exported definition integrates with existing pipelines and provides an additional review layer before provisioning.
06
Apply recommendations one at a time before deploying
When multiple recommendations are available, apply them one at a time and re-simulate between each. Batch-applying all recommendations obscures which changes had the most impact, making post-deployment debugging harder.

Design. Simulate. Optimise.
Deploy.

The full workflow - canvas design, traffic simulation at up to 100M RPS, live cost estimation, and direct deployment to AWS - in one product. Start free, deploy when you're ready.

Start free Deployment documentation → Pro plan required for deployment · Free 14-day trial