Backends

Backends control which infrastructure and transport RemoteMux uses. The core model stays the same: one environment per project directory, /workspace as the remote root, tmux-backed workspaces, and named workspaces for parallel work.

Compare The Backends

Backend	Who owns the cloud	User auth	Attach transport
`aws`	Your AWS account	AWS credentials	AWS SSM Session Manager
`gcp`	Your GCP project	`gcloud` auth or a credential file	`gcloud compute ssh`
`e2b`	Your E2B account	E2B API key	E2B PTY API
`managed`	RemoteMux control plane	RemoteMux OAuth or service token	E2B PTY API

Which One To Pick

I want direct control of my AWS infrastructure
My org is already on GCP
I want fast, sandboxed environments
I want the fewest moving parts for users

Choose aws. Provisioning, credentials, and runtime resources stay in your AWS account. RemoteMux orchestrates through the hosted control plane.

Choose gcp. Keeps the workflow aligned with gcloud, Compute Engine, and GCP-native networking.

Choose e2b. Lightweight E2B sandboxes with API-key auth. No cloud account needed.

Choose managed. Users only need RemoteMux auth and a project directory. Operators own the cloud complexity.

Backend Guides

AWS BYOC

Direct AWS ownership and AWS-native auth.

GCP BYOC

Direct GCP ownership with gcloud.

E2B

Sandbox-backed runtimes with API-key auth.

Managed Cloud

Operator-owned infrastructure and the simplest user setup.

Last modified on April 9, 2026

Getting Started

Core Concepts

Guides

Reference

Backends

Compare The Backends

Which One To Pick

Backend Guides

AWS BYOC

GCP BYOC

E2B

Managed Cloud

​Compare The Backends

​Which One To Pick

​Backend Guides

AWS BYOC

GCP BYOC

E2B

Managed Cloud

Compare The Backends

Which One To Pick

Backend Guides