Define the deploy account
Scope a deployment identity to one application, environment and write path. Customer root access does not justify broad agency administrator rights.
Give the operator the application, environment, domain, deploy tool and named users. Specify required write paths, read-only configuration access, database migration needs, the approving owner and when to revoke access.
For VM Start with Managed OS, the customer retains root access; coordinate guest-account changes that affect agreed OS work. Ubuntu documents local user and group management and explains that sudo grants elevated system administration. An agency deployment identity still needs a narrow agreed scope. Request only the access the contract permits; do not ask for root or blanket sudo because a deployment command fails. If you are still comparing services, use the managed VPS access-boundary guide to check who may change the guest before requesting an account.
Separate file, database and platform permissions
Ask for a named account or other approved identity for one application. The writable area should be confined to the deployment destination and any documented release or cache directories. The process may need to read application configuration, but secret-bearing files should be delivered through the approved route and should not become downloadable from the web root. Database changes, where needed, call for a separately scoped database identity and an explicit migration procedure; a file-transfer account does not automatically need database administration.
Tell the operator whether the tool requires SFTP, SSH, a CI connection or a panel upload. If it requires a privileged service restart or ownership change, request an operator-run step rather than broadening the deployment identity. Clarify whether the account is temporary, how its key or password is rotated and who can approve another agency user.
Test both intended and unintended access safely
After provisioning, use a harmless test file within the approved application path and verify that the expected site or deployment process can read it as designed. Remove the test file after confirming. Ask the operator to demonstrate or confirm that the account cannot write platform configuration, another application’s directory or another customer’s data. Do not probe unrelated tenant paths yourself; use the operator’s controlled acceptance checks. For database access, test only a pre-agreed non-sensitive operation against the intended database.
Record the account owner, scope, authorised users and successful test. A login that succeeds but cannot complete a normal deployment may have too little access; a login that can change system settings has too much. Revisit the scope with the operator rather than changing filesystem permissions indiscriminately.
Illustrative acceptance: an agency account can create and remove a harmless file in its release directory. The operator confirms it cannot write system configuration or another application's files.
Do not probe other tenants to test isolation; have the operator confirm denied access through its controlled acceptance process.
Review and revoke access at handover
When a deployment method changes or an agency leaves, have the operator revoke its key or account and review any related CI secret and database identity. Verify the authorised replacement can still deploy before retiring the old route. Keep a rollback artefact for application changes; access revocation does not roll back a release.
Frequently asked questions
Should the deploy account own every site file? The operator should define ownership according to the application and web-server model. Blanket ownership changes can break services or widen access.
Can a successful SFTP login prove the scope is safe? No. Test the intended write path and obtain a controlled check of denied out-of-scope access.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.