CloudShell

Disclaimer: Project is in an early phase. This is not a committed product.

CloudShell is a language-neutral, resource-oriented control plane for modeling, running, inspecting, and operating distributed applications in local and self-hosted environments.

It is for developers building local distributed apps, platform teams building self-hosted internal cloud tooling, and extension authors adding resource types, providers, UI, diagnostics, or service integrations. CloudShell gives those users one shared resource graph across code, Resource Manager, the CLI, and the Control Plane API instead of binding the platform to one programming language or one public cloud.

The CloudShell UI is a Fluent UI shell built on CoreShell, the generic shell contribution model for pages, navigation, sections, settings, and extension surfaces. Resource Manager is the first major CloudShell extension in that shell, with an operational experience inspired by the .NET Aspire Dashboard.

Resources view:

Graphs (from UI):

CloudShell preview packages are published to the public CloudShell MyGet feed. They target the .NET 11 preview SDK and are not yet published to NuGet.org as a supported stable release.

Add the preview feed as a package source:

dotnet nuget add source \
  https://www.myget.org/F/cloudshell/api/v3/index.json \
  --name CloudShell

Prerelease versions must be selected explicitly when adding a package, for example dotnet add package CloudShell.AppHost --version 0.1.0-preview.2.

The first CloudShell MVP experience uses the installed CLI, a project-local cloudshell.yaml, and the default development host bundled with the tool at the same version.

Install an explicit preview from MyGet:

dotnet tool install --global CloudShell.Cli \
  --add-source https://www.myget.org/F/cloudshell/api/v3/index.json \
  --version <preview-version>

From a project directory containing cloudshell.yaml, run:

cloudshell run

CloudShell starts in the foreground, applies the YAML resource template, and prints the Resource Manager URL. Host output remains in that terminal until you press Ctrl+C. This MVP command does not use a daemon.

Try the complete ASP.NET Core example in samples/YamlAppHost:

cd samples/YamlAppHost
cloudshell run

Open the printed CloudShell URL, then start YAML Sample API in Resource Manager and open http://localhost:5265.

CloudShell includes built-in application providers for the local-development resource graph. These are not meant to be a complete deployment platform yet; they are the current supported resource types for modeling and running application workloads through Resource Manager, launchers, and the Control Plane API.

• Resource Manager web UI with resource inventory, relationships, actions, endpoints, diagnostics, logs, traces, metrics, monitoring, and activity.
• ResourceDefinition-backed graph declarations through code, templates, CLI, API, and launcher workflows.
• Built-in providers for local applications, containers, SQL Server, RabbitMQ, configuration, secrets, storage, networking, DNS/name mappings, load balancing, identity, logs, traces, and usage.
• Resource-scoped authorization, configurable authentication, and EF Core persistence with SQLite or SQL Server.
• CoreShell-backed extension points for shell pages, navigation, settings, and sections, plus CloudShell-specific extension points for resource providers, Resource Manager UI, diagnostics, runtime adapters, and client helpers.

A CloudShell environment is the managed cloud-like environment for a local, team-owned, or on-premise deployment. It is made up of a Control Plane, installed capability packages, resource state, and one or more UI hosts.

A CloudShell host application is the ASP.NET Core app that composes one deployment. It can host the CloudShell UI, the Control Plane, or both. In local development, a combined host can run programmatically declared resources through the same local Control Plane that manages them.

CloudShell capability packages add environment capabilities. They can contribute Control Plane resource providers, resource type definitions, programmatic declaration helpers, Resource Manager UI support, shell views, and client helpers. The intended distribution model is NuGet packages that expose CloudShell extension registrations for host applications to install.

Resources represent things CloudShell can manage, such as applications, containers, databases, networks, storage, identities, configuration services, and infrastructure components.

See CloudShell Terminology for canonical vocabulary and Resource model for the projected object model, endpoint mappings, and ownership rules.

Providers connect CloudShell resources to underlying implementations such as local processes, Docker, networking systems, or external platforms.

CloudShell provider authoring is currently C#-only. Workloads written in other languages integrate through resource declarations, templates, launchers, or Resource Manager/Control Plane clients that target the same resource model.

Resource groups organize related resources into project boundaries for management, filtering, and authorization.

CloudShell uses the same resource model through code, the Resource Manager UI, and the Control Plane API.

CloudShell resources can be declared from code and then run through the same Control Plane model:

resources
    .AddDotnetProject(...)
    .AddContainerApplication(...)
    .AddVirtualNetwork(...);

Applications, infrastructure, networking, and operational capabilities are represented through the same resource graph. For full launcher examples, see samples/CSharpAppHost, samples/TypeScriptAppHost, samples/JavaAppHost, samples/GoAppHost, and samples/PythonAppHost.

