Temporary access for Magento developers

A preview environment is useful for a specific branch, fix or support investigation. Staging usually provides a longer-lived environment for testing a release against the production stack. An acceptance environment is where the merchant or delivery team confirms business behaviour. Teams use these names differently. The important decision is which code, services, data and integrations the environment contains, and who can change them.

For module support, prepare the Magento release, relevant extensions, PHP and supporting services needed to reproduce the issue. Use a branch for the proposed fix so the supplier can investigate without competing with other work on shared staging. Adobe’s deployment guidance recommends testing on staging before production; a representative environment makes that review meaningful.

A separate hostname alone does not make a safe test environment. Check the database, payment configuration, email delivery, webhooks and background integrations before handing it over. The developer should be able to trigger the problem without creating a real charge, sending a customer email or changing orders in a live external system.

Ask each developer for their SSH public key and add it to the selected site. Their private key stays with them. Give the record a useful label, such as the supplier, developer and support ticket, so the team can later identify whose access it represents. A shared password or shared supplier key makes that handover and removal harder to manage.

In Intercube, the site’s SSH key workspace brings the developer’s public key, label and expiration date together. Set the end date when access is granted and match it to the support task. Active, expiring and expired states give your team a clear view of the access window, so a supplier request remains easy to find and review.

For a two-day investigation, give the developer a named key with that agreed end date. If the work finishes early, remove the key from the site. If more time is needed, approve a new date. Your team keeps control of the access window while the supplier gets the environment needed to solve the issue.

A production copy can contain customer details, order history, API credentials and configuration for connected systems. Treat the copy as a data decision before it becomes a developer convenience. Remove unnecessary personal data and production credentials, and agree what the supplier is permitted to inspect or export. Use synthetic orders or a reduced dataset where they reproduce the problem.

Keep the test environment on separate credentials and endpoints. Payment providers should use their test mode, outgoing email should be captured or restricted, and ERP, fulfilment and marketing integrations should use test endpoints or be disabled when they are not part of the investigation. Check cron and queue consumers as well as the storefront; background jobs can contact a live service even when the page looks like staging.

Before access is granted, agree which administrative privileges and files are needed. SSH access can expose application configuration and anything readable by that site user. Intercube engineers prepare the runtime and services with your team; the merchant and application team approve the dataset and business integrations used for the investigation.

The supplier should return a module release, patch or reviewed code change with reproduction steps and the tests that demonstrate the fix. Keep it in the repository so your developers can inspect the difference and rebuild it. A manual change on the test server is useful evidence during diagnosis, but it should not become the only copy of the solution.

Run the fix through preview and the relevant acceptance checks, then release it through the production pipeline. Intercube includes deployment pipelines in the hosting plan, with build stages, logs and release history. Your team can use that route without assembling a separate GitHub Actions deployment workflow for this hosting environment.

Validate checkout, payment, customer accounts, scheduled work and integrations affected by the module. Agree any database changes or maintenance window before production deployment. A successful supplier test is one input to release approval; your team still decides whether the complete store is ready.

Access removal belongs in the definition of done for the support ticket. Remove the site SSH key, let the managed configuration change complete and verify that it no longer permits a new connection. Review any temporary Admin account, repository invitation, API token and database credential separately. Removing one SSH key does not revoke those other routes.

Record the final patch, release approval and access closure in the ticket. End the investigation session and review any processes or temporary integrations created for the work. Remove the preview environment when the investigation is complete, or give it a new purpose and owner if the team needs to retain it.

If the supplier still needs access, give the extension a new owner review and end date. A preview environment, a labelled key and a deliberate closure process let developers solve the problem without turning one support request into permanent access to the store.