How to Give Metricfixer Safe Server and SSH Access

Use this guide when Metricfixer needs safe server, SSH, or SFTP access to inspect files, read logs, prepare a staging environment, deploy an approved fix, or support a technical repair task.

When to use this guide

This guide applies when Metricfixer needs access to a server or hosting environment, including SSH, SFTP, application logs, deployment scripts, or staging setup.

Typical cases include:

• creating or fixing a staging environment;
• reviewing application files that are not yet in GitHub;
• checking deployment failures, permissions, cron jobs, queues, or background workers;
• reading application logs related to the issue;
• deploying an approved pull request to staging;
• performing an approved production hotfix when staging is not available;
• verifying runtime versions, web root, environment variables, or server configuration related to the ticket.

Preferred workflow

Metricfixer normally uses a staging-first workflow:

1. You provide GitHub access for the codebase, if a repository exists.
2. You provide staging server access, SFTP access, or a temporary deploy user only for the project involved in the ticket.
3. We inspect the issue, project structure, logs, and deployment process.
4. We make code changes in GitHub through a branch and pull request whenever possible.
5. We deploy or help deploy the change to staging.
6. You review the staging result.
7. Production deployment happens only after approval and with a rollback plan.
8. Temporary access is revoked after the ticket is completed.

Before you give server access

Please prepare the following information in the ticket:

• server or hosting provider name;
• environment type: staging, production, development, shared hosting, VPS, cloud VM, Docker host, or managed platform;
• website URL and staging URL, if available;
• project directory path, web root, and deploy path, if known;
• runtime versions, such as PHP, Node.js, Python, Ruby, Java, MySQL, MariaDB, PostgreSQL, Redis, or other relevant services;
• deployment method, such as GitHub Actions, manual SSH deploy, SFTP upload, Docker Compose, release directory, or hosting control panel;
• commands used to build, restart, migrate, queue, cache, or clear the application;
• location of relevant logs, if known;
• whether the environment contains production customer data;
• confirmation that a recent backup or snapshot exists before production changes.

Recommended access level

Choose the smallest access level that allows Metricfixer to perform the agreed task.

1. No server access

Use this when the issue can be solved through GitHub, screenshots, exported logs, or written instructions. This is preferred for simple code review, tracking review, and configuration guidance.

2. Read-only diagnostics

Use this when Metricfixer only needs to inspect logs, configuration names, runtime versions, or deployment errors. The user should not be able to change application files or restart services.

3. Staging SFTP access

Use this when Metricfixer needs to inspect or adjust files on a staging environment but does not need a shell. Limit access to the staging project directory.

4. Staging SSH deploy user

Use this when Metricfixer needs to run install, build, test, deploy, migration, queue, cache, or restart commands on staging. The user should be limited to the project directory and the specific commands required for the task.

5. Production deploy access

Use this only when the change has been reviewed and approved, or when an emergency hotfix has been explicitly confirmed. Production access should be temporary, limited, logged, and backed by a rollback plan.

How to create a safe SSH user

Ask your server administrator to create a separate temporary user for Metricfixer. A typical setup is:

• Username: metricfixer-deploy or another ticket-specific name;
• Authentication: SSH public key only;
• Password login: disabled for this user whenever possible;
• Scope: only the relevant project directory or staging directory;
• Sudo: disabled by default;
• Expiration: remove or disable after the ticket is completed;
• Logging: keep normal SSH, sudo, deploy, and application logs available for review.

Example request for your server administrator

You can send this to your hosting provider or DevOps team:

Please create a temporary SSH/SFTP user for Metricfixer named metricfixer-deploy. The user should authenticate by SSH public key only, have access only to the project directory needed for this ticket, and should not have root or unrestricted sudo access. If privileged actions are required, please allow only the specific deploy or restart scripts agreed for this task. We will remove this access after the ticket is completed.

If sudo is needed

Most tasks should not require full sudo. If a privileged action is required, please allow only specific commands or wrapper scripts, for example:

• /usr/local/bin/project-staging-deploy
• /usr/local/bin/project-staging-restart
• /usr/local/bin/project-staging-logs

Avoid rules that allow ALL commands. Do not give unrestricted sudo su, sudo -i, shell access as root, or passwordless sudo for every command unless it is explicitly approved for an emergency production case.

Recommended directory scope

Access should normally be limited to one of these paths or an equivalent project-specific directory:

• /var/www/example.com/staging
• /var/www/example.com/current
• /home/example-user/apps/example-project
• /srv/example-project

Metricfixer does not need access to unrelated websites, other customers, personal home directories, system-wide secrets, mailboxes, backups unrelated to the task, or the hosting provider billing account.

What not to provide

Please do not provide the following unless Metricfixer specifically requests it for a defined reason and you approve that scope:

• root SSH login;
• server root password;
• your personal SSH private key;
• hosting master account login;
• full control panel owner access;
• unrestricted sudo or sudo su access;
• access to unrelated websites or users on the same server;
• production database write access;
• database root credentials;
• live payment provider secrets;
• cloud provider owner access;
• domain registrar owner access, unless the task specifically involves DNS or domain changes.

Production access rules

Production server access is not the default. If production access is needed, please make sure that:

• the task scope is clear and approved in the ticket;
• a recent backup, snapshot, or restore point exists;
• there is a rollback or revert plan;
• the change has been tested on staging whenever possible;
• the access is temporary and limited to the project involved in the ticket;
• there is a named person who can approve production deployment;
• deployment timing is agreed if the change can affect visitors, orders, tracking, payments, or customer data.

Emergency production hotfix

If there is no staging environment and the issue must be fixed directly on production, please confirm emergency mode in the ticket before work begins.

Emergency production work should include:

• written approval for production changes;
• backup or snapshot confirmation;
• short description of the exact issue and target result;
• temporary SSH/SFTP access limited to the affected project;
• database access only if the task requires it and it is separately approved;
• rollback notes or the ability to restore changed files;
• post-fix verification and access revocation.

If the project uses Docker

Do not add Metricfixer to the Docker group by default. Access to the Docker daemon can effectively allow broad control over the host. If Docker actions are needed, prefer specific scripts for the agreed project, such as:

• /usr/local/bin/project-staging-compose-pull
• /usr/local/bin/project-staging-compose-up
• /usr/local/bin/project-staging-compose-logs
• /usr/local/bin/project-staging-compose-restart

If full Docker access is unavoidable, it should be treated as elevated server access and approved explicitly.

If the project is on shared hosting, cPanel, or Plesk

When possible, create a separate SFTP/FTP user restricted to the project directory or staging subdomain. Do not send the main hosting account password if a limited account can be created.

If the hosting provider does not support limited users, we may provide step-by-step instructions for your administrator to perform sensitive actions, or we may use a supervised remote access session if it is necessary for the agreed task.

Logs and sensitive data

Logs are often enough for diagnostics, but they may contain personal data, access tokens, session identifiers, order data, email addresses, IP addresses, or other sensitive details. Please share only the logs required for the ticket and redact secrets where possible.

If Metricfixer needs to inspect logs directly on the server, access should be limited to the relevant application logs whenever practical.

After the work is completed

After Metricfixer confirms that the server-side work is completed, please:

1. disable or delete the temporary SSH/SFTP user;
2. remove Metricfixer public keys from authorized_keys if they are no longer needed;
3. remove temporary sudo rules or deploy scripts that are no longer required;
4. rotate any password, token, or key that was shared directly;
5. verify that no production secrets were added to GitHub, tickets, logs, or documentation;
6. keep deployment notes and rollback details in your internal records.