konradcinkusz/deployment-and-platform

Use when provisioning persistent tool-using AI agents on Azure AI Foundry. The Hub/Project/Connection Bicep pattern, per-service managed identity and RBAC including the two-role gotcha where Azure AI Developer alone is not enough, agent-as-code provisioned by a run-and-exit job, azd versus az deployment in CI, GitHub Actions to Azure authentication, and which PR-environment resources are cheap. Getting this wrong looks like a healthy deploy until the first agent-creation call.

Use when running .NET services on Azure beyond AI Foundry. Passwordless SQL end to end, provision-versus-deploy staleness, the permission matrix document, CI credential preflight and soft-delete recovery, storage without keys, model deployments and capacity, and Container Apps manifest idioms and job escape hatches. The unifying rule: managed identity plus RBAC everywhere, and a key or password anywhere in the chain is a finding.

Use when making a service deployable to Fly.io, writing or reviewing a fly.toml, or building the deploy pipeline. Every fly.toml field annotated, the four service shapes (HTTP service, database, frontend, one-shot job), 6PN .internal and .flycast networking, scale-to-zero and when not to, volumes and state, configuration and secrets, the tag-driven pipeline with change detection, bootstrapping a new app, scaling and teardown, and cost.

Use when adding or reviewing a /metrics endpoint, choosing metric labels, or diagnosing a monitoring system that is growing without bound: which labels are cardinality decisions, capping high-cardinality views, exporting the fact that you truncated, and provisioning dashboards from the repository.

Use when giving each pull request its own running environment. Naming as the isolation mechanism, classifying what is shared versus per-PR, the deploy workflow and sticky status comments, teardown that actually tears down, and cost posture. The two hard problems are deciding what is shared and guaranteeing teardown, not deployment itself.

Use when selling or shipping the SaaS as a self-hosted, customer-deployed edition. The vendor-pushes-images / customer-runs-everything responsibility split, the per-client registry, the vendor push-and-stop workflow, the IaC handed over, upgrades and rollback, the one-flag product switch, and the commercial artifacts. A fifth deployment shape alongside the Fly guide's four, with no fork and no vendor production access.

Use when running GitHub Actions on local self-hosted runners instead of GitHub-hosted ones, or when reviewing such a setup. One repository variable (RUNNER_LABELS, a JSON array) switches every job, with cloud as the default; the guard for jobs that need an OS the host lacks; release and secret-bearing jobs that stay on cloud; runner host setup with ephemeral registration and re-minted tokens; concurrency and timeouts; the security rules for running pull-request code on your own machine; operations and the offline-runner fallback; and the agent procedure that writes docs/RUNNER.md.

Use when a service in one system is about to be reused by a second, unrelated system in the estate: publishing it as a pinned image, running one independent instance per consumer with its own database and signing key, and keeping the publish pipeline free of deployment secrets. Not for delivering a whole product to a paying customer - that is private-cloud-delivery.