Traffic changes fasterthan manual log analysis.
For small teams running NGINX or OpenResty
Respond to anomalous HTTP traffic with limits, rollback, and operator control.
DynoxWall detects anomalies from access logs, lets operators inspect decisions in dry-run, and can apply limited, reversible NGINX actions when live mode is explicitly enabled.
Technical demo and limited pilot stage
Request path and control loop
local NGINX actionHTTP traffic
NGINX / OpenResty
Application
ordinary traffic passes through
access log + traffic signals
DynoxWall anomaly detection
Safety checksprotected target allowlist, scope validation, rate and concurrent block limits, kill switch
temporary blocking rule
audit log
automatic unblock when TTL expires
When manual response becomes hard to time
Aggressive blockingmay damage useful traffic.
Cautious manual actionmay arrive after application resources are exhausted.
The goal is not more aggressive automation. It is automation whose impact can be inspected, constrained, reversed, and stopped.
How it works
DynoxWall runs locally alongside NGINX or OpenResty and works from relevant access-log events.
- 1Observe relevant access-log events.
- 2Detect anomalous HTTP traffic.
- 3Evaluate the decision in dry-run and safety checks.
- 4When explicitly enabled, apply a limited NGINX action.
- 5Unblock automatically or through operator/emergency control, and record the lifecycle.
HTTP traffic
Optional upstream protection
NGINX / OpenResty
Application
Access log -> DynoxWall
Dry-run or limited NGINX action
Operator, audit, and emergency controls
Safety controls
Trust is built from concrete controls, not from a claim that automation is risk-free.
Dry-run
Decisions can be inspected before any live action is enabled.
Protected allowlist
Defined sources or scopes can be protected from automated blocking.
Scope limits
Actions are constrained to the configured traffic scope.
Duration limits
Blocks are time-bounded instead of left open-ended.
Action-rate and concurrent-block limits
The rate and number of active actions are bounded.
Duplicate protection
Repeated attempts to block the same target are guarded.
Automatic unblock
Temporary action can expire without manual cleanup.
Kill switch
Operators can stop live action globally.
Emergency unblock
Operators can remove active blocks through an emergency path.
Audit trail
Decisions and action lifecycle are recorded for review.
Operator flow
Live action remains bounded and recoverable.
Mechanisms implemented and tested; disposable NGINX validation completed; customer production outcome not yet validated
Anomaly detected
Decision and safety checks
Dry-run record
Live action explicitly enabled
Limited NGINX action
Automatic unblock
Manual or emergency unblock
Audit trail
Fit and boundaries
A good fit when
- Linux with NGINX/OpenResty.
- Small team with production responsibility.
- Anomalous HTTP traffic is visible in access logs.
- Incident analysis or mitigation is still substantially manual.
- The team wants to evaluate dry-run before limited live action.
Not the right layer when
- The external link is saturated by volumetric L3/L4 traffic.
- No supported access-log path exists.
- The requirement is a fully managed global scrubbing service.
- Zero operator responsibility or guaranteed zero false positives is expected.
DynoxWall is designed to complement upstream protection, not replace it.
Technical demo
The demo is an isolated technical walkthrough, not a production benchmark or customer case study.
Request a technical demo- 01
An isolated NGINX target.
- 02
DynoxWall in dry-run.
- 03
A controlled HTTP anomaly.
- 04
The decision and safety checks without live impact.
- 05
An explicitly enabled limited action on the test target.
- 06
Automatic or emergency unblock.
- 07
The audit trail and final state.
- 08
The measurements proposed for a separate pilot.
Request a technical demo
The request is reviewed for technical fit. Submission success does not mean the lead is qualified.
Brazilian Portuguese and Ukrainian copy require competent human review before publication.
FAQ
How is DynoxWall different from manual NGINX rate limits and scripts?
It combines anomaly detection, dry-run, safety checks, bounded action, automatic unblock, and audit lifecycle.
Does it replace Cloudflare, AWS Shield, Akamai, or scrubbing?
No. DynoxWall complements upstream protection.
Which traffic scenarios are in scope?
Initial scope includes HTTP flood, aggressive bots, scraping, and anomalous HTTP load visible in NGINX/OpenResty access logs.
What prevents an overly broad or long block?
Safeguards include allowlists, scope/duration/action limits, duplicate protection, auto-unblock, kill switch, emergency unblock, and audit trail.
Can we start in dry-run only?
Dry-run can be evaluated before live mode.
What data does DynoxWall read and retain?
Exact data fields, retention, and network behavior are confirmed before a pilot.
What are the infrastructure requirements?
Current pilot target is Linux with NGINX/OpenResty and relevant access-log access; exact versions, formats, and permissions are reviewed.
What is the current product status?
Technical mechanisms are implemented and tested, but customer production outcome is not validated.
Which product and documentation languages are available?
Product interface and documentation are English; landing locales are English, Brazilian Portuguese, and Ukrainian.
Is there a public price?
No public price exists during initial validation.