Firefox Containers for Developers and Teams: Multi-Account, Privacy, and Session Isolation

Firefox Containers keep different browsing contexts isolated within the same browser window. The default Firefox installation includes "Personal", "Work", "Banking", and "Shopping" containers, but you can create more. This guide focuses on practical workflows for teams, developers, and privacy-conscious users.

What Containers Do

Each container gets its own:

• Cookies: a site you're logged into in Work won't be logged in in Personal
• localStorage and sessionStorage: completely separate per container
• Cache: separate per container (in practice, some disk cache is shared but memory cache is not)
• IndexedDB: separate per container

What containers do NOT isolate:

• Bookmarks (shared across containers)
• Browser history (shared, though you can filter in address bar)
• Extensions (extensions run in all containers but see the container's storage)
• Saved passwords (shared via Lockwise)
• Extensions' storage (extensions store data per-container via contextualIdentities API)

Default Container Setup

Firefox ships with 4 containers accessible via the "+" new tab button drop-down (if Multi-Account Containers extension is installed):

Personal  — Blue dot
Work      — Orange dot  
Banking   — Green dot
Shopping  — Pink dot

Plus "No Container" (default tab behavior).

Installing Multi-Account Containers

The core containers feature is built into Firefox, but the management UI requires the official extension:

1. Install "Firefox Multi-Account Containers" from AMO
2. New tabs now show a container picker
3. Right-click any link → Open Link in New Container Tab

Developer Workflows

Testing Multiple Accounts

The classic use case: testing your app as different users simultaneously:

Tab 1 (Work container): logged in as [e-mail]
Tab 2 (Personal container): logged in as [e-mail]
Tab 3 (No Container): logged out

All three tabs can be open in the same window, each maintaining separate login state.

API Testing with Different Auth Contexts

Container "Dev API": API key for development environment
Container "Staging API": API key for staging environment  
Container "Prod API": API key for production (use with caution)

Each container keeps the API console's authentication separate.

Social Media Isolation

Container "Twitter Work": work account
Container "Twitter Personal": personal account

No cross-contamination between accounts.

Permanent Container Assignments

Assign a site to always open in a specific container:

1. Open the site in the correct container
2. Click the container icon in the address bar
3. "Always Open This Site in [Container]"
4. Future visits automatically redirect to that container

Example: always open github.com in Work container, gmail.com in Personal.

Container-Specific Bookmarks

While bookmarks aren't container-aware by default, you can use the bookmark URL to force a container:

Using ext+container: URLs:

ext+container:name=Work&url=https://github.com/mywork

This opens GitHub directly in the Work container when clicked.

Privacy Use Cases

Tracking Prevention Per Context

Firefox Enhanced Tracking Protection works per-tab, not per-container. But containers provide an additional layer:

• facebook.com in a "Social" container: Facebook's pixels/scripts elsewhere can't match your container's cookies back to your Facebook login cookie (different containers = different cookies)
• Your banking session in "Banking" container: can't be cross-referenced with your "Shopping" container browsing

Compartmentalizing Identity

Container "Real Name": banking, government, medical sites
Container "Pseudonym": forums, social media, niche communities
Container "Shopping": e-commerce (Amazon, etc.) — tracking expected
Container "Research": security research, unfamiliar sites

Sites in "Research" can't track you to your banking container even if they try via cookies.

Firefox Extension Integration

Extensions interact with containers via the contextualIdentities API:

// Get all containers
const containers = await browser.contextualIdentities.query({});

// Create a new container
const container = await browser.contextualIdentities.create({
  name: 'New Project',
  color: 'blue',
  icon: 'fingerprint',
});

// Open a tab in a specific container
await browser.tabs.create({
  url: 'https://example.com',
  cookieStoreId: container.cookieStoreId,
});

Tab Manager & Session Saver can save and restore sessions per-container, preserving container assignments for each tab.

Teams: Separate Test Environments

For QA/dev teams using shared test accounts:

Container "QA Env A": login with test account A
Container "QA Env B": login with test account B
Container "QA Env C": login with test account C

Each team member can test all accounts in parallel without switching users.

Enterprise: Temporary Containers

The "Temporary Containers" extension creates a unique container for every new tab by default — maximum isolation:

• Every tab opened from a link creates a new, ephemeral container
• Containers are deleted when all their tabs close
• No cross-site tracking possible via cookies
• More aggressive than Multi-Account Containers

Use case: maximum privacy at the cost of being logged out everywhere, all the time.

Limitations

• No true isolation for IP/fingerprint: Containers only isolate cookies/storage. Your IP, browser fingerprint, and HTTP headers are the same across containers. Use a VPN or Tor for true network-level separation.
• HSTS bypasses container isolation: HSTS (HTTP Strict Transport Security) is stored in the network stack, not per-container. A site's HSTS state is shared across containers.
• Cache: Browser cache (disk cache) is shared between containers in some implementations. Memory cache is separate.