[Integration Proposal]: Miabi hosting and deployment integration

[axies20]

Aspire issue link

No response

Overview

Miabi is an open-source, self-hosted multi-tenant PaaS with declarative manifests, container deployments, a registry, managed databases, volumes, GitOps, monitoring, backups, and Goma Gateway routing.

This proposal is for a CommunityToolkit.Aspire.Hosting.Miabi integration that treats Miabi as an Aspire deployment target. It would translate the standard Aspire application model into miabi.io/v1 resources and add Aspire publish, deploy, and destroy pipeline steps.

The goal is to let applications use normal Aspire APIs instead of requiring Miabi-specific configuration for every resource. The proposed mapping includes:

• Project and container resources -> Miabi Application
• External Aspire endpoints -> Miabi generated External Access routes
• Named volumes -> Miabi Volume
• Secret parameters -> Miabi Vault references
• Container registry annotations -> remote image names used by Miabi
• PostgreSQL instances and databases -> Miabi managed database resources
• Later adapters for Redis, MySQL/MariaDB, MongoDB, and libSQL
• Standard .WithReference(...) relationships -> connection information supplied to applications without writing credentials to manifests or logs

An experimental implementation is available at https://github.com/axies20/Miabi.Aspire.Hosting. The prototype currently supports applications, image build/push, external endpoints, explicit domains/routes, named volumes, secrets, and deployment lifecycle steps. Managed database translation is the next proposed area.

Because Miabi is a deployment platform rather than a containerized dependency, I would like feedback on whether this integration fits CommunityToolkit.Aspire, the expected initial resource scope, and whether invoking the Miabi CLI from Aspire deployment pipeline steps is acceptable.

Usage example

var builder = DistributedApplication.CreateBuilder(args);

var miabiToken = builder.AddParameter("miabi-token", secret: true);
var registry = builder.AddContainerRegistry(
    "registry",
    "registry.example.com");

var postgres = builder.AddPostgres("postgres");
var database = postgres.AddDatabase("appdb");
var cache = builder.AddRedis("cache");

builder.AddProject<Projects.Api>("api")
    .WithContainerRegistry(registry)
    .WithReference(database)
    .WithReference(cache)
    .WithVolume("app-data", "/data")
    .WithExternalHttpEndpoints();

builder.AddMiabiEnvironment(
    "production",
    "https://miabi.example.com",
    "my-workspace",
    miabiToken);

builder.Build().Run();

The expected workflow would use standard Aspire commands:

aspire publish
aspire deploy
aspire destroy

aspire publish would generate inspectable Miabi manifests. aspire deploy would build and push project images, perform a Miabi dry-run, and apply the desired resources. aspire destroy would remove only resources owned by that deployment.

Additional context

The implementation should be incremental. A reasonable first complete scope would be:

1. Applications and remote container images
2. External HTTP endpoints
3. Named volumes
4. Secret references
5. PostgreSQL instance/database support and .WithReference(...)
6. Idempotent preview, deploy, update, and destroy behavior
7. Unit tests plus an end-to-end PostgreSQL example

Other database engines could be added through internal engine-specific adapters while keeping the public Aspire API unchanged.

Important design requirements are that credentials never appear in generated manifests, command arguments, deployment state, or logs; unsupported resources produce actionable diagnostics; and the generated deployment remains deterministic and reviewable.

Help us help you

Yes, I'd like to be assigned to work on this item.