How to Give Metricfixer Safe Laravel and PHP Access

Use this guide when Metricfixer needs access to a Laravel, Symfony, custom PHP, or PHP-based web application to diagnose an issue, review code, prepare staging, fix tracking or application logic, inspect logs, run tests, or deploy an approved change.

When to use this guide

This guide applies when the support task involves a Laravel or PHP application, including backend code, Blade views, APIs, queues, scheduled tasks, tracking code, forms, ecommerce logic, payment flows, CRM integrations, or deployment behavior.

Typical cases include:

• diagnosing Laravel errors, PHP exceptions, failed requests, broken forms, API failures, routing issues, or Blade template problems;
• fixing custom PHP code, Laravel controllers, jobs, events, listeners, middleware, validation, service classes, or views;
• reviewing Composer dependencies, package updates, Laravel version compatibility, PHP version compatibility, or failed builds;
• checking queues, failed jobs, scheduler tasks, cron configuration, webhooks, notifications, and mail delivery;
• repairing analytics, conversion tracking, ecommerce events, pixels, data layer logic, server-side events, or CRM conversion imports;
• preparing staging, testing a pull request, or deploying an approved production hotfix.

Preferred workflow

Metricfixer normally uses the following workflow for Laravel and PHP projects:

1. Confirm the issue, affected URL or endpoint, expected result, actual result, and business impact in the ticket.
2. Use screenshots, logs, error messages, exports, and read-only information first when direct access is not required.
3. Work from a GitHub repository using a separate branch and pull request.
4. Use a reproducible development or Codex environment based on .env.example, not production secrets.
5. Run the agreed checks, such as Composer install, frontend build, Pint, PHPUnit, Pest, static analysis, or smoke checks.
6. Deploy to staging and verify the fix there whenever the issue can be reproduced outside production.
7. Deploy to production only after backup, client approval, and a clear rollback plan.
8. Revoke temporary access after the ticket is completed.

Choose the minimum safe access level

1. No direct access

Use this for an initial review when Metricfixer can diagnose the issue from public pages, screenshots, log excerpts, stack traces, browser console output, network logs, deployment logs, or sanitized configuration examples.

2. GitHub repository access

Use this for most Laravel/PHP fixes. Give Metricfixer repository access with Write permission so we can create a branch, commit changes, open a pull request, and document the fix. Do not provide organization owner or repository admin rights unless a separate infrastructure task requires them.

3. Staging application access

Use this when the issue should be reproduced, tested, or verified before production deployment. Staging should have its own database, storage, mail behavior, payment test mode, queue configuration, and environment variables.

4. Limited SSH or SFTP access

Use this only when repository access is not enough or when Metricfixer must inspect logs, verify deployment paths, run approved commands, check queue workers, or prepare staging. The access should be temporary and limited to the relevant project directory.

5. Production read-only diagnostics

Use this when the issue is production-specific and cannot be reproduced on staging. Prefer read-only logs, monitoring output, error reports, or temporary read-only access before granting write access.

6. Production deploy or write access

Use this only after explicit approval in the ticket. A production change should have a recent backup, reviewed pull request or patch, rollback plan, and a person on the client side who can approve and verify the deployment.

Before you provide access

Please add the following information to the ticket:

• production URL and staging URL, if available;
• repository URL, default branch, staging branch, and deployment branch;
• framework and application type: Laravel, Symfony, custom PHP, WordPress-adjacent custom PHP, API-only backend, monolith, or microservice;
• PHP version, Laravel/Symfony/framework version, Composer version, Node version, package manager, and database engine;
• build and test commands, such as composer install, npm ci, npm run build, php artisan test, vendor/bin/pint, or project-specific commands;
• deployment method: GitHub Actions, Forge, Envoyer, Deployer, Plesk/cPanel, manual SSH, Docker, Kubernetes, FTP/SFTP, or hosting panel;
• whether queues, workers, Horizon, Redis, cron, scheduler, websockets, Reverb, Octane, or long-running processes are used;
• where logs are stored and whether error monitoring is available;
• whether the issue affects production users, payments, emails, orders, subscriptions, tracking, CRM, advertising optimization, or data collection;
• confirmation that a recent backup exists before any production code, database, or configuration change.

Repository requirements

A safe Laravel/PHP workflow starts with a clean repository.

• Give Metricfixer GitHub repository access with Write permission, not Admin or Owner.
• Keep main, master, and production branches protected from direct pushes where possible.
• Keep composer.json, composer.lock, package.json, and the package lock file committed when the project uses them.
• Keep .env.example updated with placeholder values so the project can be installed without production secrets.
• Do not commit .env, database dumps, private keys, OAuth tokens, API secrets, payment gateway secrets, SMTP passwords, or production credentials.
• Include setup notes in README.md, DEPLOY.md, or AGENTS.md when available.
• Document the expected test, build, lint, and deployment commands.

Safe Laravel environment setup

Metricfixer should be able to run or analyze the project without live production credentials.

• Provide .env.example with non-secret placeholders and required variable names.
• Use separate values for local, staging, and production environments.
• Use staging-only credentials for staging work. Do not reuse production database, SMTP, payment, storage, OAuth, or webhook credentials on staging.
• Use a local or disposable development database for Codex/dev analysis whenever possible.
• Set APP_DEBUG=false on public production environments.
• Confirm where APP_KEY, database credentials, queue credentials, cache credentials, storage credentials, and mail credentials are managed.
• If production secrets must be used for a specific approved task, provide them only through the agreed secure method and rotate them after completion where appropriate.

Staging requirements

A safe Laravel/PHP staging environment should be separated from production.

