Build, develop, and host distributed applications
CloudShell was designed for hosting distributed applications from the start. Its Control Plane, provider boundaries, persistent resource identity, and independently deployable Resource Manager are hosting concerns—not additions to a local development dashboard.
The development workflow is equally important. Developers need a well-integrated way to define an application, run it beside the source, connect its services, inspect its resource graph, and diagnose requests across process boundaries. CloudShell uses the same resource model for that workflow and for the standing environment that hosts the application.
The two contexts share an application story, but their trust and operational boundaries change.
| Local development | Shared or self-hosted environment | |
|---|---|---|
| Primary goal | Build, run, inspect, and diagnose an application graph quickly | Operate durable workloads and services for a team |
| Typical application shape | Language-specific project resources or container apps | Container apps and provider-managed services |
| Filesystem trust | The developer controls the host and may authorize local project paths | Users should not select arbitrary paths on the runtime host |
| State | Project-local and disposable by default | Durable Control Plane state and explicit persistence policy |
| Authentication | May be disabled on loopback for a trusted local session | Required, with authorization enforced by the Control Plane |
| Placement | Usually the developer machine and local Docker | Operator-selected hosts, networks, and providers |
Hosting is the architectural foundation
A hosted CloudShell environment has an authoritative Control Plane that can remain available after a CLI, launcher, or developer session exits. Providers materialize accepted resource definitions on configured runtimes. Resource Manager and API clients connect to the Control Plane rather than owning the resource lifecycle themselves.
This foundation is what lets CloudShell grow from a developer-owned process into a team-owned environment with durable state, authorization, provider policy, networking, storage, identities, and operational ownership.
Development: integrate with the code
The current first-run experience is cloudshell run with a project-local cloudshell.yaml. The CLI starts the bundled local host, applies the template, and keeps the environment tied to the terminal session.
Language-specific resources—JavaScript, Java, Go, Python, .NET, and executable apps—can point at trusted local source. This enables short edit-and-run cycles while still providing resource relationships, configuration, endpoints, lifecycle, logs, health, and telemetry. The goal is not merely to start several processes; it is to give application code and tools a coherent integration surface for the complete distributed application.
Hosting: narrow the trust boundary
A shared host should prefer container apps for application workloads. Images provide a clearer artifact, filesystem, placement, and isolation boundary than a user-supplied path on the host. Host-run language resources should only be enabled when the operator deliberately supports trusted artifact or path-based workflows.
A standing environment also needs durable persistence, authentication, provider configuration, backups, network policy, and operational ownership. CloudShell does not create those policies merely because the local and hosted resource types look similar.
Host settings that enforce the boundary
Three settings are especially important when moving beyond a developer-owned host:
ApplicationResources:HostRunResourceTypesEnabledcontrols whether executable, .NET, JavaScript, Java, Go, and Python process-backed resource providers are installed. A hosted profile should normally leave them disabled.ResourceManager:AllowLocalPathResourceDefinitionscontrols whether applied definitions may select project paths, executable paths, scripts, working directories, and build contexts on the host filesystem.DeploymentArtifacts:Enabledcontrols the host-managed artifact upload and revision path for application resources. Enabling it also requires an artifact store.
These are host policy, not fields in an application template. A launcher can describe a project path for a trusted local profile; it cannot make an arbitrary remote host accept that path.
Combined and split hosting
The local profile normally combines Resource Manager and the Control Plane in one process. A shared installation can separate the UI from the Control Plane: the UI becomes a client, while the Control Plane remains authoritative for resources, providers, authorization, operations, logs, traces, and persisted state.
Splitting the processes does not create another resource model. Templates, launchers, the CLI, and Resource Manager still target the same Control Plane contracts.
Move without changing the application story
The transition is usually from a language-specific local resource to a container app, not from one product model to another:
- Model dependencies, endpoints, configuration, secrets, and telemetry locally.
- Package the workload as an image.
- Express it as an
application.container-appresource. - Apply the template to a compatible hosted environment.
- Let that environment's providers resolve placement, networking, identity, storage, and runtime behavior.
CloudShell is in preview. Remote hosting, provider parity, deployment promotion, and clustered Control Plane behavior are still evolving; validate the capabilities of the target environment before treating a local template as a production deployment definition.
If you are evaluating an application orchestrator rather than a standing environment, see CloudShell and Aspire for a technical comparison of their operating boundaries.