• CloudShell.Hosting: Razor class library for the Blazor shell, layout, static assets, built-in Resource Manager, Extensions, and Observability views.
• CoreShell: framework-neutral shell contribution model for pages, menus, targets, sections, and shell services.
• CoreShell.Blazor: Blazor adapter for CoreShell content and section projection.
• CloudShell.AppHost: combined-host composition helpers that wire the CloudShell UI and Control Plane into one ASP.NET Core process.
• Launchers/: language-specific app-host launcher packages that emit ResourceTemplates and ask the CLI or Control Plane API to apply them.
• CloudShell.Host: development sample host that wires CloudShell UI, Control Plane, and local provider extensions together.
• CloudShell.LocalDevelopmentHost: stable local Control Plane and UI host profile with the built-in provider presets for launcher-based samples.
• CloudShell.Cli: installable .NET tool that carries the same-version default development host and runs YAML app hosts in the foreground.
• CloudShell.ControlPlane: control-plane services, authorization adapters, resource/log stores, and the versioned OpenAPI endpoint module.
• CloudShell.Abstractions: extension SDK, shell contributions, and resource contracts.
• CloudShell.Client: shared SDK client credential primitives.
• CloudShell.ControlPlane.Client: remote domain client for the Control Plane API.
• CloudShell.Configuration.Client: SDK client and IConfiguration integration for Configuration Store service APIs.
• CloudShell.Configuration: service-discovery configuration helpers.
• CloudShell.ConfigurationService: standalone ASP.NET Core configuration service application.
• CloudShell.Secrets.Client: SDK client and IConfiguration integration for Secrets Vault service APIs.
• CloudShell.Persistence: EF Core SQLite or SQL Server persistence for resources and local Identity.
• CloudShell.ResourceModel: Resource model and ResourceDefinition graph contracts.
• CloudShell.ControlPlane.ResourceModel: Control Plane Resource Manager integration for graph-backed Resource model state.
• CloudShell.ControlPlane.Providers: built-in Resource model providers and their Control Plane/runtime adapter integrations.
• CloudShell.ControlPlane.Providers.UI: Resource Manager UI integration for built-in Resource model providers.
• CloudShell.Abstractions.Tests: extension registration and validation tests.

See the project workflow and tracking docs:

• Development workflow: how to make changes in focused, verified slices.
• Changelog: dated implementation, stabilization, sample, and documentation history.
• Architecture decision log: durable product and architecture decisions.

• .NET 11 preview SDK.
• Docker Desktop or a local Docker daemon if you want to use the Docker sample.

The repository includes global.json to pin the preview SDK expected by the project.

From the repository root:

dotnet restore
dotnet run --project CloudShell.Host --urls http://localhost:5088

Then open:

http://localhost:5088

Useful routes:

• /resources: resource inventory and resource groups.
• /resources/add: add a resource by choosing a registered resource type.
• /resources/templates: export and import resource group templates.
• /resources/docker-engine: Docker Engine detail view.
• /extensions: installed extensions and contributed resource types.
• /api/control-plane/v1: versioned Control Plane API.
• <configuration-service-endpoint>/api/configuration/settings?resourceId=...: token-authenticated configuration service API.
• /openapi/control-plane-v1.json: OpenAPI document for generated clients.

Local-development host and launcher samples are also available:

• samples/YamlAppHost: declares an ASP.NET Core app in cloudshell.yaml and runs it with the installed cloudshell tool.
• CloudShell.LocalDevelopmentHost: reusable Control Plane/UI host profile used by launcher-based samples.
• samples/CSharpAppHost: declares a JavaScript app and Configuration Store resource from a C# launcher app, then applies the template through the CLI.
• samples/TypeScriptAppHost: declares the same style of graph from TypeScript using the experimental @cloudshell/local-development package.
• samples/JavaScriptApp: declares a Node.js app resource from a C# launcher and runs it as a local process managed by CloudShell.
• samples/JavaApp: declares a Java app resource from a C# launcher and runs it as a local JVM process managed by CloudShell.
• samples/JavaAppHost: declares a Java app, Configuration Store, and Secrets Vault from a Java launcher source file, then applies the template through the CLI.
• samples/GoAppHost: declares a Go app, Configuration Store, and Secrets Vault from a Go launcher program, then applies the template through the CLI.
• samples/PythonAppHost: declares a Python app, Configuration Store, and Secrets Vault from a Python launcher script, then applies the template through the CLI.
• samples/JavaScriptContainerApp: wraps a JavaScript app as a Dockerfile-backed container app with replica scaling.
• samples/RoboticMowerIoT: declares a robotic mower IoT app from a C# launcher, with a React frontend, a SignalR container backend, Device Registry enrollment, and a simulated mower device.
• samples/CoreShell.FluentUiSample: reference CoreShell-only Fluent UI shell with a sample extension module; use it as the testbed for common shell building blocks before CloudShell-specific integration.
• samples/CloudShell.UiExtensionHost: hosts only the CloudShell UI and a custom UI extension.
• samples/CloudShell.ResourceHost: hosts CloudShell UI and Control Plane together with a sample resource provider.
• samples/ProjectReference: declares two .NET app resources from a C# launcher where one references the other in an Aspire-style dev loop.

dotnet build
dotnet test CloudShell.Abstractions.Tests/CloudShell.Abstractions.Tests.csproj --no-restore

• CloudShell goal
• Why CloudShell
• CloudShell and Aspire
• Domain model
• Launchers and app hosts
• CloudShell Terminology
• System design guidelines
• Roadmap
• Architecture decision log
• Changelog
• Control plane API and generated clients
• Authentication and authorization
• Hosting model
• Localization
• Persistence
• Programmatic resources
• Resource templates
• Built-in resource types
• Application resources
• Python applications
• Configuration services
• Executable applications