Dprime Hosting

Give an AI coding agent safe SSH deployment access

Create a website-scoped connection that can publish a release without exposing root access or unrelated services.

Separate development from production

The agent should edit and test a local repository. SSH is used only for the final, reviewed deployment and verification steps.

  • Do not install an autonomous coding agent as root on the production server.
  • Do not share the hosting-panel administrator password with a coding tool.
  • Do not reuse a personal SSH key that opens several servers.
  • Do not keep a private key inside the website repository or public document root.

Create the smallest useful account

  1. Use the website-level SSH account supplied by Dprime or request a dedicated deployment user.
  2. Limit the account to the relevant website files and application processes.
  3. Use public-key authentication and generate a separate key pair for this deployment workflow.
  4. Add only the public key to the destination account.
  5. Keep the private key in a permission-restricted local file or approved secret store.
Important

Enhance runs website-level processes and SSH sessions inside the website's isolated container. The exact capabilities still depend on the hosting package and assigned website permissions.

Test access before automating

  1. Connect interactively using the hostname, port, username and private-key file.
  2. Confirm the remote working directory belongs to the intended website.
  3. Confirm the account cannot read another website or system configuration.
  4. Run read-only checks for the runtime, storage and current release.
  5. Upload a harmless temporary file outside the public path, verify it and remove it.

Use an atomic release process

  1. Upload the release into a new uniquely named directory.
  2. Copy production environment configuration from the current release without displaying its contents.
  3. Install production dependencies and build inside the new release directory.
  4. Run database migrations only when they are backward compatible and backed up.
  5. Switch the active path only after the new release builds successfully.
  6. Run health checks and restore the previous release automatically if verification fails.

Maintain the deployment credential

  • Name the key so its purpose and owner are clear.
  • Remove the public key when the tool, device or contractor no longer needs access.
  • Rotate the key after suspected exposure or a change of responsibility.
  • Review server authentication logs after unexpected deployment activity.

Official references

Platforms and tools change over time. Use these official references for the current product documentation.

Need help with this?

Tell us the affected domain, what you expected and the exact message you see.

Contact support