Deployment Overview

CritterWatch deploys as two pieces:

1. Wolverine.CritterWatch — a NuGet package added to each service you want to monitor. No new processes, no new ports.
2. CritterWatch console — a dedicated ASP.NET Core application that runs the monitoring UI. Single instance.

What you need

Component	Why	Sizing
A database for the console — PostgreSQL 14+, SQL Server, or SQLite	Backs the console's own bookkeeping (alerts, audit log, timeline).	Modest — a small database for most deployments. Don't share it with anything performance-sensitive. The SQLite flavour (CritterWatch.Sqlite) needs no database server at all.
Wolverine transport (RabbitMQ recommended)	Carries telemetry from services to the console and commands back.	Whatever you already have, plus one extra queue (critterwatch).
CritterWatch host	Runs the console process.	A single ASP.NET Core process by default. For HA, run 2+ nodes behind a load balancer with a SignalR backplane — see Clustering.

Your monitored services don't need any new database or new ports — they reuse the Wolverine transport they already have. The console never opens a connection to your services' databases.

Deployment topologies

Standalone server (recommended)

The most common production topology. The console runs as its own dedicated web app on a private network. Operators reach it through a VPN or internal load balancer. Monitored services connect via RabbitMQ.

This gives you:

• Clean separation between the console and the services it observes — a console crash doesn't affect monitored services and vice versa.
• A clear network boundary for authentication and access control.
• Independent deploy/scale schedules.

See Hosting Guide → Standalone Server.

Embedded in an existing application

The console can be embedded as middleware in an existing ASP.NET Core admin app. Useful when you want monitoring co-located with another internal admin tool. Watch for route conflicts — the console mounts at /api/critterwatch/* and /api/messages by default.

See Hosting Guide → Embedded.

.NET Aspire (development)

For local dev and ephemeral environments, .NET Aspire orchestrates the console alongside Postgres, RabbitMQ, and your sample services. The Vue frontend runs as a Vite dev server with hot-reload. See Hosting Guide → Aspire.

Production checklist

• [ ] HTTPS — terminate TLS at a load balancer or directly on the console. Plaintext is unacceptable; the console gives operators significant control over your services.
• [ ] Authentication — UseCritterWatch() does not include auth. Add ASP.NET Core authentication middleware in front. See Hosting Guide → Authentication.
• [ ] Network isolation — the console should not be on the public internet. VPN, allowlist, or private cluster only.
• [ ] TLS on the transport — RabbitMQ should be amqps:// in production. Tenant connection strings travel over the transport when AddTenant is used.
• [ ] Process supervisor — Kubernetes, systemd, or your platform of choice. Restart on failure.
• [ ] Health checks — register a Postgres connectivity check on the console and (optionally) on each monitored service. See Health Checks.
• [ ] License — for Professional / Enterprise features (edit-and-replay, multi-tenant management, batch DLQ ops, etc.), set the license key. See Licensing.
• [ ] Operations gating — for change-freeze windows, flip the global "Operations Enabled" off in Settings. The console becomes read-only.

Next steps

• Configuration Reference — every option and what it does.
• Hosting Guide — the worked patterns for each topology.
• Health Checks — wiring services to k8s probes.
• Licensing — tiers and license key configuration.