Deployment Overview
CritterWatch deploys as two pieces:
Wolverine.CritterWatch— a NuGet package added to each service you want to monitor. No new processes, no new ports.- CritterWatch console — a dedicated ASP.NET Core application that runs the monitoring UI. Single instance.
What you need
| Component | Why | Sizing |
|---|---|---|
| PostgreSQL 14+ | 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. |
| 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. | Single ASP.NET Core process; not currently HA. Run behind a process manager that restarts on failure. |
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.
.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 whenAddTenantis 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.