How eight Magalu lookalike storefronts share one backend

In a saved capture of retiradamagalu[.]com, the page asks a service which store settings to use. A few seconds later, it sends a cart request back to the same service, carrying the identifier it just received. Beneath its imitation of Magalu, a Brazilian retailer, the storefront follows a shared application design.

That short exchange gave us a way to connect eight lookalike storefronts. Their different hostnames led to five store configurations in one backend, the service that handles the application's data. Following those requests explains a relationship that matching logos alone cannot show.

A store chooses its settings

The capture from 22nd October 2026 records a lookup called resolve_tenant_by_host. It sends the storefront's hostname and receives the corresponding configuration. The application calls this a tenant: a stored set of settings for a store.

The design lets one application serve several storefront addresses. A different hostname can select a different tenant, or several hostnames can select the same one. The tenant identifier tells later requests which configuration to use.

In this capture, the lookup returns the tenant we call E. The cart request then includes that same identifier. Both requests go to one project in Supabase, a hosted database and backend service.

The later request is important. A backend address left in copied code might never be used. Here, the browser uses the returned identifier in a cart request, and the service acknowledges it. The connection is visible in the exchange.

The same pattern connects eight storefronts

We compared ten complete lookup responses from captures dated 7th–22nd October. They cover eight hostnames, with repeat observations of two hosts. Every response returns a hostname that matches the store under examination.

The five tenant identifiers divide the stores into a clear pattern. Three hostnames select tenant A. Two select tenant B. Each of the remaining three selects its own tenant within the same backend project.

So some stores share more than a service: they select the same configuration. This lets us describe how the application groups the addresses without assuming that each address represents an independent system.

The cart records confirm that the pattern extends beyond the initial lookup. Nine archived cart submissions carry the tenant identifier from their preceding response. All nine receive HTTP 201, the service's acknowledgement. The remaining lookup observation did not reach a cart write.

These are requests from Sandfish's captures, not records of customer purchases. They show the application using its configurations. For this comparison, the important result is that the returned setting continues into a later operation.

An image match reaches a different application

Could the same approach connect more storefronts? A shared image URL supplied a candidate, but the application behind it changed the answer.

An 8th October archive of promegaofers[.]com contains the exact image URL found in the original application's code. That made it worth checking. The match concerned the written URL; the image files were not compared.

We inspected the complete archived main script. It points to a different Supabase project and contains neither the original project identifier nor its hostname-lookup function names. The image reference is shared, but the code does not support adding this store to the five-tenant map.

This comparison explains why the request sequence matters. A resource reference can be reused in an application with a different backend. A matching lookup response followed by a matching cart request establishes a more specific connection: the store is using that backend and configuration.

The connection is in the requests

The eight storefronts are connected through a shared application, with several addresses selecting the same stored configuration. The image-only comparison shows why a wider group of similar pages would need its own request evidence.

The tenant map does not identify the people behind the stores. A shared platform, copied settings, or delegated administration could produce these relationships. Five tenant IDs are not five verified customers, and one backend is not proof of one operator.

What we can follow is the application's decision: a hostname selects a configuration, and the cart uses it. That is the useful connection beneath the copied storefronts.

Source notes

The source ledger lists all eight hostnames, tenant aliases A–E, request IDs, and observation times. It records the complete-file comparisons and the different-backend control. The original project is opsgyzuojnswtwlrqzoi; the Promegaofers script names vgwoegmybeincutmqyua. The latter result applies to its selected complete main script.

Independent captures from 15th September also preserve an earlier build with the original project and hostname lookup. The compared September files match each other exactly, but differ from the October build. They date an earlier observation of the design, not its launch or another verified tenant.

The research used retained captures and archive files reviewed on 24th October 2026. All counts describe captured evidence, not traffic, victims, or payments.