/drasi

Azure hosting bundle

Use this bundle when Drasi Server is hosted as an Azure workload, especially Azure Container Apps with azd, Bicep, Terraform, or GitHub/Azure DevOps pipelines.

Load this bundle for

• Drasi Server deployment to Azure Container Apps.
• azd provision, azd deploy, Container App revision, image pull, ingress, identity, environment variable, or health-check failures.
• Drasi Server REST API validation.
• Azure production baseline decisions for a new Drasi Server project.

Do not use this bundle for

• Kubernetes-native Drasi resource YAML. Use sources, continuous-queries, and reactions.
• AKS pod-level Dapr or Drasi platform issues. Use operations and, if needed, a Kubernetes/AKS sibling skill.

New-project hosting defaults

Prefer this baseline unless the repository explicitly requires otherwise:

1. Azure Container Apps for Drasi Server with a pinned image tag and digest.
2. Internal ingress by default. Public ingress requires an explicit front door, auth, TLS, rate limit, and logging boundary.
3. Azure API Management, authenticated reverse proxy, or equivalent control for public management API exposure.
4. Managed identity for Azure resource access.
5. Key Vault references or secure secret injection for credentials.
6. Log Analytics, Container App revision diagnostics, and alertable health checks.
7. Environment-separated configuration for dev, test, and production.
8. Explicit CORS configuration only when browser clients are required.
9. No unauthenticated public access to /api/v1/docs/ or /api/v1/openapi.json.
10. No floating latest image tag in production.

Version gate

Before deployment success is reported, capture:

• Drasi Server version.
• Container image reference and digest.
• API compatibility expectation.
• Any provider/plugin versions used by sources or reactions.
• Known pre-1.0 or preview risk.

For production, reject examples that use:

image: ghcr.io/drasi-project/drasi-server:latest

Use a pinned version and preferably a digest instead.

Deployment validation sequence

Run these checks in order:

1. Confirm Azure subscription, resource group, environment, and region.
2. Confirm infrastructure deployment succeeded.
3. Confirm Container App revision is healthy and receiving traffic as intended.
4. Confirm image pull and registry permissions.
5. Confirm environment variables and secret references are present.
6. Confirm ingress is internal or protected by the intended front door/auth boundary.
7. Confirm Drasi Server API surface responds through the intended path.
8. Create or verify at least one source, query, and reaction flow.
9. Confirm downstream side effect from a real or synthetic source change.
10. Capture rollback path and residual risk.

Required endpoint checks

For Drasi Server, validate the management surface through the intended ingress path:

curl -fsS "$DRASI_BASE_URL/health"
curl -fsS "$DRASI_BASE_URL/api/v1/openapi.json" | jq '.openapi // .swagger'
curl -fsSI "$DRASI_BASE_URL/api/v1/docs/"

If the endpoint is intentionally private, run the checks from an approved private network location or through the approved jump path. Do not make the endpoint public just to validate it.

Azure failure triage

Exit criteria

Do not report Azure deployment success until all are true:

• Deployment command succeeded.
• Container App revision is healthy.
• Drasi Server API is reachable through the intended secure path.
• API docs and OpenAPI are protected when exposed beyond a trusted network.
• At least one end-to-end source to query to reaction path is validated.
• Rollback path is documented.
• Version and image evidence are recorded.

Co-skills for Azure-hosted Drasi

Load these before authoring hosting, identity, or deployment manifests. They are co-requisites, not alternatives.

• Azure Container Apps skill, for revision, ingress, managed identity, and environment variable wiring.
• identity-managed-identity skill, for Workload Identity (AKS) or managed identity (ACA) configuration and the common failure table.
• azure-deployment-preflight skill, for Bicep/ARM validation and what-if before deployment.
• azure-defaults skill, for naming, tagging, and region defaults.
• Bicep / Terraform skill, for IaC authoring standards matching the chosen tool.
• event-driven-messaging skill, if the Drasi pipeline uses Event Hubs, Event Grid, SignalR, Service Bus, or any pub/sub reaction.

If a co-skill listed above is not present in the repository, note it as a gap, do not silently proceed.

azd template starter for Drasi Server on Azure Container Apps

Drasi does not (at the check date) publish an official azd template for Drasi Server. Use the following minimal skeleton as a starting point; verify image, env names, and CLI behaviour against current azd and Drasi Server docs before committing to a release.

Repository layout

infra/
  main.bicep              # entry point, parameters: drasiServerImageDigest, location, namePrefix
  modules/
    containerApp.bicep    # Drasi Server Container App with internal ingress + managed identity
    keyVault.bicep        # secrets: source credentials, reaction tokens
    apim.bicep            # public-facing APIM in front of Drasi (optional)
  abbreviations.json
azure.yaml                # azd service definitions
config/
  server.yaml             # Drasi Server config (sources, queries, reactions)
.azure/                   # azd state (not committed)

azure.yaml skeleton

name: drasi-server-aca
services:
  drasi-server:
    project: .
    language: docker
    host: containerapp
    docker:
      remoteBuild: false
      image: ghcr.io/drasi-project/drasi-server@sha256:<digest>

Container App essentials (modules/containerApp.bicep highlights)

• ingress.external: false (internal-only) and front with APIM or Application Gateway for any public surface.
• ingress.allowInsecure: false; TLS terminates at the proxy.
• identity.type: SystemAssigned (or UserAssigned for cross-environment promotion).
• Mount config/server.yaml from a Container Apps secret or a mounted volume; do not bake it into the image.
• Probe /health for liveness; probe /api/v1/sources for readiness only after instance state is restored.
• CPU/memory: start with 0.5 vCPU / 1 GiB for evaluation, then size against the scaling matrix in scaling-and-capacity/guide.md.

Deployment order (matches the non-negotiable rules)

azd env new <env-name>
azd env set DRASI_IMAGE_DIGEST sha256:<digest>
azd provision   # Key Vault, identity, APIM, Container App
azd deploy      # apply the Drasi Server config
# Acceptance:
curl --fail https://<apim-host>/health
curl --fail -H "Authorization: Bearer <token>" https://<apim-host>/api/v1/sources

Record image digest, APIM API version, and APIM policy hash in your release notes. Re-verify the ingress.external, identity, and image Bicep field names against current Microsoft.App/containerApps API versions before merging.

Container Apps plan choice for Drasi Server

Azure Container Apps offers Consumption, Dedicated, and Workload Profile plans. Drasi Server's holding of long-lived source subscriptions makes the plan choice load-bearing.

Non-negotiable settings for production Drasi Server on ACA

• minReplicas: 1 (or higher if HA is required) - never let Drasi Server scale to zero while sources are active.
• maxReplicas: confirm at the pinned release whether multiple Drasi Server replicas can safely share source ownership. If unconfirmed, set maxReplicas: 1 and scale vertically.
• Stable revision mode (revisionsMode: 'Single') unless you have validated multi-revision behaviour with active sources.
• Probes: livenessProbe against /health (NOT /api/v1/health); set initialDelaySeconds high enough to cover source re-acquisition.

Cost notes

Dedicated/Workload Profiles bill per allocated capacity rather than per-second compute. For Drasi Server this is usually cheaper than Consumption-with-minReplicas-1 at any non-trivial scale, because Consumption's per-second pricing is optimised for bursty stateless workloads. Run a one-week cost comparison in non-production before committing.

Telemetry-cost controls

See bundles/observability/guide.md "Telemetry-cost controls" for Log Analytics ingestion, metric cardinality, and trace sampling guidance that complements this hosting baseline.