How to Give Metricfixer Safe Node.js and Next.js Access

Use this guide when Metricfixer needs access to a Node.js, Next.js, React, Vue, Nuxt, Vite, or JavaScript/TypeScript application to diagnose an issue, review code, prepare a preview deployment, repair tracking, fix frontend or backend behavior, inspect logs, or deploy an approved change.

When to use this guide

This guide applies when the support task involves a JavaScript or TypeScript web project, especially a Node.js or Next.js application. It also applies to many frontend projects deployed through Vercel, Netlify, Cloudflare Pages, a VPS, Docker, Kubernetes, or a custom CI/CD pipeline.

Typical cases include:

• fixing a broken Next.js page, route, layout, server action, API route, middleware, or static generation issue;
• diagnosing failed builds, dependency conflicts, hydration errors, runtime exceptions, or deployment errors;
• repairing forms, authentication flows, checkout flows, webhooks, dashboards, or customer-facing UI issues;
• reviewing Node.js backend code, serverless functions, edge functions, workers, queues, or scheduled jobs;
• fixing analytics, conversion tracking, ecommerce events, pixels, data layer logic, consent-related behavior, or CRM conversion imports;
• preparing or reviewing a pull request, preview deployment, staging deployment, or approved production hotfix.

Preferred workflow

Metricfixer normally uses the following workflow for Node.js and Next.js projects:

1. Confirm the issue, affected URL, expected result, actual result, browser/device details, and business impact in the ticket.
2. Use screenshots, browser console output, network logs, deployment logs, error traces, 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 install, lint, type check, unit tests, integration tests, and production build.
6. Use a preview or staging deployment to verify the change before production whenever possible.
7. Deploy to production only after client approval, a clear rollback plan, and confirmation that the affected flow was checked.
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, browser console output, network logs, build logs, error messages, redacted configuration examples, or a short screen recording.

2. GitHub repository access

Use this for most code 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 repository-management task requires them.

3. Preview or staging deployment access

Use this when the issue should be reproduced, tested, or verified before production deployment. Preview or staging should use separate environment variables, test credentials, sandbox payment settings, and non-production data where possible.

4. Deployment provider project access

Use this only when repository access and preview links are not enough. If the project is hosted on Vercel, Netlify, Cloudflare Pages, Render, Railway, Fly.io, or a similar platform, provide the lowest project-level role that allows Metricfixer to inspect deployments, logs, build settings, and environment configuration required for the task. Do not provide Owner, billing, or organization-wide access by default.

5. Limited server or SSH access

Use this for self-hosted Node.js or Next.js projects only when needed to inspect logs, deployment paths, process managers, Docker containers, reverse proxy settings, or runtime behavior. The access should be temporary and limited to the relevant project or staging directory.

6. Production diagnostics or deploy access

Use this only when the issue is production-specific or when an approved deployment cannot be completed through the normal CI/CD workflow. Prefer read-only logs and deployment information before granting write access. Production changes require written approval in the ticket.

Before you provide access

Please add the following information to the ticket:

• production URL and preview or staging URL, if available;
• GitHub repository URL, default branch, production branch, staging branch, and preview branch rules;
• framework and application type: Next.js, Node.js API, React, Vue, Nuxt, Vite, Express, NestJS, Remix, Astro, monorepo, or another stack;
• Node.js version and how it is pinned, such as .nvmrc, package.json engines, Volta, asdf, Dockerfile, or CI settings;
• package manager: npm, pnpm, yarn, or bun;
• install, development, build, start, lint, type-check, and test commands;
• deployment provider and deployment method, such as Vercel, Netlify, Cloudflare Pages, GitHub Actions, Docker, VPS, Kubernetes, or manual deploy;
• whether the project uses server-side rendering, static export, API routes, serverless functions, edge functions, middleware, image optimization, queues, cron jobs, or background workers;
• required environment variable names in .env.example without secret values;
• where logs and error monitoring are available, such as Vercel logs, Netlify logs, Cloudflare logs, Sentry, Logtail, Datadog, or server logs;
• whether the issue affects production users, payments, emails, orders, subscriptions, tracking, advertising optimization, or data collection;
• confirmation that a rollback method exists before any production deployment.

Repository requirements

A safe Node.js or Next.js 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.
• Commit the correct lock file: package-lock.json, pnpm-lock.yaml, yarn.lock, or the lock file used by your package manager.
• Keep .env.example updated with placeholder values and required variable names.
• Do not commit .env, .env.local, .env.production, database dumps, private keys, OAuth tokens, API secrets, payment secrets, SMTP passwords, or production credentials.
• Pin the Node.js version in a visible place, such as .nvmrc, .tool-versions, package.json, Dockerfile, or CI configuration.
• Include setup notes in README.md, DEPLOY.md, or AGENTS.md when available.
• Document the expected test, lint, type-check, build, preview, and deployment commands.
• If the project is a monorepo, tell us which app/package is affected and which workspace commands should be used.

Environment variables and secrets

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

• Provide .env.example with non-secret placeholders and all required variable names.
• Use separate values for local, preview, staging, and production environments.
• Use staging-only or sandbox credentials for preview and staging work. Do not reuse production database, payment, email, storage, OAuth, or webhook credentials in preview deployments.
• Do not send production .env, .env.local, or .env.production files unless Metricfixer specifically asks for a limited excerpt through an approved secure method.
• In Next.js, variables exposed to the browser usually use the NEXT_PUBLIC_ prefix. Never place private secrets, database URLs, API secrets, payment secrets, or access tokens in variables that are exposed to the browser.
• Some frontend and Next.js variables are applied at build time. After changing deployment environment variables, a rebuild or redeploy may be required.
• If a production secret is truly required for an approved task, provide only the specific secret through the agreed secure method and rotate it after completion where appropriate.

