Issue Publishing Aspire Application to Kubernetes: "The endpoint is not allocated for the resource"

[RileySzecsy]

Hello,

I've been using Aspire successfully for local development and recently started exploring deployment to Kubernetes using the aspire publish command.

While the application runs correctly with aspire run, publishing Kubernetes artifacts fails with endpoint allocation errors:

The endpoint tcp is not allocated for the resource "redis-cache"
The endpoint http is not allocated for the resource "wiremock"

What I've Found

I found a few related discussions, but they appear to be focused on runtime scenarios rather than failures during aspire publish:

• The endpoint http/https is not allocated for the resource  #4868
• "System.InvalidOperationException: The endpoint `http` is not allocated for the resource `keycloak-webrtc`." generating manifest #7051

In my case, the application starts and runs locally without issue. The problem only occurs during artifact generation via:

aspire publish -o k8s-artifacts

Scenario

My Aspire application contains:

1. A WireMock container used to mock external dependencies.
2. A Redis cache.
3. An ASP.NET API project that references both resources.

WireMock Configuration

Initially, I encountered issues loading mappings during publish because Kubernetes does not support the local bind mount approach used during development. To work around that, I added conditional configuration:

• Local development uses WithMappingsPath(...)
• Publish mode uses a pre-built image with mappings baked into the container

if (builder.ExecutionContext.IsPublishMode)
{
    wiremockBuilder
        .WithImage("custom-wiremock-image", "001")
        .WithReadStaticMappings();
}
else
{
    wiremockBuilder
        .WithMappingsPath(DirectoryPathUtilities.GetWireMockDirectory("sample-service"))
        .WithReadStaticMappings();
}

This resolved the mappings issue, but I now encounter endpoint allocation errors during publishing.

Where the Error Occurs

The failures appear to be tied to the following endpoint lookups:

var redisEndpoint = redis.GetEndpoint("tcp");
var wiremockEndpoint = wiremock.GetEndpoint("http");

These endpoints are then used when configuring environment variables for the API:

.WithEnvironment(c =>
{
    string redisConnectionString =
        $"{redisEndpoint.Host}:{redisEndpoint.Port},password={redisAccess}";

    c.EnvironmentVariables.Add("cache__connectionString", redisConnectionString);

    c.EnvironmentVariables.Add("externalApi__scheme", wiremockEndpoint.Scheme);
    c.EnvironmentVariables.Add("externalApi__host", wiremockEndpoint.Host);
    c.EnvironmentVariables.Add("externalApi__port", wiremockEndpoint.Port);
});

Question

Is there something different about endpoint resolution during aspire publish versus local execution?

Specifically:

• Are resource endpoints expected to be unavailable during the publish phase?
• Is calling GetEndpoint() in AppHost.cs supported when generating Kubernetes artifacts?
• If not, what is the recommended approach for injecting Redis and WireMock connection information into dependent services when targeting Kubernetes?

AppHost

const string imageRegistry = "some-artifactory";

var builder = DistributedApplication.CreateBuilder(args);

#pragma warning disable ASPIRECOMPUTE003
var registry = builder.AddContainerRegistry("registry", imageRegistry);
var k8s = builder.AddKubernetesEnvironment("k8s")
    .WithContainerRegistry(registry);
#pragma warning restore ASPIRECOMPUTE003

#pragma warning disable ASPIRECERTIFICATES001
var redisAccess = "redis-access";
var redis = builder.AddRedis("redis-cache")
    .WithImageRegistry(imageRegistry)
    .WithComputeEnvironment(k8s)
    .WithDataVolume()
    .WithPassword(builder.AddParameter("redis-cache-access", redisAccess))
    .WithoutHttpsCertificate();
#pragma warning restore ASPIRECERTIFICATES001

var wiremockBuilder = builder.AddWireMock("wiremock")
    .WithImageRegistry(imageRegistry);

if (builder.ExecutionContext.IsPublishMode)
{
    wiremockBuilder
        .WithImage("custom-wiremock-image", "001")
        .WithReadStaticMappings();
}
else
{
    wiremockBuilder
        .WithMappingsPath(
            DirectoryPathUtilities.GetWireMockDirectory("sample-service"))
        .WithReadStaticMappings();
}

var wiremock = wiremockBuilder;

var redisEndpoint = redis.GetEndpoint("tcp");
var wiremockEndpoint = wiremock.GetEndpoint("http");

builder.AddProject<Sample.Api>("sample-api")
    .WithReference(redis, "redis-cache")
    .WithReference(wiremock)
    .WithOtlpExporter()
    .WithEnvironment(c =>
    {
        string redisConnectionString =
            $"{redisEndpoint.Host}:{redisEndpoint.Port},password={redisAccess}";

        c.EnvironmentVariables.Add(
            "cache__connectionString",
            redisConnectionString);

        c.EnvironmentVariables.Add(
            "externalApi__scheme",
            wiremockEndpoint.Scheme);

        c.EnvironmentVariables.Add(
            "externalApi__host",
            wiremockEndpoint.Host);

        c.EnvironmentVariables.Add(
            "externalApi__port",
            wiremockEndpoint.Port);
    });

builder.Build().Run();

Versions

• Aspire.Hosting.AppHost: 13.5.3
• Aspire.Hosting.Kubernetes: 13.5.3-preview.1.26425.3
• Aspire.Hosting.Redis: 13.5.3
• WireMock.Net.Aspire: 1.12.0
• TargetFramework: net10.0

Any guidance would be appreciated.

I'm trying to understand why endpoint resolution succeeds during local execution but fails during aspire publish, and whether there is a Kubernetes-specific pattern that should be used instead.

[Sueun Cho (sueun-dev)]

Publishing a manifest is precisely what #7051's accepted answer addresses, so it applies to the eager-evaluation problem here, not just runtime startup.

GetEndpoint() gives you a reference. Reading its .Host or .Port asks for an allocated value. Keep endpoint.Property(EndpointProperty.Host) and endpoint.Property(EndpointProperty.Port) as expression objects in the environment dictionary. For a combined string, compose them with ReferenceExpression.Create($"{host}:{port}"), not ordinary string interpolation. The same distinction matters in your Redis connection-string construction.

I tested the actual Aspire.Hosting 13.5.3 assembly offline: the eager Host/Port reads threw your allocation error, while the composed expression retained {wiremock.bindings.http.host}:{wiremock.bindings.http.port}. This verifies the expression mechanism, not a complete Kubernetes publish or your WireMock integration.