Decide who operates each part
Document the infrastructure boundary, access model and responsibilities for configuration, upgrades, data and recovery. Agree on a handover before production use.
MolternAgencies
For your team
Deliver the application. Make the handover work.
Give client projects a clear workspace, service boundary and path from development to production.
Flight paths artwork / 04
The launch is successful when the next person can operate it. Separate client workloads, grant only the access a collaborator needs, and keep configuration with the project. Plan domains, data ownership and ongoing operations before handing over the application.
Put it into practice
Grant the access a task needs
Use managed roles and the narrowest useful scope. Set expiry for temporary access, inspect effective permissions and revoke the grant when the work is finished.
Check the release people will use
Inspect deployment status and logs, verify the URL and test the application’s main workflow. Record who owns configuration changes, service upgrades and recovery.
Detailed instructions are maintained in the product documentation.
Questions before you start
Is infrastructure ownership the same as a security certification?
No. Infrastructure placement and operational responsibility are design choices, not claims of independent certification.
Does using a secret allow someone to reveal it?
Secret use and secret reveal are separate permissions. Grant sensitive access only when the task requires it.
What should I check when a deployment fails?
Start with deployment logs, build commands, runtime port, health checks and required variables, then follow the troubleshooting guide.
Keep exploring
All pages ↗
Start with one useful workload.
Bring your code or choose a service, then give the result a clear operating home.
Start building ↗