Skip to main content

Deploy anything

TL;DR — Tell @git-ape what you want, in plain language. Or hand it a reference architecture link, diagram, or screenshot. Either way, it generates a CAF-compliant ARM template with security, cost, and policy enforced before deployment.

Git-Ape is workload-agnostic. If Azure Resource Manager can deploy it, the agent can generate it — using the live Azure REST API specs at generation time, not last year's module catalogue.

Three ways to describe what you want

InputExample prompt
Plain intent@git-ape deploy a .NET web app with SQL Database for the customer portal in dev
Reference architecture@git-ape implement this reference architecture: https://learn.microsoft.com/azure/architecture/reference-architectures/...
Diagram or pictureAttach a PNG or markdown with mermaid, then: @git-ape deploy what's in this diagram for the payments-api project

The agent reads the input, asks clarifying questions only when needed (region, environment, project name), and produces a full deployment plan you can review before approval.


Example 1 — Web app with SQL Database

A common full-stack pattern: App Service with managed identity to SQL Database, secrets in Key Vault.

Prompt:

@git-ape deploy a .NET web app with SQL Database and Key Vault
for the customer-portal project in dev, eastus

What you get:

ResourceKey settings enforced automatically
App ServiceHTTPS-only, TLS 1.2, managed identity, FTP disabled
SQL ServerazureADOnlyAuthentication: true — no SQL username/password
SQL DatabaseStandard S1, geo-backup enabled
Key VaultRBAC authorization, soft-delete + purge protection
RBACApp Service → SQL DB Contributor, App Service → Key Vault Secrets User

Example 2 — Container Apps

A containerised microservice with auto-scaling, private registry, and centralised logging.

Prompt:

@git-ape deploy a Container App with Registry and Log Analytics
for the payments-api project in dev, eastus

What you get:

ResourceKey settings enforced automatically
Container AppMin replicas: 0, max: 10, scale on HTTP concurrency
Container Apps EnvironmentConnected to Log Analytics workspace
Container RegistryAdmin user disabled, managed identity pull only
RBACContainer App → AcrPull on registry
Log Analytics30-day retention

Example 3 — AI knowledge-base service

A retrieval-augmented AI service: Azure OpenAI for embeddings and chat, Azure AI Search as the vector store, behind a Function App API.

Prompt:

@git-ape deploy a knowledge-base API: Function App + Azure OpenAI
+ AI Search for the kbai project in dev, eastus

What you get:

ResourceKey settings enforced automatically
Function AppFlex Consumption, identity-based AzureWebJobsStorage, HTTPS-only
Azure OpenAILocal auth disabled, public network access locked down
AI SearchIdentity-based auth, free-tier blocked, semantic ranker available
Storage AccountallowSharedKeyAccess: false, TLS 1.2 minimum
RBACFunction App → Cognitive Services OpenAI User on OpenAI, Search Index Data Reader on Search

Example 4 — Streaming data platform

Real-time ingestion to a data lake: Event Hubs receives events, Stream Analytics shapes them, ADLS Gen2 stores the curated stream.

Prompt:

@git-ape deploy a streaming data platform: Event Hubs + Stream Analytics
+ ADLS Gen2 for the telemetry project in dev, eastus

What you get:

ResourceKey settings enforced automatically
Event Hubs NamespacedisableLocalAuth: true, TLS 1.2 minimum, zone-redundant where SKU supports
Stream Analytics JobSystem-assigned managed identity for both input and output
Storage Account (ADLS Gen2)Hierarchical namespace enabled, allowSharedKeyAccess: false
RBACStream Analytics → Azure Event Hubs Data Receiver on Event Hub, Storage Blob Data Contributor on ADLS
Log AnalyticsDiagnostic settings wired to namespace and job

Use a reference architecture as the source of truth

The Git-Ape Vision describes a future state where governed documents — reference architectures, ADRs, security baselines — become the ledger that drives deployments. The agent's job is to compile those documents into compliant infrastructure.

You can do this today:

  1. Point the agent at a published Azure reference architecture URL. The agent fetches it, identifies the resources, and produces an ARM template that matches.
  2. Attach a diagram or screenshot of an internal architecture pattern. The agent reads the boxes and arrows and proposes a deployment.
  3. Reference an Architecture Decision Record (ADR) in your repo. The agent treats the ADR as authoritative and validates the generated template against it.
@git-ape deploy this reference architecture for the order-api project, dev:
https://learn.microsoft.com/azure/architecture/reference-architectures/...

Whatever you use as input, the agent produces the same artifacts: a CAF-compliant ARM template, a security analysis, a cost estimate, and a deployment trace under .azure/deployments/ — your auditable evidence of intent → plan → outcome.


What happens after you approve

See the full lifecycle in State Management and CI/CD Pipeline.