• Use a staging domain or subdomain that is clearly separate from production.
• Protect staging with authentication, IP restriction, or another access control when possible.
• Use a separate staging database. Use sanitized or reduced data where possible.
• Disable or redirect customer-facing emails unless email testing is part of the task.
• Use payment gateway sandbox or test mode on staging.
• Disable live webhooks, live fulfillment, subscription renewals, CRM automations, advertising conversion imports, and marketing automations unless they are required for the test.
• Keep queue workers and scheduled tasks controlled so staging does not process production jobs.
• Confirm whether uploads, private files, generated documents, and storage links are copied, sanitized, or excluded from staging.

SSH, SFTP, and deployment access

If server access is required, please create a separate temporary user for Metricfixer instead of sharing a personal or root account.

• Use a clear username such as metricfixer-deploy or metricfixer-ticket-1234.
• Use SSH key authentication where possible.
• Limit access to the relevant project directory, release directory, or staging directory.
• Do not provide root SSH, unrestricted sudo, hosting master accounts, billing access, or access to unrelated websites.
• If privileged commands are required, allow only specific approved deploy or restart scripts instead of full sudo.
• If the project uses Docker, be careful with Docker socket or Docker group access because it can provide broad control over the host.
• Prefer deployment through GitHub Actions, a deployment tool, or a reviewed deploy script instead of manual file editing on production.

Database and migration safety

Laravel/PHP fixes often involve migrations or data repair. Keep database access limited to the task.

• For staging, provide a staging database user with the permissions required for the task.
• For production diagnostics, prefer read-only database access or log/export-based review.
• Do not provide database root credentials unless Metricfixer specifically confirms that they are required and approved.
• Do not send full production database dumps when a sanitized sample, schema, specific table export, or specific record ID is enough.
• Production migrations should be reviewed, backed up, and approved before running.
• Do not run destructive commands such as migrate:fresh, db:wipe, table drops, mass deletes, or irreversible data updates on production unless they are explicitly approved and backed up.

Queues, scheduler, workers, and cron

Please tell Metricfixer if the project uses background processing.

• Identify the queue driver, such as database, Redis, SQS, Beanstalkd, or another provider.
• Identify worker management, such as Supervisor, systemd, Horizon, Docker, Kubernetes, or hosting panel workers.
• Share relevant failed job details, queue logs, scheduler logs, and cron configuration where available.
• Confirm whether workers must be restarted or reloaded after deployment.
• Keep staging workers separate from production workers.
• Do not give production queue credentials or cloud queue credentials unless they are required for the approved task.

Files, storage, and uploads

If the issue involves file uploads, private downloads, invoices, generated files, images, feeds, or exports, provide only what is needed.

• Tell Metricfixer which filesystem driver is used: local, public, S3-compatible, cloud storage, or custom storage.
• Provide sample files instead of full customer file archives where possible.
• Do not provide unrelated private customer files or full storage buckets.
• Confirm whether storage:link, private disks, signed URLs, file permissions, or CDN behavior are relevant to the issue.
• Use staging storage or a sandbox bucket for testing whenever possible.

Email, payments, webhooks, and third-party integrations

Laravel/PHP projects often connect to payment providers, email providers, CRMs, analytics platforms, ad platforms, and webhook-based systems. Keep these credentials separated by environment.

• Use log mailer, test SMTP, sandbox email, or redirected test recipients on staging.
• Use Stripe, PayPal, WooPayments, or other payment providers in test/sandbox mode on staging.
• Do not send live payment gateway secret keys, webhook signing secrets, payout settings, bank credentials, or full card data unless specifically requested for an approved task.
• If live webhooks must be reviewed, provide dashboard access or redacted examples first.
• If an integration requires production credentials, ask Metricfixer to confirm why they are needed and how they should be rotated after completion.

Production deployment rules

Production deployment should be deliberate and traceable.

• Confirm the production branch, deployment command, and rollback method before deployment.
• Confirm that a recent backup exists for files, database, and relevant configuration.
• Use a pull request, reviewed patch, or documented release whenever possible.
• Run the agreed build and test checks before deployment where practical.
• Use a maintenance window when the change may affect checkout, payments, login, database schema, queues, or customer-facing flows.
• After deployment, verify agreed smoke checks, logs, queues, scheduler, forms, checkout, tracking, or webhook behavior.

What not to provide

• your personal developer, server, hosting, or GitHub password;
• root SSH, unrestricted sudo, hosting master account, billing access, or registrar owner access;
• repository Admin or organization Owner permissions unless separately approved;
• production .env file, APP_KEY, private keys, OAuth tokens, API secrets, SMTP passwords, or live webhook secrets unless explicitly required;
• database root credentials or full production database dumps when a limited export is enough;
• live payment gateway secrets, bank credentials, payout settings, or full payment card data;
• full customer exports, private user files, health data, children’s data, government IDs, or unrelated personal data;
• access to unrelated websites, servers, repositories, cloud accounts, or business systems.

After the ticket is completed

After Metricfixer completes the work, please review and revoke temporary access.

1. Remove Metricfixer from GitHub if ongoing repository access is not needed.
2. Disable temporary SSH/SFTP/deploy users.
3. Remove temporary database users and staging users that are no longer required.
4. Revoke temporary API tokens, application passwords, webhook secrets, and integration tokens.
5. Rotate any secret that was shared temporarily for the approved task.
6. Keep the pull request, deployment log, backup reference, and test result in your internal records.

Quick checklist

• GitHub access is limited to the required repository.
• Production branches are protected where possible.
• .env.example is available and production .env is not sent.
• Staging is available or the ticket explains why production access is required.
• Database access is staging or read-only unless write access is approved.
• Queues, scheduler, storage, mail, payments, and webhooks are documented if relevant.
• Production backup and deployment approval are confirmed before production changes.
• Temporary access will be revoked after completion.