FAQ
One question per block, the fact before the explanation. AtriShield is an application-layer protection installed at the edge of your server (HAProxy, CrowdSec, AppSec inspection), driven by a console. The answers below describe what ships today; roadmap items are flagged as such.
Filtering runs on your server, at the edge, before your application. Traffic goes through HAProxy at TLS termination, then AppSec inspection and CrowdSec. A blocked request never reaches PHP. No request is sent to an external service to obtain a verdict: the decision is local.
No. AtriShield installs on your server, at the edge, in front of the application. It does not replace a CDN and does not require one. You keep your current host and network chain; inspection is added at the edge, with no detour through a third party to obtain a verdict.
The request is stopped at the edge and never reaches your application. The source IP is banned automatically, for a default of 4 hours, 24 hours for scanners, with no limit for exploits, depending on the profiles. The event is sent to the console: source IP, URI and query string.
Yes. Inspection covers the URL and the body of POST requests, looking for SQL injection and XSS. The payload is analysed on your server, before the application. Nothing is sent to an external service for analysis: the verdict is rendered locally, at the edge of the server.
Legitimate bots are recognised by origin: 2,194 address ranges from Google, Bing, Apple and DuckDuckGo are verified. Payment gateways with published IPs have trusted presets. Other bots are classified from the console; without a stable IP, we rely on the application signature, never on a guessed range.
The latency measurement is being prepared for publication; we do not quote a figure until it is documented. By design, the decision is made on your server, at the edge, with no call to an external service to obtain a verdict: no network round-trip to a third party is added.
AtriShield runs on Debian 11 and 13 and protects the server edge whatever runs behind it: Magento, WordPress, an in-house API, a Linux server. The install mode adapts to how the server receives traffic: assisted, integrated (nginx/Apache) or standalone, detected automatically.
Debian 11 or 13, root access, outbound HTTPS to your console and an enrolment token. The agent installs as a Debian package; HAProxy, the detection engine and WireGuard are pulled automatically by apt. One licence per server. No remote access is opened toward your machine.
The agent installs as a Debian package (apt pulls HAProxy, the engine and WireGuard), then a single enrolment command links the machine to the console and pulls the signed configuration: the auto-installer sets everything up in under two minutes. You then switch to observe mode before enabling blocking.
No. AtriShield sits at the server edge, in front of the application; you touch neither your code nor your templates. The install mode adapts to your entry point (assisted, integrated with nginx/Apache, or standalone). You keep your host; inspection is added at the edge, with no redeployment.
Yes. At enrolment, the `--install-mode` option accepts three values — assisted, integrated, standalone — auto-detected if omitted, depending on how the server receives traffic. The integrated mode fits alongside your existing nginx or Apache; the application port is set with `--backend-port`.
Observe mode is on by default before any blocking: you see what would be blocked before acting. You can simulate rules, then enable protection once the impact is validated. Trusted IPs and legitimate bots, verified by origin, pass through without being stopped.
Payment gateways with published IPs — Stripe, PayPal, Klarna, Postmark — have trusted-IP presets, let through at the edge. When a service has no stable IP, we rely on the application signature rather than guessing a range. You validate the behaviour in observe mode.
Trusted-IP presets exist for payment gateways and services whose IPs are published. You manage them from the console. For a service without a stable IP, no range is guessed: we rely on the application signature. Observe mode lets you verify before activation.
Yes. Legitimate search-engine bots are recognised by origin: 2,194 address ranges from Google, Bing, Apple and DuckDuckGo are verified and let through. Other bots are classified from the console. This weeds out bots impersonating a search engine without penalising your SEO.
It is the default behaviour before blocking. Every request is evaluated and logged without being stopped: you see the real impact on your traffic. You can also simulate rules. Once the impact is validated, you enable protection from the console, by mode and by profile.
If the inspection component stops, the server refuses requests (503) rather than letting them through unchecked. It restarts on its own within seconds, and the console shows the state. The choice is deliberate: when in doubt, close the door rather than open it.
Protection keeps running on your server: the signed configuration already in place stays active. The console is there to drive and supervise, not to render verdicts. Decisions and inspection remain local, at the server edge, independent of the link to the console.
Configuration updates are signed (Ed25519) and pulled automatically every hour from the console. Each package is verified before being applied; any unsigned source is rejected. If verification fails, an automatic rollback restores the previous configuration.
Yes. Sensitive configurations follow a pattern: backup, dry-run validation, atomic apply, health check, then automatic rollback if the check fails. A configuration that does not pass validation is never applied. The state is visible from the console.
The console receives service status, the package inventory and counters. For each blocked request, it receives the source IP, the URI and the query string as received. No full traffic log is collected. Masking those fields is an announced roadmap item, with no promised date.
The console is currently hosted with a cloud provider. A migration to OVH Beauharnois, in Quebec, is under way; we do not communicate a date. The agent talks to the console over an outbound encrypted tunnel; no full traffic data travels over that link.
No one on the Atrilya side has remote access to your server. Agent-to-console communication runs over an encrypted tunnel, initiated by the agent; no remote administration channel is opened toward your machine. The rare local privileged operations go through bounded rights.
The main third party involved is the console host: today a cloud provider, with a migration under way to OVH Beauharnois (Quebec), with no date communicated. Inspection and decisions stay on your server. The list and details are in the documentation provided for your assessment.
The end-of-contract procedure is being documented. The agent installs and removes like a standard Debian package; the configuration and the incident ledger reside on your server. The details of return and deletion are set out in the documentation provided for your assessment.
A data processing agreement (DPA) is provided on request, before signing. It sets out the roles, the data involved — service status, inventory, and for each blocked request the IP, URI and query string — and the hosting of the console. It is provided for your assessment.
AtriShield is not a PCI attestation. Documentation is provided for your QSA: edge filtering, injection inspection, the incident ledger. It serves your assessment and does not replace your compliance process, which remains yours and your QSA’s responsibility.
AtriShield is for web agencies, hosting providers and managed-service providers, as well as stores with managed hosting. It protects the server edge, before the application, for exposed sites: Magento, WordPress, an API or a Linux server. The licence is granted per protected server.
The licence is granted per protected server. Each enrolled server has its own signed configuration and appears in the console. Terms and pricing are not published: they are shared on request, within the pilot program. The tiers are presented without prices.
AtriShield is offered through a pilot program: a first server is installed in real conditions, first in observe mode, to measure the impact before blocking. Terms and pricing are shared on joining. The goal is to validate the fit on your infrastructure.
Tiers differ by hardening level and the profiles applied at the edge. Filtering is set by server mode, tier and hardening profiles, not by a per-rule switch. The details are in the documentation; prices are not published.
A demonstration is requested through the contact form or by email. A technical exchange precedes the installation of a first server in pilot mode, in observe. Terms are shared on joining. The demonstration covers the console and the behaviour of filtering at the server edge.