Yeeted

HOSTING FOR AI-BUILT APPS

Deploy a C# minimal API on Yeeted

A small slug API as an ASP.NET Core minimal API on .NET 8, with no Dockerfile: Yeeted finds SlugApi.csproj, runs dotnet publish in the .NET SDK image, and starts SlugApi.dll in the ASP.NET runtime image with ASPNETCORE_URLS set to 0.0.0.0 and $PORT.

The API matches the Java and Composer PHP slug examples, so the same smoke script shape verifies each of them. The project references no NuGet packages: the web SDK's shared framework is all it uses.

Tests: ./smoke.sh https://... against a deployment. There is no separate test project, because the generated build publishes the one project it finds and the SDK would compile a test folder's sources into it.

Run locally

Use the .NET 8 SDK. From dotnet/slug-aspnet:

dotnet run --urls http://127.0.0.1:8080

Open http://localhost:8080, or call the API directly:

curl 'http://localhost:8080/api/slug?text=Cr%C3%A8me%20Br%C3%BBl%C3%A9e'

Deploy and verify

Follow the deployment walkthrough. Deploy this folder, SlugApi.csproj, the .cs files and yeeted.yaml, with no database and no Dockerfile. Do not upload bin/ or obj/; the build runs on Yeeted. The manifest selects port 8080 and /healthz.

sh smoke.sh "$PREVIEW_URL"

The script checks the health endpoint, the page, two slugs (one with accents), and that a blank request is refused with 400.

What to change before real use

Keep one .csproj at the root: the generated build publishes the first one it finds and names the entry assembly after it. A solution with several projects, or a separate test project in a subfolder, needs its own Dockerfile. ASP.NET Core features that persist keys, such as cookie authentication or antiforgery, need a key store outside the image, because the deployed filesystem is read-only apart from /tmp.

All examples · Deploy an example