See Every Flow. Defend Every Network.
Tidegard is an independently engineered open network telemetry, DDoS detection, traffic analytics, and policy-controlled mitigation platform for ISPs, enterprises, data centers, hosting providers, and managed network service providers.
Project status: Development Preview. Phases 0–7 are complete, with real, tested Rust source: collector, aggregator, detector, and incident management with PostgreSQL persistence, a REST API, a CLI, a web NOC UI, Grafana dashboards, notifications, and an approval-gated BGP mitigation lab (RTBH and FlowSpec through GoBGP), off and in dry-run by default. There is no packaged release. See Project Status below before evaluating this as a production-ready product.
Built by WeTechi Solutions.
- Project Status
- What Tidegard Is
- What Tidegard Is Not
- Architecture
- Core Capabilities (Planned)
- Getting Started
- Repository Layout
- Documentation
- Roadmap
- Security
- License
- Contributing
- Support
Development Preview. This repository follows an explicit, phased
delivery model (see ROADMAP.md). Phases 0–7 are merged to
main:
- Phase 0–1: product foundation, clean-room boundary, repository governance and documentation/validation tooling.
- Phase 2–3: IPFIX/NetFlow/sFlow telemetry collector, aggregation, and ClickHouse analytics storage.
- Phase 4: static-threshold detection engine.
- Phase 5: incident management. A seven-state lifecycle that
correlates detections, PostgreSQL persistence with an append-only
timeline and audit trail, the incident manager process, a
REST API and the
tidegardctlCLI. See the Gate 2 assessment. - Phase 6: dashboards, the NOC UI and notifications. Grafana dashboards as code, a read API for traffic, browser sessions, a React NOC UI served by the API, and a notifier for email, Slack, Teams, Telegram and signed webhooks. See the Gate 2 assessment.
- Phase 7: the BGP mitigation lab. RTBH, parent-prefix and FlowSpec mitigations, each requested by one person and approved by a NOC lead. A safety guard with a per-tenant allowlist and hard prefix floors, a kill switch, and a mitigator that alone speaks to GoBGP. Mitigations appear in the API, the CLI, the UI and notifications, and a two-speaker lab in CI proves what an edge router receives. See the RTBH guide and the Gate 2 assessment.
Explicit safety boundaries, current as of this preview:
- No automated mitigation, ever: every announcement needs a NOC lead's approval, and the mitigator may only propose. BGP is off and dry-run is on by default, and nothing is announced until an operator turns both around in the guard file (see Security below).
- Notifications are delivered only to the destinations an operator allows, and every incident message says where its mitigation stands.
- APIs, schemas, and storage architecture may still change.
- Production use is not yet recommended unless explicitly supported by WeTechi Solutions.
There is no packaged release yet — the first runnable component (the IPFIX telemetry collector) shipped in Phase 2, and the repository has carried real, tested source code since.
Tidegard is an independently engineered open network telemetry, DDoS detection, traffic analytics, and policy-controlled mitigation platform. Planned product categories:
- NetFlow / IPFIX / sFlow monitoring
- Network traffic analytics
- DDoS and network anomaly detection
- Incident management
- Grafana dashboards
- BGP RTBH and BGP FlowSpec automation
- Managed DDoS monitoring and policy-controlled mitigation
Full detail: docs/product-charter.md.
Tidegard is not a clone, replica, copy, alternative build, reverse-engineered edition, or replacement edition of any proprietary product, named or unnamed. It is built exclusively from public RFCs, public protocol specifications, vendor documentation, and independently designed schemas and interfaces. See docs/clean-room-boundary.md for the full, binding clean-room policy.
Tidegard is designed as a modular, event-driven platform of 15 logical services (Telemetry Collector, Traffic Aggregator, Direction Classifier, Detection Engine, Incident Manager, Mitigation Controller, Notification Service, Public REST API, Internal gRPC API, Web Application, CLI, Configuration Service, Audit Service, Reporting Service, Backup and Restore Service).
Architecture direction (not yet finalized — tracked via Architecture Decision Records once decided):
A visual architecture diagram will be added once the core service boundaries are implemented (Phase 2–5) — a placeholder link only, no diagram exists yet.
| Area | Summary |
|---|---|
| Telemetry Collector | IPFIX, NetFlow v9/v5, sFlow v5 decoding with template caching and sampling correction |
| Aggregation | Traffic totals across host/network/hostgroup/ASN/exporter/interface dimensions |
| Detection | Static thresholds first, statistical/baseline anomaly detection later |
| Incident Management | Explicit incident state machine with full audit trail |
| Mitigation | GoBGP-integrated RTBH/FlowSpec, dry-run and disabled by default |
| Dashboards | Original Grafana dashboards and a native NOC web UI |
| Notifications | Email, Teams, Slack, Telegram, PagerDuty, generic webhook |
| Multi-Tenancy | Designed in from the schema level, enforced starting v1.1.0 |
Full requirement traceability: docs/functional-requirements.md and docs/non-functional-requirements.md.
There is no packaged release or installer yet. The Rust workspace
(cargo build --workspace, cargo test --workspace) builds and its 531
tests pass locally, but there is no HTTP API, web UI, or CLI to run
against real traffic yet — see
docs/development/local-setup.md for
what you can do today (build the workspace, run the test suite,
preview documentation, run Markdown/YAML validation). Installation
guides for Docker Compose, Kubernetes/Helm, and bare-metal Ubuntu will be
published once the corresponding phase ships a deployable service.
The NOC UI is in apps/web; screenshots and a quick-start walkthrough are not written yet.
tidegard/
├── .github/ CI, issue/PR templates, CODEOWNERS, Dependabot
├── apps/ api and cli (Phase 5); web, the NOC UI (Phase 6)
├── crates/ Rust service crates — 13 populated with real,
│ tested code (see Cargo.toml); the rest remain
│ README-only placeholders for later phases
├── deployments/ docker-compose, kubernetes, helm, systemd — reserved
├── docs/ product, architecture, and operational documentation
├── grafana/ dashboards and provisioning (Phase 6)
├── database/ reserved; incident migrations live in crates/incident-postgres
├── tests/ integration, replay, performance, security, fixtures
├── tools/ flow-generator, flow-replay, diagnostics, migration
├── scripts/ developer/CI helper scripts
├── examples/ example configurations
├── branding/ logos and brand assets
├── mkdocs.yml documentation site configuration
├── Makefile developer task runner (make targets)
├── Taskfile.yml developer task runner (Task targets)
└── prompts/ the governing master prompt for this project
crates/ (13 of them), apps/api, apps/cli, apps/web, tools/flow-replay/ and tools/dashboard-check/ carry real, tested
source (see Cargo.toml's [workspace] members). Every still-empty
directory contains a README.md explaining what it is reserved for and
which phase populates it — see docs/roadmap.md.
Product-foundation documentation set (Phase 0 + Phase 1; the full,
current documentation tree — including Phase 2–7 architecture, ADRs,
and operational docs — is browsable via mkdocs serve or directly under
docs/):
- Product Charter
- Clean-Room Boundary
- Functional Requirements
- Non-Functional Requirements
- Architecture Options
- Technology Options
- Dependency License Matrix
- Commercial Boundaries
- Security Principles
- MVP Scope / Out of Scope
- Risk Register
- Detailed Roadmap
- Acceptance Criteria
- Blocking Questions
- Naming and Branding
- License Recommendation Warning
A browsable documentation site (MkDocs Material) will be published once
hosting is configured; until then, browse docs/ directly or run
mkdocs serve locally per
docs/development/local-setup.md.
See ROADMAP.md for the milestone summary and docs/roadmap.md for full per-phase detail.
See SECURITY.md for how to report a vulnerability, and docs/security-principles.md for the project's threat model and security design principles. Automated BGP mitigation is disabled and dry-run by default at every layer, permanently — this is a hard safety rule, not a configuration default that will change. Since Phase 7 a person may request a mitigation and a NOC lead may approve it. Only an approved one is ever announced, and only once an operator has turned BGP on and dry-run off.
Licensed under the Apache License 2.0 — resolved 2026-08-21 by WeTechi Solutions; see docs/blocking-questions.md (BQ-1) and docs/license-recommendation.md for the full decision record and the fork-risk trade-off accepted knowingly. Contributions are accepted under the same license via DCO sign-off, no CLA — see ADR 0006.
See also NOTICE and docs/dependency-license-matrix.md.
Contributions are welcome once there is code to contribute to. Read CONTRIBUTING.md first — in particular the clean-room and dependency-licensing rules, which are non-negotiable. See also GOVERNANCE.md and CODE_OF_CONDUCT.md.
See SUPPORT.md.
© 2026 WeTechi Solutions. Tidegard, SentinelFlow Engine, and
tidegardctl are original names — see
docs/naming-and-branding.md.