- The Deployments page is where a consumer lives after they request something: change it, troubleshoot it, resize it, or destroy it. Deployment cards for a few, the deployment list and resource list when there are many.
- Day-2 actions run from the Actions menu on a deployment or a component resource. What appears depends on the resource type, the namespace, and the day-2 policy that applies to the user.
- The lease trap: when a lease expires the deployment is powered off and then destroyed, and a powered-off machine cannot be powered back on until the lease is extended. This drives a real share of support tickets.
- Consumers also see utilization (CPU and memory) for VMs and VKS clusters, which is the data that makes right-sizing a conversation instead of a guess.
- My recommendation: scope day-2 policies tightly, default leases short with easy extension, and teach teams to drive routine day-2 from the API so the console is not the only path.
A developer pings you on a Monday: their app VM will not power on, and nothing is broken. The deployment lease expired over the weekend, the VM was powered off, and in VCF Automation a powered-off machine cannot be powered back on until the lease is extended. That single rule explains a surprising share of day-2 tickets. It is a feature, not a bug, and once you understand the Deployments page and the policies behind it, most of those tickets stop reaching you at all.
The Deployments page is the consumer's whole world
Provisioning is a moment; the deployment is the relationship. After a user requests a catalog item, everything they do next happens on the Deployments page: making changes, troubleshooting a failed deployment, modifying the resources inside it, and destroying it when it is no longer needed. A deployment is the unit they own, and it can contain one machine or a whole application topology of VMs, networks and load balancers.
VCF Automation gives two ways to look at the same thing. Deployment cards are a graphical view that works when a user manages a handful of deployments. Once the count grows, the deployment list and the resource list give a denser, more workable view, letting someone act across many deployments or drill into individual resources without clicking through cards. The distinction matters more than it sounds: a power user drowning in cards is a sign you should be pointing them at the list view, or at the API.
What a consumer can actually do
Day-2 actions are the verbs of the Deployments page. A user opens the Actions menu on a deployment, or on a component resource inside it, and runs an action to modify or manage what they own. The set that appears is not fixed. It depends on the resource type, whether the action is supported on that namespace, and the day-2 policy that applies to that user. That last point is the governance seam: the policy is what decides whether a junior developer can resize a machine or only power it on and off.
| Action | What it does | Typical gate |
|---|---|---|
| Power on / off | Start or stop machines in the deployment | Day-2 policy |
| Change / resize | Adjust CPU, memory, disk or deployment inputs | Day-2 policy + project quota |
| Change lease | Extend or shorten the deployment lifetime | Lease policy |
| Change project | Move deployment ownership to another project | Day-2 policy |
| Delete / destroy | Reclaim every resource in the deployment | Day-2 policy |
The lease trap, and why it is on purpose
A lease policy defines the maximum time a deployment can exist. When the lease expires, the deployment is destroyed and its resources are reclaimed. Before that, there is the behavior that catches everyone: a powered-off machine cannot be powered back on unless the lease is extended. The platform is doing exactly what you asked it to do, which is to stop idle and abandoned workloads from holding capacity forever. The friction is the point. Capacity that is never reclaimed is the most common way a self-service platform quietly runs out of room.
How to keep the trap from generating tickets
Set leases short by default and make extension trivial and self-service, so the path of least resistance is to keep a deployment alive deliberately rather than by accident. Make sure expiry notifications actually reach the owner, not a shared mailbox nobody reads. And put the Change Lease action in the day-2 policy for the people who own deployments, so they can extend without opening a ticket. The mistake teams make is setting long default leases to avoid complaints, which just trades a small, visible friction for a large, invisible capacity leak.
Utilization insights, so right-sizing is a fact
Application teams can see utilization, CPU and memory, for VMs and VKS clusters directly against their deployments. This is more useful than it first appears. The Change action lets a consumer resize, but without data they resize by feeling, which usually means up and never down. Utilization turns that into evidence: a VM sitting at single-digit CPU for a month is a resize-down candidate, and a deployment pinned at its memory ceiling is a real bottleneck rather than a complaint. Pair the utilization view with a day-2 policy that permits the Change action and you get right-sizing the consumer drives themselves, which is the only kind that scales.
Driving day-2 from the API
The console is fine for one deployment. For many, or for anything repeatable, day-2 belongs in the API. The pattern is the same one that keeps you honest elsewhere in the platform: list, discover the available actions on the specific deployment, then run one by its action id rather than assuming the string. Get a token first, which is covered in Part 20.
# List your deployments
curl -s -H "Authorization: Bearer $TOKEN"
https://$VCFA/deployment/api/deployments?expand=true
# Discover the day-2 actions available on ONE deployment (do not guess the id)
curl -s -H "Authorization: Bearer $TOKEN"
https://$VCFA/deployment/api/deployments/$DEP_ID/actions
# Run an action using an actionId returned above (here: extend the lease)
curl -s -X POST -H "Authorization: Bearer $TOKEN"
-H "Content-Type: application/json"
https://$VCFA/deployment/api/deployments/$DEP_ID/requests
-d '{"actionId":"Deployment.ChangeLease","inputs":{"Lease Expiration Date":"2026-09-01"}}'Expected result: the POST returns a request you can poll until it completes, and the deployment lease moves out. Failure mode: a 403 or an empty action list usually means the day-2 policy does not grant that action to the token's user, not that the API is wrong. Confirm the exact paths and action ids against the API reference for your build, because they are versioned. The same loop scripts cleanly for bulk operations like extending every lease in a project before a holiday freeze.
My Take
Treat the Deployments page as a product you operate, not a screen you ignore after go-live. Scope day-2 actions tightly so owners can do the routine things and only admins can do the irreversible ones, keep default leases short with painless self-service extension, and surface utilization so resizing is driven by data. When would I loosen this? For a mature platform team that owns its own capacity, widen the action set and lengthen leases, because the people bearing the cost are the ones making the call. For everyone else, short leases and a narrow Delete grant will save you more incidents than any amount of monitoring. The console is the front door, but push your heavy consumers to the API early so day-2 scales past what clicking can handle. What does your average lease length look like against how often a project actually reclaims capacity?
References
- How do I manage my deployments in VCF Automation (Broadcom TechDocs)
- Configure Day 2 Action Policies in VCF Automation (Broadcom TechDocs)
- Configure Lease Policies in VCF Automation (Broadcom TechDocs)
- Self-service private cloud with VCF 9.1 (Broadcom)
About The Author
