The cloud accounts, production footing, data, and secrets stay under the client's ownership.
→Development To Production
Whirlwind Delivery Model
A deployable AWS foundation for a full software product.
Whirlwind creates a client-owned AWS foundation for a full software product: development, staging, production, access, DNS, certificates, and runtime infrastructure deployed through Terragrunt.
Whirlwind gives the product a concrete operating shape: owned cloud accounts, separate environments, public and private routes, runtime infrastructure, and evidence that future contributors can inspect.
What Whirlwind Creates
Client AWS accounts become a usable product platform.
Terragrunt creates the account, environment, access, DNS, certificate, and runtime infrastructure.
→The software product gets development, staging, production, public routes, private administration, and a repeatable delivery path.
Whirlwind In Plain Terms
A plain-language overview of how work moves from build to launch.
1 / 5
What It Is
A client-owned AWS foundation for a full software product.
Whirlwind creates the cloud footing around the product.
The setup is deployed into the client's AWS accounts with Terragrunt. It gives the application defined environments, access, DNS, certificates, and runtime infrastructure.
- The client owns the accounts and production footing.
- Infrastructure is created from code.
- The product gets a clear operating path.
Client AWS
Accounts, data, secrets, and production stay with the client.
Terragrunt
Infrastructure is deployed through repeatable code.
Runtime
The application gets a defined place to operate.
Access
Administration has a planned route.
The Environment Path
Development, staging, and production each have a job.
The team can build, check, and launch without mixing environments.
Development is for building. Staging is for release checks. Production is where users depend on the product.
- Development work stays away from live users.
- Release checks happen before production.
- Production has its own controls.
Development
A place for active product work.
Staging
A place to validate releases.
Production
The live product environment.
Admin
A controlled administration path.
Public And Private Routes
Users and administrators need different exposure.
The product can be public while administration stays controlled.
Whirlwind plans user-facing routes and operator routes as separate concerns. DNS, certificates, and access rules are part of the same setup.
- Public URLs serve the product.
- Admin URLs stay on the operator path.
- Routes are checked before publication.
Users
Website, portal, API, or dashboard access.
Operators
Admin access follows a controlled route.
Certificates
Service URLs get planned certificate handling.
Validation
Routes are tested before use.
Product Boundary
One setup serves one coherent product domain.
Related surfaces share one foundation.
A website, portal, API, dashboard, mobile app, and admin surface can share Whirlwind when they belong to the same backend, data model, auth surface, and operating path.
- The product has a clear infrastructure boundary.
- Related surfaces can share the same runtime footing.
- Ownership and evidence stay easier to inspect.
Backend
The shared product logic and data model.
Identity
The access surface that belongs to the product.
Runtime
The application infrastructure.
Surfaces
Web, mobile, API, portal, and admin.
How It Stays Inspectable
The delivery path leaves records.
The important parts are encoded and reviewable.
Infrastructure, runtime configuration, endpoint publication, and operator access are handled through code and delivery workflows.
- Plans and applies can be reviewed.
- Runtime setup follows automation.
- DNS and certificates can be checked.
Terraform
Infrastructure is declared in files.
Terraform Cloud
Changes leave plan and apply history.
Ansible
Runtime setup follows automation.
Checks
Routes and certificates are verified.
What It Is1/6
A client-owned AWS foundation.
Whirlwind creates the infrastructure around a full software product in the client's AWS accounts.
- Development, staging, and production are created.
- Access, DNS, certificates, and runtime are included.
- The setup is deployed through Terragrunt.
Ownership2/6
The client keeps the cloud footing.
The AWS accounts, data, secrets, and production environment stay under the client's ownership.
- Infrastructure is created from code.
- Delivery leaves reviewable records.
- Future contributors can inspect the setup.
The Path3/6
Development, staging, and production each have a job.
Development is for building. Staging is for checks. Production is where users depend on the product.
- Build in development.
- Check releases in staging.
- Run the live system in production.
Access4/6
Public product, private administration.
User-facing routes and operator routes are planned as separate paths.
- Public URLs serve users.
- Admin URLs stay controlled.
- DNS and certificates are handled in the platform path.
Boundary5/6
One setup serves one product domain.
Related user surfaces can share the same foundation when they belong to the same backend, data model, auth surface, and operating path.
- Web, mobile, API, portal, and admin can share one setup.
- Runtime, data, access, and evidence stay in one boundary.
- The product remains easier to explain as it grows.
Proof6/6
The important parts are inspectable.
Terraform, Terragrunt, Terraform Cloud, Ansible, DNS checks, and operator-access tooling leave a visible delivery path.
- Plans and applies can be reviewed.
- Runtime setup follows automation.
- Routes and certificates can be checked.
1 / 6
What The Platform Gives The Client
Owned infrastructure, clear environments, controlled access, and visible delivery.
The client keeps ownership of the AWS accounts and production footing. Whirlwind supplies the operating structure around the application.
Client-Owned Cloud
The AWS accounts, data, secrets, and production environment stay under the client's ownership.
Real Environments
Development, staging, and production each have a clear role in the delivery path.
Controlled Administration
Public product access and private operator access are planned as separate routes.
Inspectable Delivery
Infrastructure, runtime setup, publication, and checks leave records the client can review.
Operating Path
One route from build work to live operation.
Build in development. Check in staging. Run in production. Administer through a controlled operator path.
BuildDevelopment
CheckStaging
LaunchProduction
OperateControlled administration
Product Boundary
One setup is scoped around one coherent product domain.
Web, mobile, API, portal, and admin surfaces can share the same foundation when they belong to the same backend, data model, auth surface, and operating path.
One Product Domainbackend, data, auth, runtime, delivery controls
WebsitePortalAPIAdminMobile
Automated Setup And Evidence
The important parts are encoded and inspectable.
Infrastructure, runtime configuration, access, publication, and validation are handled through code and delivery workflows.
- 1Cloud Footing
- 2Access
- 3Runtime
- 4Environments
- 5Web Addresses
- 6Application Runtime
- 7Publication
Terraform and Terragrunt define the AWS infrastructure.
GitHub Actions and Terraform Cloud record plans and applies.
Ansible handles runtime configuration.
DNS and certificate checks validate routes before publication.
Operator-access tooling keeps administration on a controlled path.