An exported ZIP and a generated Blueprint are not yet a product. If the first clone reuses the production FQDN, source computer account, or a disk containing sensitive data, App Stack Formation has faithfully reproduced the problem. Real industrialization therefore starts after capture.
We begin with webshop-appstack-v1, produced in the previous article from ns-webshop-prod. The goal is to make WebShop Environment v1 requestable in prj-webshop-modern and deletable without affecting production. The promotion chain, version model, and cleanup controls below are a proposed operating model, not a procedure executed in a lab.
The source Namespace already belongs to All Apps: App Stack Formation does not convert a VM Apps deployment or replace any migration step.
TL;DR
- A capture becomes a product only when it regenerates identities and secrets, selects appropriate data, and supports a complete lifecycle through deletion.
- Publish to a sandbox project first; audience grows after startup, failure, Day-2, and cleanup evidence, never merely after provisioning succeeds.
- On Monday, define three separate versions — source state, technical Blueprint, and catalog release — and prohibit silent replacement of a consumed version.
Promote through evidence, not confidence
Broadcom documents Namespace capture and Blueprint distribution, but publication radius remains a governance decision. A capture derived from production should never enter a global catalog directly. It passes a four-party review, isolated clone, representative failure, and controlled deletion.
The review joins platform, application, security, and data owners. It looks for IPs, MACs, hostnames, certificates, private keys, tokens, service accounts, CMDB/DNS/IPAM/AD endpoints, backup destinations, broad firewall rules, and dependencies on an unavailable Region, VPC, or class. It covers both the Blueprint and captured disks: a secret absent from code can still exist inside an image.
Isolate the first clone
The first deployment should use a network with no route to production systems except explicitly approved temporary flows. A clone contacting PROD before its identities are replaced is an incident, not a successful test.
Customize intent, calculate infrastructure
The form should use consumer language: allowed environment, functional size, lifetime, data profile, and cost center. It should not expose raw VM Class, Storage Class, or subnet inventories. The platform derives those choices from project, Region, quota, and policy.
- environment: sandbox or integration according to rights;
- size: small or standard;
- data profile: empty, demo, or sanitized;
- lease within policy limits;
- change and cost center when governance requires them.
- allowed Namespace Class, VM Class, and Storage Class;
- dedicated or approved VPC and subnets;
- unique naming prefix and identifiers;
- generated secrets and approval path;
- observability, backup, and ownership labels.
This separation reuses the principle of dynamic Custom Forms rebuilt for All Apps: the user describes intent and the backend revalidates allowed values. A dynamic list is never a security boundary; provisioning must reject a class or project outside policy even if a request bypasses the form.
clone_profile:
environment: sandbox
namespace_name: generated
hostname_prefix: ws-sbx
size: standard
vpc_policy: dedicated-per-deployment
credentials: generated-in-approved-secret-store
data_source: sanitized-demo-snapshot
external_registration: sandbox-only
lease_days: 7Passwords never become form defaults. They are generated or referenced through an approved secret mechanism. A production dataset is not a demonstration convenience: a sanitized-demo profile has an owner, version, sanitization proof, and retention rule.
Deploy the clone and prove independence
The first request records request ID, deployment ID, Namespace, VPC, VMs, volumes, Blueprint version, non-sensitive parameters, events, and timestamps. This evidence connects an error to the correct layer instead of diagnosing only the last VM created.
The following four identities must change:
| Domain | Captured source | Expected clone |
|---|---|---|
| Namespace | ns-webshop-prod |
unique generated name |
| VMs and FQDNs | PROD names | deterministic request prefix |
| external systems | production CI, AD, and DNS | distinct sandbox objects or none |
| data | production dataset | empty, demo, or sanitized by policy |
The most revealing test is stopping the clone. If WebShop PROD loses a dependency, something was shared that should have been isolated. Also verify that no name, IP, or certificate collides, logs carry the clone’s project and Namespace, backup targets a sandbox destination, and the CMDB does not merge both CIs.
The official App Stack Formation 9.1 overview positions the stack as an operational unit, including actions such as start, stop, or snapshot. Exact actions, scope, and policy controls still require build verification. The expected test starts the database, waits for readiness, starts the application, waits for /readyz, and then makes Web healthy through /healthz. Shutdown reverses the order.
Inject a failure before widening the audience
A platform product is defined by errors as much as by its happy path. Make the Content Library temporarily unavailable, deny a secret, exhaust the Storage Class in a safe environment, or interrupt cleanup. For each injection, capture the user message, events, blocked resource, remediation, and any residue.
The clone contacts production
The stack starts in the wrong order
A Day-2 action disappears for the user
A new release breaks requests
Diagnosis must never “repair” the clone by changing ns-webshop-prod. The capture source remains protected. A declarative correction may be applied to the Blueprint and tested; a major or poorly understood drift normally calls for a new capture and review.
Test deletion as a product function
A clone’s success is not measured only at creation. After deletion, inspect the Namespace according to ownership, VMs, dedicated VPC and subnets, volumes/PVCs, DNS and IPAM records, AD accounts, CMDB CI, load-balancer membership, temporary secrets, and backups.
Classify every remainder as absent, retained, or orphan. A deliberately retained volume is not an orphan when owner, duration, cost, and destruction procedure are documented. Conversely, a “probably useful” resource with no owner is a cleanup failure.
delete_evidence_template:
evidence_status: expected-result
validation_requirements:
- timestamped-deletion-task
- post-deletion-inventory
- production-non-impact-check
expected_state:
namespace: absent
virtual_machines: absent
dedicated_vpc: absent
volumes: retained-with-data-owner-for-7-days
dns_ipam_ad_cmdb: absent
temporary_secrets: revoked
production_source_impact: none
execution_status: not-performedThis block describes the expected evidence format: this article performed no deletion. After testing, replace expected values with timestamped proof and a post-deletion inventory.
Version three different objects
A single v1 label is insufficient. Keep a tuple:
release_tuple:
capture_source: webshop-prod@2026-08-10T20:00Z
blueprint: webshop-appstack-v1.2
catalog_release: 1.0.0
audience: prj-webshop-modern
deprecated_after: 2026-11-10capture_source identifies the observed Namespace state. blueprint versions the technical artifact and customizations. catalog_release communicates a contract to consumers. Do not silently replace v1: publish v2, mark v1 deprecated, optionally stop its new requests, and let existing deployments follow their lifecycle.
For a major change in the running stack, recapture and repeat the entire chain. For a small declarative correction, patch the Blueprint and retest. For data-only changes, version data without recapturing infrastructure. For a new runtime, create a new product instead of disguising the break as a minor release.
Gradual publication and rollback
The first release remains scoped to prj-webshop-modern. Apply the required All Apps approval, lease, Day-2, and IaaS resource policies as appropriate, and configure quotas for the intended scope. Display owner, support path, estimated cost, limitations, version, and deprecation date. Global Catalog or broader sharing comes only after several observed lifecycles.
If the clone fails, limit or unpublish the release, retain the deployment for analysis when security permits, remove it through the supported lifecycle, inspect external systems, and restore the previous release. If sensitive data was cloned, deployment deletion may not be enough; backups and retention follow the customer’s incident process.
Conclusion
App Stack Formation accelerates the move from a stable service to a reusable artifact. Platform work then makes that artifact safe, understandable, observable, and deletable. Identity + data + Day-2 + deletion + version creates the product, not the Publish button.
Independence to prove
The clone must own its names, secrets, data, and external objects. Stopping it must have no effect on production.
Cleanup to prove
After testing, every remaining resource must be absent or retained with an owner and expiry; ambiguity is treated as a product defect.
Explicit versions
Source state, Blueprint, and catalog release evolve independently so consumed contracts never change invisibly.
Return to Namespace preflight and capture when the defect belongs to the source artifact. Once the release is operable, the final step is to drain, disable, and potentially delete the VM Apps organization.
Official sources: Capture a Namespace as a Blueprint · App Stack Formation 9.1 · Import or Export a Stateful Blueprint · Approval policies · Lease policies · Day-2 policies · IaaS resource policies.
Get the next one by email
New articles and series, sent when they are published. No other mail.
