DevOps

HiveCFM has two supported deploy targets, one dev workflow, and one CI pipeline. This page is the honest map of each.

Targets, at a glance

Target	Use case	Where it lives
Docker Compose (native)	Local development on your laptop.	`hivecfm-core/docker-compose.yml` + overlays
Single-VM Docker Compose	Small self-hosted production.	`hivecfm-core/docs/DEPLOYMENT.md` walks through it end-to-end.
Helm chart + Kubernetes	Self-hosted clusters (community path).	`hivecfm-core/helm-chart/`
Azure Container Apps + Azure Pipelines	The managed / cloud target.	`hivecfm-core/azure-pipelines.yml` + `hivecfm-core/docs/azure-environment-setup.md`

No single deploy target is “the one” — the project supports both community self-hosting and the cloud path. Pick the one that matches your ops maturity.

Local development

Docker Compose brings up the full stack (web + hub + Postgres + Redis + MinIO + Superset + MailHog) with a single command:

docker compose -f docker-compose.yml -f docker-compose.dev-ports.yml up -d

The dev-ports overlay exposes postgres:5433 and redis:6380 on the host so you can run the web app natively with hot-reload against containerised services. Full walkthrough: Local dev.

CI/CD

The pipeline is Azure Pipelines, configured in hivecfm-core/azure-pipelines.yml. In one sentence: it builds the web, hub, and docs images, pushes them to ACR (hivecfmregistry.azurecr.io), and rolls the Container Apps revision.

Key build-time notes:

Triggered on pushes to the hivecfm-main branch.
Uses Docker BuildKit with --secret mounts so secrets never land in layers.
Heap limit bumped for the web build: NODE_OPTIONS="--max_old_space_size=8192" (the Next.js build peaks around 8 GB).
Tags each image with $(Build.BuildId) for immutable rollbacks.

Production target — Azure Container Apps

Core and the Hub run as Azure Container Apps in a VNet-integrated environment. Postgres is Azure Database for PostgreSQL flexible server, peered into the same VNet. Nothing is exposed to the public internet except the ingress front door.

Lessons and gotchas (from running the NPRD environment) are captured in:

hivecfm-core/docs/azure-deployment-lessons.md — VNet CIDR pitfalls, subnet delegation rules, Azure policy exemptions.
hivecfm-core/docs/azure-environment-setup.md — step-by-step greenfield setup.
hivecfm-core/docs/nprd-deployment.md — the NPRD-specific playbook.

If you are about to stand up a fresh Azure environment, read those three files first — several of their checklist items cannot be discovered by running the pipeline.

Helm chart (self-host)

hivecfm-core/helm-chart/ contains a Helm v3 chart that packages:

The web, hub, and docs images.
Bitnami postgresql (v16.4.16) as a subchart when postgresql.enabled is true.
Bitnami redis (v20.11.2) as a subchart when redis.enabled is true.

It is the community path for Kubernetes self-hosters. Values are documented in helm-chart/values.yaml; most deployments override at least the image tags, domain names, and secret references.

If you are coming from a .NET deploy shop, think of Helm as “an ARM/Bicep template plus kubectl apply, parameterised”. The chart knows the resource shape; values files know the environment.

Environment matrix

Env	Runs on	Triggered by
`dev`	Your laptop (docker compose).	Manual.
`nprd`	Azure Container Apps (non-prod tenant).	Push to `hivecfm-main`.
`prod`	Azure Container Apps (prod tenant).	Manual promotion from a tagged `nprd` build.

Secrets are read from Azure Key Vault via CSI driver on ACA. The only secrets in the repo are the .env.example placeholders.

Observability and logging

Short version: pino structured JSON logs from core, slog structured logs from the hub, OpenTelemetry metrics + traces from both. Full details in Observability.