Preview and staging requirements

A safe preview or staging environment should be separated from production.

• Use automatic preview deployments for pull requests when the hosting provider supports them.
• Use a clearly separate staging or preview URL.
• Protect private previews with authentication, password protection, team-only access, noindex headers, or IP restrictions where possible.
• Use a separate staging database, API environment, storage bucket, search index, and cache namespace where possible.
• Use sandbox payment settings and test cards for checkout-related work.
• Disable or redirect customer-facing emails unless email delivery is part of the test.
• Disable live webhooks, fulfillment, subscription renewals, CRM automations, advertising conversion imports, and marketing automations unless they are required for the test.
• Do not point preview deployments to production-only APIs unless this has been explicitly approved and the risk is understood.

Vercel, Netlify, Cloudflare Pages, and similar platforms

If your project is deployed through a managed frontend platform, repository access may be enough. Provider access is needed only when Metricfixer must inspect build logs, deployment settings, environment variables, domains, redirects, functions, edge behavior, or platform-specific errors.

• Invite Metricfixer with the lowest available project-level role that allows the approved task.
• Do not provide Owner, billing, or organization-wide access by default.
• Do not share a personal login or personal access token for the deployment provider.
• If environment variable editing is required, limit it to the affected project and environment whenever the platform supports that.
• Production deploys should require client approval. The client may keep production promotion rights and ask Metricfixer to prepare only the pull request and preview deployment.
• If DNS changes are required, prefer that the client adds the DNS records from Metricfixer instructions instead of granting full registrar access.

Self-hosted Node.js or Next.js projects

If the project runs on a VPS, dedicated server, Docker host, Kubernetes cluster, or custom infrastructure, please follow the server access guide as well.

• Create a temporary deploy or diagnostic user such as metricfixer-deploy or metricfixer-ticket-1234.
• Use SSH key authentication where possible.
• Limit access to the relevant project, release, or staging directory.
• Do not provide root SSH, unrestricted sudo, access to unrelated applications, or hosting master accounts.
• Tell us how the app is started and restarted, such as npm start, next start, PM2, systemd, Docker Compose, Kubernetes, or a platform-specific process manager.
• Share log locations, process names, ports, reverse proxy configuration, and deployment commands only as needed for the task.
• Treat Docker socket or Docker group access as high-privilege access. Do not grant it unless the task requires it and the risk is approved.

Databases, APIs, and third-party services

• Use staging or sandbox credentials for databases, APIs, payment providers, email providers, storage providers, and CRM systems whenever possible.
• For production diagnostics, prefer read-only dashboards, logs, error reports, or redacted payload examples.
• Do not provide production database write access unless the approved scope requires it and a backup or rollback plan exists.
• Do not provide live payment gateway secret keys, webhook signing secrets, OAuth client secrets, or private API tokens unless they are strictly required for the approved task.
• For webhooks, provide event IDs, timestamps, redacted payload examples, dashboard screenshots, and logs before sharing secrets.
• Create temporary test accounts instead of asking Metricfixer to use real customer accounts.

What not to provide

Please do not provide the following unless Metricfixer explicitly confirms that a specific item is required for the approved scope:

• personal passwords or personal employee accounts;
• GitHub organization Owner, repository Admin, or access to unrelated repositories;
• deployment provider Owner, billing, organization admin, or full team access;
• production .env, .env.local, .env.production, production database URLs, private keys, OAuth tokens, API secrets, SMTP passwords, or live webhook secrets;
• private secrets in NEXT_PUBLIC_ or other browser-exposed variables;
• root SSH, unrestricted sudo, Docker socket access, or hosting master accounts;
• production database write access or full production database dumps without a specific need;
• live payment secrets, full card data, bank credentials, or payout settings;
• full customer exports, private uploads, health data, children’s data, government ID data, or unrelated sensitive information;
• domain registrar owner access unless the task specifically requires domain-level changes.

If no preview or staging environment exists

If there is no preview or staging environment, Metricfixer may first ask to create one or to configure pull request preview deployments. If that is not possible, the ticket may move to a limited production hotfix workflow with stronger safeguards.

For production-only work, we may require:

• client confirmation that production work is approved;
• a recent backup or a platform rollback option;
• a short maintenance window if user-facing risk exists;
• a reviewed branch, pull request, patch, or deployment plan;
• a person on the client side who can verify the result immediately after deployment;
• access revocation or secret rotation after completion.

How to revoke access after completion

1. Remove Metricfixer from the GitHub repository, organization team, or temporary collaborator list if access is no longer needed.
2. Remove Metricfixer from Vercel, Netlify, Cloudflare, Render, Railway, Fly.io, or other deployment providers.
3. Delete temporary SSH/SFTP users, deploy keys, API tokens, and provider tokens created for the ticket.
4. Rotate any secret that was shared for the task, especially API tokens, OAuth secrets, webhook secrets, database passwords, and payment-related secrets.
5. Remove or disable temporary test users, preview credentials, and staging-only accounts if they are no longer needed.
6. Check that no production secrets were committed to the repository or placed in browser-exposed environment variables.
7. Keep the final pull request, deployment record, and ticket history for future reference.