Deploy a .NET App

Deploy any ASP.NET Core application to Eyevinn Open Source Cloud using the My Apps .NET runtime. No Dockerfile needed — push your repository and OSC handles building and running your application.

Overview

The .NET runtime in My Apps supports ASP.NET Core applications. Push your repository to any HTTPS git host and OSC handles the rest: it builds your project and exposes a public HTTPS URL.

This is part of the My Apps feature — private deployment for code you own, without open sourcing it.

Prerequisites

  • An Eyevinn Open Source Cloud account
  • An ASP.NET Core application in a git repository (public or private) on any HTTPS git host

Requirements for Your .NET App

Your application must:

  • Listen on the port specified by the PORT environment variable
  • Be an ASP.NET Core application

Example:

var builder = WebApplication.CreateBuilder(args);
var port = Environment.GetEnvironmentVariable("PORT") ?? "8080";
builder.WebHost.UseUrls($"http://0.0.0.0:{port}");

var app = builder.Build();
app.MapGet("/health", () => "OK");
app.Run();

Deploy via the Web Console

  1. Go to My Apps in the OSC dashboard
  2. Click Add application
  3. Choose I have a git repository and enter your HTTPS git URL, or choose I need a git repository to have OSC provision one for you
  4. Select .NET as the runtime
  5. Enter a unique application name (alphanumeric only, e.g. mydotnetapp)
  6. For private repositories, provide a git access token
  7. Click Deploy

OSC builds your application and assigns it a public HTTPS URL:

https://<appname>.auto.prod.osaas.io

Monorepo support

If your .NET application lives in a subdirectory (e.g. src/Api), enter the subdirectory path in the Sub Path field. The build runs from that directory instead of the repository root.

Specifying the entrypoint DLL

OSC auto-detects the entrypoint DLL from your build output. If your solution contains multiple projects (e.g. a web API alongside a worker or test assembly), OSC may pick the wrong DLL. Set the Entrypoint DLL field during creation to pin it explicitly:

Field Description
Entrypoint DLL Filename of the DLL to use as the application entry point (e.g. MyApp.Api.dll). Leave blank to use auto-detection. Only applies to .NET apps.

Via MCP (AI Agent):

"Deploy my .NET app from https://github.com/myorg/myapp with entrypoint MyApp.Api.dll"

The create-my-app MCP tool accepts an oscEntry parameter for this purpose.

Updating the entrypoint after deployment

To change or clear the entrypoint DLL on an existing app, use the AI agent:

"Set the entrypoint DLL for my app called myapp to MyApp.Api.dll"

"Clear the entrypoint DLL override for my app called myapp"

The new value takes effect on the next rebuild — triggering a restart alone is not sufficient.

Deploy via MCP or AI Agent

If you have the OSC MCP server configured in your AI tool (Claude Desktop, Claude Code, Cursor, etc.), you can deploy with a natural language prompt:

"Deploy my .NET app from https://github.com/myorg/myapp as a .NET app named mydotnetapp"

For monorepo layouts:

"Deploy the .NET app at path src/Api from https://github.com/myorg/monorepo as a .NET app named myapi"

Environment Variables and Configuration

Using the Parameter Store

The recommended way to supply environment variables to your app is via a Parameter Store (config service). Values are injected at startup — no secrets committed to your repository.

  1. Create a parameter store in the OSC dashboard
  2. Add key-value pairs (e.g. ConnectionStrings__DefaultConnection, MyApiKey)
  3. Bind the parameter store to your app via the Config button on the My Apps dashboard, or ask your AI agent: "Bind the parameter store called myconfig to my app called mydotnetapp"

Troubleshooting

App not starting

Check that your application listens on $PORT. OSC routes traffic to the port defined by this variable. A hardcoded port will cause the health check to fail and the app to appear unavailable.

Build failed

Check the build logs via the AI agent ("Show me the logs for my app called mydotnetapp") or the get-my-app-logs MCP tool.

App works locally but fails on OSC

Ensure your app does not depend on local files or development-only configuration. All runtime configuration should come from environment variables, ideally via the parameter store.

App starts with wrong behaviour or wrong endpoints

If your solution has multiple projects and OSC starts the wrong one, set the entrypoint DLL explicitly. During creation, fill in the Entrypoint DLL field (e.g. MyApp.Api.dll). For an existing app, ask the AI agent: "Set the entrypoint DLL for my app called myapp to MyApp.Api.dll", then trigger a rebuild.