Documentation
Access
SSH, SFTP, and keys
Separate shell access, file access, provider access, and deployment access so infrastructure remains understandable during handover.
Updated Jun 22, 2026
2 min read
What access tools do
SSH, SFTP, and deploy-key tools separate shell access, file access, source-code access, provider access, and workspace permissions. This separation matters when agencies manage infrastructure for multiple clients and contractors.
Before granting access
- Decide whether the person needs shell access, file access, deployment access, or dashboard access.
- Use individual keys rather than shared keys.
- Confirm provider keys and server-only keys are understood separately.
- Plan how access will be reviewed after launch or handover.
Typical workflow
- Save a named SSH public key.
- Sync it to existing servers or include it on future servers.
- Add server-only keys only for exceptions or temporary access.
- Create SFTP users with scoped directories and authentication choices.
- Use deploy keys for repository access instead of broad personal credentials.
- Review access when team or client ownership changes.
Checks before handover
- Every active key has an owner.
- Contractor access has an end date.
- Deploy keys are not confused with human shell access.
- SFTP users have the smallest useful directory scope.
- Provider-level keys remain visible in the connected provider account.
Common issues
- A shared SSH key remains after a contractor leaves.
- SFTP access is broader than the file-transfer workflow needs.
- A deploy key is removed and production deployments start failing.
- Provider keys are updated but server access is not reviewed.