Get Started
Open source · MIT licensed

Coconut Sharp Aspire
Aspire, all the way to Azure.

An opinionated application and deployment layer on top of .NET Aspire. Every Aspire API keeps working exactly as it does today. Coconut Sharp adds publish environments, a real identity model, and a deployment path directly onto Azure App Service, with no container registry required.

Explore the packages
No container registry
Deploys directly to App Service
.NET 10 · Aspire 13.5
How it fits

A thin layer, not a fork.

Coconut Sharp does not re-model resources and does not replace service discovery, orchestration, the dashboard, or publishing. CoconutSharpApplication.CreateBuilder returns a full IDistributedApplicationBuilder, so an existing AppHost keeps every line it already has.

Everything Coconut Sharp adds is expressed through native Aspire mechanisms: execution context, Azure environments, provisioning resolvers, and compute environments.

  1. Your AppHostCoconutSharpApplication
  2. .NET AspireApplication and resource model
  3. Coconut Sharp AspireEnvironments, identity, targets
  4. RunLocally, with Aspire
    PublishAzure App Service
See it in code

A Coconut Sharp AppHost.

The builder is a normal Aspire IDistributedApplicationBuilder. Environments, the App Service target and identity are all declared on top of it, in the same file as the resources they describe.

var builder = CoconutSharpApplication.CreateBuilder("MyApp", args);

builder.OnPublish(publish =>
{
    publish.Environment("Staging", env => env
        .UseResourceGroup("MyApp")
        .UseAppServicePlan("SharedPlan", isLinux: false, resourceGroup: "plans-rg"));

    publish.Environment("Live", env => env
        .UseResourceGroup("MyApp")
        .UseAppServicePlan("SharedPlan", isLinux: false, resourceGroup: "plans-rg")
        .UseManagedIdentity("myapp-live-identity"));
});

var api = builder.AddProject<Projects.Api>("api")
    .WithExternalHttpEndpoints()
    .OnPublish(publish =>
    {
        publish.UseAppService("MyApiSite");
        publish.Environment("Staging", env => env.UseSlot("staging"));
        publish.Environment("Live", env => env.UseProductionSlot());
    });

var web = builder.AddProject<Projects.Web>("web")
    .WithReference(api);

builder.Build().Run();
The reason it exists

Deploy directly to Azure App Service. No container registry.

Aspire's own Azure App Service integration is container based: it builds a Linux image and runs it through App Service Site Containers, with no supported way to opt out. That requires a container registry, and it rules out a Windows App Service Plan entirely. Coconut Sharp adds an independent target for exactly that case.

Container based

Aspire's App Service integration

  • Builds a Linux container image
  • Needs an Azure Container Registry
  • Needs a container build wherever you publish from
  • Cannot run on a Windows App Service Plan
Coconut Sharp classic target

UseAppService

  • dotnet publish, deployed directly onto the site
  • No registry and no Docker anywhere in the pipeline
  • Runs on the App Service Plan you already pay for, Windows or Linux
  • Deployment slots and swaps work the same way

Nothing is created behind your back.The App Service Plan is never provisioned by Coconut Sharp. Every environment references one that already exists, so no new billable resource appears because of a deploy.

An existing site is never rewritten.The classic target deploys through the Azure CLI rather than ARM, so custom domain bindings, certificates and slot configuration are left untouched. Application settings and site configuration are the only things brought in line with the AppHost.

Deploying is always deliberate.The deploy step is anchored to deploy, so running the application locally and a plain publish never push code anywhere.

What it adds

The parts every serious deployment ends up writing by hand.

Each of these is configuration an application normally spreads across scripts, pipelines and secrets. Coconut Sharp keeps them in the AppHost, next to the resources they describe.

01

Run and publish, separated

Local defaults and deployment configuration are declared apart, so neither can ever leak into the other.

02

Free-form environments

Dev, UAT, Live, prod-eu-west: the names are yours, and each carries its own subscription, resource group, region and identity profile.

03

Predictable resource names

Generated names stay stable across publishes and unique across environments, through Azure Provisioning's own naming pipeline.

04

Identity without secrets

Managed identity, external connection strings and Key Vault secrets are one model, and connection strings never land in source.

05

Existing Azure resources

An environment can consume infrastructure that already exists instead of provisioning a parallel copy of it.

06

Local defaults that stay local

Storage and Cosmos run as emulators with persistent development data and no cloud dependency at all.

On nuget.org

Two packages, and the documentation that ships inside them.

Each package page reads its version and README straight from nuget.org, so what you see here is what the published package actually contains.

AppHost layer

CoconutSharp.Aspire.Hosting

Opinionated application and deployment layer on top of .NET Aspire. Run locally with Aspire, publish with CoconutSharp.

Version
1.0.1
Framework
net10.0
License
MIT
  • Run and publish configuration kept apart, so local development never carries cloud settings.
  • Free-form publish environments, each with its own subscription, resource group, region and identity.
  • Deploys directly to Azure App Service, with no container registry required.
  • Managed identity, external connection strings and Key Vault secrets as one identity model.
dotnet add package CoconutSharp.Aspire.Hosting
View Package nuget.org
Interactive console

CoconutSharp.Aspire.Launcher

A launcher for CoconutSharp applications: run locally, preview, publish artifacts, or deploy, then drive the Aspire CLI. Deliberately has no Aspire dependency.

Version
1.0.1
Framework
net10.0
License
MIT
  • One console entry point that asks what to do, then hands off to the Aspire CLI.
  • The AppHost it publishes comes from an ordinary project reference.
  • Confirms the Azure account and environment before anything is deployed.
  • Deliberately carries no Aspire dependency of its own.
dotnet add package CoconutSharp.Aspire.Launcher
View Package nuget.org
Run versus publish

Local development and cloud deployment never share configuration.

Local execution is not an environment. Dev is a real cloud environment, exactly like Staging and Live, and never a name for running the application on your machine.

  1. 01

    Run

    Aspire handles local execution. Coconut Sharp supplies local defaults, emulators with persistent development data, and publish configuration is never applied.

  2. 02

    Publish

    The environment is selected at publish time. Each one carries its own subscription, resource group, region, resource naming and identity.

  3. 03

    Deploy

    The launcher confirms the Azure account and lists every configuration change before anything is applied, then hands off to the Aspire CLI.