On this page
- Web vs. desktop: where does the browser actually run?
- Why did using both interfaces cause a problem?
- Where is profile data stored?
- Choosing cloud or local storage around the workflow
- Synchronization needs a clear handoff point
- What value does the design deliver?
- More from the Multilogin review series
- Frequently asked questions
The web interface and desktop app are two ways to manage profiles. Cloud and local storage are two ways to save profile data. You can choose the interface around how you work and choose storage around where the data needs to be available.
This distinction explains much of Multilogin’s design. The web interface gives you another management entry point, while the desktop app brings management and launching into one application. Cloud storage supports saved-data access across devices; local storage keeps browser data on the machine where the profile runs.
Our review combines the October 31, 2026 interface checks and operating experience with the vendor’s documented workflow. Our practical recovery tests used cloud profiles on one Mac. Cross-device synchronization and member access are discussed through the official product design.
Web vs. desktop: where does the browser actually run?
An Agent is the background component connecting the web dashboard to profiles on your computer. The standalone web workflow needs that component. The desktop app includes it. Multilogin also documents using both interfaces together, with the desktop app handling launches. Official interface comparison.
| Setup | Where you manage profiles | What launches the profile locally |
|---|---|---|
| Web interface with a standalone Agent | A tab in your ordinary browser | The separately installed Agent and launcher |
| Desktop app | The Multilogin application | Its built-in launching components |
| Web interface with the desktop app | Either interface, using the same account | The desktop app, with the legacy Agent disconnected |
When you click Start in the dashboard, the Mimic window runs on the computer. The browser interface does not remove the local launching requirement. Multilogin explains the division of responsibilities in its Agent and launcher documentation.
Our assessment: the desktop app is the more natural starting point for a solo user who wants to open one application and begin working. The web interface adds flexibility when browser-based workspace management fits the workflow. Both should make the current launcher status obvious.
Why did using both interfaces cause a problem?
In our setup experience, using both entry points led to a situation where one did not work as expected. Diagnosing it required separating three objects: the dashboard, the independent Agent, and the desktop application.
The documented procedure is to disconnect the legacy Agent, sign in to the desktop app, and then sign in to the web interface using the same account. The desktop app becomes responsible for launching profiles. Official coexistence procedure.
Our interpretation is that launcher ownership is the right first checkpoint for this symptom. Users see two interfaces, but the underlying switch also involves two ways to provide the local component. Similar application names make that relationship harder to recognize.
The design would be clearer with a visible statement such as “Profiles are launched by the desktop app” and a guided handoff when the active component changes. That would preserve the flexibility while reducing the need to understand the installation history.
Where is profile data stored?
Profile management information and browser data have different roles. Management information identifies and organizes a profile. Browser data carries the website state you expect to recover, including cookies and session-related data.
| Information | Cloud profile | Local profile |
|---|---|---|
| Metadata used to identify and manage the profile | Kept in the cloud | Also kept in the cloud |
| Browser data, such as cookies and extensions | Saved through cloud storage | Kept on the device |
Multilogin’s storage explanation identifies AWS as its cloud storage provider and says metadata remains in the cloud for either storage type. Official storage explanation.
The operational consequence is that “local” answers where browser data lives. Account access, workspace management, and component connectivity still need to be considered separately when planning the software’s network access.
Choosing cloud or local storage around the workflow
| Need | Cloud storage | Local storage |
|---|---|---|
| Continue on another computer | Designed to retrieve saved browser data through synchronization | Requires a plan to move browser data from the original computer |
| Hand work to another member | Fits a shared-profile workflow | Better aligned with a fixed-device workflow |
| Open and stop profiles | Pay attention to downloads and completed uploads | Pay attention to the data on the current device |
| Daily responsibility | Wait for the save confirmation before handing off | Maintain local backups and a migration plan |
The vendor describes both modes and provides a conversion workflow in its cloud and local storage help.
Our recommendation: choose cloud storage when continuity across people or devices is a defined requirement. For profiles tied to one computer, consider local storage around that machine’s backup and maintenance arrangements. Storage should follow the operating workflow rather than the apparent sophistication of the option.
For example, a saved shop session on a cloud profile can be retrieved as part of a device handoff. A locally stored session remains associated with its original device until the data is moved. The shop still controls the lifetime and verification requirements of its own login session.
Synchronization needs a clear handoff point
Multilogin advises against opening the same profile on multiple devices simultaneously because it can cause synchronization problems. Its stopping procedure is to wait for the loading indicator to finish and for the save confirmation. Official data synchronization checks.
In our same-computer tests, normal stopping and reopening recovered the login, cart, bookmark, and previous tabs. Restoring a profile from the trash bin also returned its saved state. Those operations are documented in the data recovery test.
Our product view is that “saved” is a handoff signal. Users should be able to tell when another person or machine can pick up the profile. Download status, upload status, and which device is using a profile deserve clear presentation in a product built around persistent workspaces.
What value does the design deliver?
Multilogin treats a profile as something you maintain over time. The interfaces provide access to that workspace; storage determines how its working state is retained; member permissions determine who can use it.
For a fixed-computer solo workflow, the value is fast access to the correct saved state. For a distributed team, the design’s value is continuity and controlled handoff. On a restricted network, the extra components also create more connection stages to understand, as our restricted-region case study explains.
Our verdict: the profile-management model is coherent; the component model needs clearer presentation. Four questions should always be easy to answer in the interface: where am I managing this profile, what launches it, where is its data saved, and when is it ready to hand over?
More from the Multilogin review series
- Multilogin Review: Profile Isolation, Fingerprint Stability, and Everyday Use
- Using Multilogin in Restricted Regions: VPN, Agent, and Network Access
- Multilogin Web vs. Desktop: How to Choose Cloud or Local Profile Storage
- Multilogin Profile Isolation and Fingerprint Stability: Defaults, Canvas Noise, and Restarts
- Multilogin Data Recovery Test: Saved Logins, Browser State, and Deleted Profiles