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 |
|---|---|---|
| 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 run inside your own application's Wolverine runtime instead of as a separate service, monitoring that application and nothing else. It keeps its data in a store of its own, mounts its UI under a sub-path (/critterwatch by default) and leaves your routes, handlers and error handling alone. Aimed at the development inner loop; on SQLite it needs no infrastructure at all. Single instance only. Its HTTP API (/api/critterwatch/*) and SignalR hub (/api/messages) stay at the server root, so those two prefixes must be free.
See Embedded deployment.
.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.
- [ ] Database permissions: give the console a dedicated role that owns its two schemas (plus four database-level permissions on SQL Server). It needs DDL rights inside them for as long as it runs, not only at install. See Database Schema and Permissions.
- [ ] 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.
- Database Schema and Permissions: what the console creates, the rights it needs, and SQL scripts for review.
- Health Checks — wiring services to k8s probes.
- Licensing — tiers and license key configuration.