Environments & Ops Links
The single "where is everything" page. Lists every running environment and the console links for dashboards, logs, uptime, and infrastructure. Start here when you need to look at the health of a deployment.
Environments
| Environment | App URL | Compute | Database | Telemetry labels | SSH |
|---|---|---|---|---|---|
| Prod | app.securityv0.com | Hetzner ash-2 (178.156.245.75) | Atlas M10 — DB sv0_prod (user sv0_prod_app) | — (Atlas-native only, no Alloy) | 1Password root → deploy@178.156.245.75 |
| Dev (Hetzner) | dev.securityv0.com + pr-N-dev.securityv0.com | Hetzner ash-1 (178.156.217.150) | local Mongo container (sv0_platform) | — (no Alloy) | deploy@178.156.217.150 |
| Dev (Azure) | dev-azure.securityv0.com | Azure vm-sv0-dev-1 (rg-sv0-dev, Standard_D2as_v6, westeurope) | local Mongo container (sv0_dev) | cluster=sv0-dev-azure, env=dev | sv0admin@dev-azure-ssh.securityv0.com |
| Staging (Azure) | staging.securityv0.com | Azure vm-sv0-staging-1 (rg-sv0-staging, Standard_D2as_v6, westeurope) | Atlas Flex sv0-staging — DB sv0_staging (user sv0_staging_app) | cluster=sv0-staging-azure, env=staging | sv0admin@staging-ssh.securityv0.com |
Dev is mid-migration (Hetzner → Azure). Both
dev.securityv0.com(Hetzner) anddev-azure.securityv0.com(Azure) currently serve. They are separate hosts with separate databases.Observability coverage: only the two Azure VMs run Grafana Alloy, so logs + host/app metrics in Grafana Cloud come from dev-azure and staging only. Prod and Hetzner dev have no log/metric shipping (prod relies on Atlas-native alerts). SSH to the Azure VMs is via Cloudflare Access — see Reaching the dev VM.
Observability — Grafana Cloud
| What | Link |
|---|---|
| API (RED) — request rate / errors / latency | /d/sv0-api-red |
| Business signals — findings, authority paths, sync age, validator pass rate | /d/sv0-business-signals |
| Workers & queue — queue depth, job throughput / failures / duration | /d/sv0-workers-queue |
| Tenant health (logs) — per-tenant activity / errors / job completions | /d/sv0-tenant-health |
| Logs (Loki) — Explore | /explore → datasource grafanacloud-logs |
| Metrics (Prometheus) — Explore | /explore → datasource grafanacloud-prom |
All three RED/business/workers dashboards have a Cluster dropdown (dev vs staging) so environments are viewed independently.
Quick queries
Pick the environment with the env / cluster label:
# All app logs for an environment
{env="staging", service_name="sv0-api"}
# Errors only
{env="staging", service_name="sv0-api"} | json | level = "error"
# Per-tenant activity (tenantId is a log field, not a metric label)
sum by (tenantId) (rate({env="staging", service_name="sv0-api"} | json | tenantId =~ ".+" [5m]))
# Scrape targets up for an environment
up{cluster="sv0-staging-azure"}
# Request rate
sum(rate(sv0_http_requests_total{cluster="sv0-staging-azure"}[5m]))
Why no per-tenant metrics?
tenant_idis deliberately not a Prometheus label (it would leak the tenant list to anyone who can read/metricsand blow up cardinality). Per-tenant data lives in structured logs (tenantId) and is queried via Loki — that's what the Tenant health dashboard does.
Uptime — Better Stack
| What | Link |
|---|---|
| Monitors dashboard | uptime.betterstack.com |
| Public status page | status.securityv0.com |
Monitored: prod (app.securityv0.com) and Hetzner dev
(dev.securityv0.com) on /api/v1/health + /api/v1/ready, plus dev-azure
and staging on /api/v1/health (their /ready stays behind CF Access).
Health endpoints
GET /api/v1/health returns liveness + build version (no auth, no tenant data).
Use it to confirm a deploy landed — compare the version field (a build tag of
the form <build>-<shortsha>) against your merge SHA.
- app.securityv0.com/api/v1/health —
200 - dev.securityv0.com/api/v1/health —
200 - dev-azure.securityv0.com/api/v1/health —
200(CF Access bypass for this path) - staging.securityv0.com/api/v1/health —
200(CF Access bypass for this path)
Infrastructure consoles
| Console | Link | Notes |
|---|---|---|
| Terraform Cloud | app.terraform.io/app/SecurityV0 | Workspaces: sv0-bootstrap, sv0-shared, sv0-observability, sv0-dev, sv0-staging, sv0-prod. Dashboards-as-code live in sv0-observability (envs/observability). |
| MongoDB Atlas | cloud.mongodb.com | Prod M10 (DB sv0_prod) + dedicated staging Flex cluster sv0-staging (DB sv0_staging). |
| Azure Portal | portal.azure.com | Resource groups: rg-sv0-dev, rg-sv0-staging, rg-sv0-shared, rg-sv0-bootstrap. |
| Cloudflare Zero Trust | one.dash.cloudflare.com | Access apps gating the URLs above. Managed in envs/shared/cloudflare-access.tf. See Access Protection. |
| GitHub org | github.com/SecurityV0 | sv0-platform, sv0-infrastructure, sv0-connectors, sv0-documentation, … |
Related
- CI/CD Operations — deploy workflows, secrets, Cloudflare Pages
- Access Protection (Cloudflare Zero Trust) — how the URLs are gated
- Azure VM Landing Zone — Azure VM access tiers + break-glass
- Deployment Guide — servers, SSH, CI/CD (in sv0-platform)