Contact
Request your security briefing.
Send us your domains. We will assess your exposure and deliver a tailored threat report within 48 hours.
Write to [email protected]We don't sell hosting. We operate critical applications on infrastructure where defense is not a layer you add, but the nature of the environment. Built for sectors where failure is not an option.
Animated globe: worldwide traffic from the largest cities, weighted by population, strikes 15 major capitals. Each impact is judged by the WAF and logged with origin, target and decision.
Application firewall, behavioral filtering, DDoS mitigation, kernel-level banning, continuous monitoring and incident response are not products you assemble. They are capabilities of a single environment we operate for you. Every rule is engineered, every session analyzed, every block explained.
Real-time analysis and rate limiting of user sessions. Detects anomalous navigation patterns, automated scraping and data exfiltration attempts.
The WAF layer, engineered around your application logic. Bespoke rules for your threat landscape: block or throttle by country, ASN, cloud provider, ISP or enterprise. One capability among many, not a bolt-on.
Blocks systematic database extraction, even with non-sequential or encrypted IDs. Enumeration patterns are detected regardless of obfuscation: exactly what signature-based WAFs miss.
Every block carries a unique request ID, shown to the end user and logged in NGINX. Any block can be audited down to the exact rule triggered and the full request context.
Full control at your fingertips. Blacklist, whitelist, create, modify or delete any rule in real time through your dedicated management interface. Every change flows through the orchestrator: validated, traced, reversible.
You talk to the engineer who writes your rules. Continuous fine-tuning, threat intelligence and incident response. Not a chatbot, not a ticket queue.
Your application code is read-only for the application itself and writable for you. The lock is enforced by the kernel on the runtime process: an exploit that reaches the application cannot install a webshell, alter an extension or inject pages, because it cannot write. Unlock a directory from your backoffice for the duration of an operation; it relocks itself after one hour, and every toggle is traced. Writable directories, uploads, cache, logs, are defined per profile and never executable.
Partitions encrypted with LUKS2 on request; for data in use, AMD SEV-SNP encrypts your virtual machine's memory against the host, on compatible hardware, from Fortress upward. We say where each stops: LUKS protects the disk, SEV-SNP the memory. Backups are what our restore guarantee stands on: two copies, in two datacenters run by two different providers, encrypted twice before they leave, the volume with LUKS2 and each file with AES. Daily by default with three months of retention, hourly on quotation. Restoration starts within minutes in business hours and completes within about an hour, depending on the volume to restore.
When an application-layer attack saturates the stack, the orchestrator switches the whole chain to under-attack mode: thresholds tighten, filtering turns far more aggressive, and curated whitelists hold. A Stripe webhook or a verified Googlebot still lands at the peak of the storm. Volumetric floods never reach this point. They are absorbed upstream, by hardware mitigation appliances in the datacenter network of our accredited hosting partner, before your server link: the right place for the wrong kind of traffic. Tyrant starts where that layer stops, at the request.
Cloudflare and AWS WAF protect at the network level. Tyrant.sh protects at the application level. Here is why it matters.
Position determines knowledge. A cloud WAF inspects your traffic in transit: anonymous requests, with no idea of what lives behind each endpoint. Tyrant.sh runs on your server, directly in front of your application, tuned by engineers who know your routes, your data model and the cost of every request. That proximity buys a depth of analysis and anticipation that is structurally out of reach for a cloud WAF: every path is classified before the first request ever arrives, sessions are correlated with real application behavior, and an attacker's next move is often predictable. Superior knowledge of your business is not something we bolt on. It is built into where we sit.
That position comes with privileges a cloud WAF will never hold: access to the application source code, to the file system, and to the real logs in both directions. We write to them, injecting the metrics a generic WAF doesn't know it needs. We read them back, mining weeks of live traffic to sharpen and reinforce the rules. Cloudflare strips the volumetric noise upstream; everything that reaches the server is the demanding part, requests that look legitimate and can only be judged with context. That is where Tyrant operates, and the precision shows in the numbers: on high-traffic production sites, we have run entire weeks with over 30% of requests blocked and zero false positives.
Cloudflare is your armored door. Tyrant.sh is the armed guard behind it who checks every ID.
We recommend running Tyrant.sh alongside a network WAF such as Cloudflare for volumetric DDoS protection. Their free tier is sufficient.
Tyrant is not a fail2ban. A fail2ban reads logs after the damage and bans an address once the request has already crossed the web server and the application. Tyrant decides before: at the reverse proxy, in memory, before the backend web server ever starts working, and for banned sources at the kernel, before a connection is accepted. The log pipeline exists, but it feeds analysis and the fleet-wide blacklists; it is not where verdicts are made.
Most WAFs evaluate each rule as a regular expression, one after the other: processing time grows with the rule count, which is why rule sets get capped. Tyrant's engine is built on decision trees. A request walks the tree once, whatever the number of rules and the number of criteria combined in each: method, path, parameters, headers, country, ASN, address history, session state. Thousands of rules, under a millisecond.
No third-party technology in the protection chain: no open-source WAF wrapped in a service, no vendor module we do not control. Every layer, kernel to log pipeline, is ours, written with performance as an obsession and a minimal CPU and memory footprint. Filtering junk traffic relieves your server far more than the processing it adds.
Eliminating unwanted traffic at the gate often removes the need to scale out, avoiding the cost and complexity of multi-server architectures.
Real numbers, measured on your traffic. On some production deployments, filtering junk traffic before it reaches the application has cut compute consumption by an order of magnitude, and with it the saturation incidents that come with unfiltered traffic. Your figures depend on your traffic profile: we measure before and after during the audit, and report both.
Every capability on this page exists somewhere on the market as a separate product: a WAF, an IP ban, a blacklist feed, a file lock. Our value is in none of them taken alone. It is in their vertical integration: proprietary layers from the kernel to the log pipeline, designed together, inside one unified infrastructure that we operate end to end, and that talk to each other permanently.
Each request the reverse proxy rejects costs the address points, whatever the rule that fired. The memory is the address's, not the rule's.
Past the threshold, the kernel drops the address's packets before a connection is accepted: the exploit request it was building up to is never sent, at zero cost to the server.
The log pipeline runs the analyses too heavy for the request path and surfaces ranges, ASNs and patterns, for your environment and for the whole fleet.
A range burned last night is refused this morning, on the first request, before any rule has to recognize a payload.
If an exploit still reaches the application, it cannot write: no webshell, no altered extension, no injected page.
This diagram shows one loop, not the system: the layers and mechanisms you can see in your logs and your measurements. Other layers sit elsewhere in the stack, at points we do not describe in writing, and other mechanisms feed the same loop: an attacker has no business mapping them, and neither does a page. What stays verifiable is the same for every layer, disclosed or not: each block carries its identifier and its rule in your logs.
Bricks bought separately overlap badly and leave seams. Seams are exactly what an attacker looks for.
You will see the integration in your monthly report, through indicators that only exist because the layers talk.
Packets from banned addresses rejected before NGINX, at no cost to the server.
Addresses banned by their own scanning, before their exploit request was ever sent.
Ranges refused because neighbouring addresses attacked, here or elsewhere in the fleet.
Which rule fired, at which layer, for every block, with its request identifier.
Saturated workers, 5xx errors and CPU, measured on your traffic, month after month.
Security by design is not a label here. It is the order in which things were made. The protection was not added to an environment; the environment was designed around the protection. That single decision is why the numbers hold and the false positives don't appear.
Security is the last layer, added once the application already exists. The firewall sees traffic from outside, blind to what each endpoint does. Gaps are the spaces between components nobody designed together.
Defense lives in the kernel, the proxy and the application at once, conceived as one system. The application is hosted within the protection, never in front of it. There are no seams to slip through, because nothing was added after the fact.
This is what regulators mean by security by design, and what GDPR Article 25 requires: protection conceived from the start, not retrofitted. The architecture on the next screen is not a feature list. It is the proof that the environment was designed, from the kernel up, to defend what it hosts.
We map your attack surface, application logic and business-critical flows, and take the baseline measurements.
Deployed on accredited infrastructure and integrated with your NGINX stack. Zero downtime, zero change to your application, Cloudflare compatible.
Custom rules are engineered for your environment and calibrated against your live traffic. Every pattern is validated with your team.
Continuous monitoring, rule updates and periodic threat reviews by the engineer who owns your account.
Tyrant.sh is not a single module sitting in front of a website. It is an 8+1+1 architecture: eight protection modules installed at eight points of the infrastructure, one supply module that keeps them armed, one orchestrator that keeps them coordinated. They interact under an ultra-strict specification covering protocol, traceability, memory footprint, security and performance: a verdict cannot wait, and every decision must be reconstructable.
One job: pull from Tyrant.sh's servers, signed and verified, everything protection consumes, and nothing else. The flow is one way, out of the traffic path.
It sequences the eight modules, watches their health and memory budgets, enforces the specification between them, and rolls out updates without ever interrupting a verdict. It is the one module you can tune, and the single point all tuning flows through.
Enforced by the kernel on the application's own process: to the runtime, its code is read-only; to you, through SFTP, SSH or your deployment tooling, it is writable as ever. Code that runs inside the application cannot lift a restriction placed on its process.
None of it touches your business application: no code change, no SDK, no redeployment, not a single update required on your side, ever. That complexity is ours to absorb, never yours. It is also why Tyrant.sh is deployed exclusively on infrastructure operated by accredited hosting partners: providers vetted for their engineering standards and contractually bound to protect our proprietary technology. Tyrant cannot be downloaded, and it cannot be installed on arbitrary infrastructure. If your application lives elsewhere, the migration to an accredited environment is scoped during the audit. Citadel clients can have a dedicated environment accredited for them.
That is the assumption we build on, and it is why the platform has several safety nets rather than one wall. Vertical isolation keeps a flaw in the application from reaching the system; horizontal isolation keeps a flaw in a system from reaching its neighbours. Each net is designed so that the one above it can be lost without consequence for the one below.
Inside a virtual machine, every component of your application runs in its own Docker container: the web server, PHP-FPM, each database in a container of its own, Redis, Elasticsearch, ClamAV. Every container runs as a non-root user, with its capabilities dropped, a seccomp profile, no-new-privileges and user namespaces, and it sees only the directories its own job needs: the MariaDB container cannot read the site's files, the PHP container cannot read MariaDB's. The reverse proxy itself is containerized; Tyrant's modules run on the host and inside containers, and the kernel module sits on the VM, below everything else. There is no direct SSH access to the virtual machine. Clients who need a shell get an SSH container of their own, with php-cli and Composer, holding the application code read-write, which is how deployments and updates keep working while PHP holds that same code read-only. That container reaches the databases, Redis, Elasticsearch and ClamAV over the network only, according to its configuration, and never sees the database files or their configuration.
Between virtual machines, the rule is one KVM virtual machine per production environment, with its stagings alongside in their own sets of containers, on latest-generation AMD or Intel hosts with NVMe storage and a very low pooling of resources. In Sentinel and Fortress, the physical host is shared between environments, which may belong to the same client or to different ones: each VM has its own kernel, memory and disk, and there is no path from one to its neighbour, in either direction. In Citadel, the physical servers are reserved for one client, and the one-VM-per-environment rule still applies, because the remaining risk, however small, is not one we choose to keep.
This is what the nets are for. Three privilege escalations that put nearly every Linux server on the planet at risk, each with a working public exploit, each used in real attacks: two in the Linux kernel, one in a userland helper every distribution ships. We detail these three because they are the best known; the same test, with the same outcome, has been run on many others since the platform exists, and it is run again whenever a new one appears. Functional exploits of the three, which our teams reproduced on common shared-hosting architectures, there opened the data of every other client on the same machine.
On ours they had no hold, and the reason is the same three times. An exploit is a chain: a foothold, then a primitive, then a capability, then a target. The foothold is not what we count on; an exploit in the application would give one. What the containers withhold is the next link, a setuid bit that elevates nothing, a namespace that cannot be created, a capability that is not there, or the value of the last one, a root that is an unprivileged user on the VM with nothing but its own directories in sight; and whatever survives that is bounded by one virtual machine, which is why the neighbouring environments were never in the picture.
What it is. A local privilege escalation in pkexec, polkit's setuid-root helper, shipped by every major Linux distribution: any local user becomes root. The bug had sat in the code since 2009 and was disclosed on 25 January 2022; it entered CISA's Known Exploited Vulnerabilities catalogue in June 2022 and has been used in ransomware campaigns.
Why it had no hold. Not because the binary was missing: pkexec was there, in the images we tested, and the exploit ran. Its reward was root inside the container, and that root is worth little. Containers run in user namespaces, so container root is an unprivileged user on the virtual machine; it saw the container's own directories and nothing else: not another environment's files, not another container's, not even the list of the VM's users. Today no-new-privileges closes the door one step earlier, since under that flag a setuid binary grants nothing at all, pkexec or another.
What it is. A flaw in the kernel's pipe buffers, from Linux 5.8 onward, that lets an unprivileged local user overwrite read-only files in the page cache and inject code into root processes. Disclosed on 7 March 2022, with public exploits within days; fixed in 5.16.11, 5.15.25 and 5.10.102.
Why it had no hold. Dirty Pipe writes only into the page cache of files the process can open for reading, and a container here can open nothing that belongs to another environment: not its data, not its users, not its binaries. Each environment runs under its own system user, in its own set of containers, with only its own directories mounted; the primitive had no neighbouring file to aim at. On the files it could reach, its own, the classic escalation, rewriting a setuid binary to become root, grants nothing under no-new-privileges and non-root. Measured result: blocked, and no propagation to any other user or environment. The one class of files two environments could ever share, the system files of a common image, holds no data and no user of anyone's; and it is why the virtual machine, one per environment, stays the last net below the containers.
What it is. A use-after-free in the kernel's netfilter nf_tables component, introduced in 2014, giving a local user root. Disclosed on 31 January 2024 and patched in February; a public exploit followed in March with a 99.4% success rate on Debian and Ubuntu. CISA listed it as exploited on 30 May 2024 and confirmed ransomware use in October 2025.
Why it had no hold. The exploit needs an unprivileged user namespace, then a network namespace of its own, to reach nf_tables with CAP_NET_ADMIN. Three links are missing inside our containers. Docker's default seccomp profile allows clone only when the namespace-flag mask is zero, and that mask, 0x7E020000, includes CLONE_NEWUSER; unshare is in the group allowed only with CAP_SYS_ADMIN, a capability our containers never hold, so unshare -U returns "operation not permitted". The documentation's remark that the kernel gates every namespace flag "except CLONE_NEWUSER" describes the kernel, and is exactly the gap the profile exists to close. A network namespace is refused by the same rules, and in the one the container already lives in, CAP_NET_ADMIN is dropped, so nf_tables is out of reach there too. No namespace, no nf_tables, no double free.
The test protocol behind these three statements, kernel, Docker and runc versions, the attacker's starting point, the proofs of concept used and their results, is available during your briefing, under NDA. We would rather be checked than believed.
Sources: Qualys advisory on CVE-2021-4034 · dirtypipe.cm4all.com · Notselwyn's write-up and proof of concept for CVE-2024-1086 · CISA Known Exploited Vulnerabilities catalogue · Docker Engine documentation, seccomp default profile, its source in moby/profiles/seccomp/default.json, and moby issues #42441, #43086 and #49756 on clone and unshare.
We operate critical applications for organizations where a data breach is an existential threat. None of them is named here, and none ever will be: a client of a security company is not a reference to display, it is a target to protect.
Protect online banking portals, trading platforms and payment gateways from sophisticated attacks.
Secure customer portals handling sensitive personal and medical data against enumeration and exfiltration.
Defend patient portals and medical record systems against unauthorized data extraction.
Sovereign protection for government portals and sensitive public-sector web applications.
Shield B2B platforms from API abuse, competitive scraping and credential stuffing attacks.
Protect high-traffic platforms from fraud, multi-accounting and automated abuse at scale.
Not a software subscription. Each tier is a managed environment where your critical application runs, defended end to end. Pricing is transparent, with no hidden fees.
Institutional pricing applies to regulated sectors: banking, insurance, healthcare, public sector. It covers what those clients require beyond the engine itself: compliance documentation, auditor questionnaires and evidence packs, regulatory due diligence, and the recurring audits we commit to honor on their behalf.
Non-institutional pricing applies to organizations outside those sectors. Same engine, same rule sets, same named engineer, same environment: only the compliance workload is absent, because it is not needed. Eligibility is confirmed during the audit.
Every price is a starting price. It covers the base virtual machine, sized during the audit on latest-generation, high-frequency AMD or Intel hosts with NVMe storage and a very low pooling of resources: a vCPU here is physical core time, not a slice of an oversubscribed one. That base is enough for the large majority of applications, institutional ones included. The final price depends mostly on the resources your application actually needs, load and traffic analysed, and is validated with us before anything is deployed. Citadel environments run on physical servers reserved for you.
Staging and pre-production environments cost 15% of the plan price per environment. Branded pages, the block page and the challenge page built to your own design and maintained with the platform: $100 per month per environment. From two production environments, whatever their tiers, each production environment comes with one staging environment at no charge, and the branded pages are included.
One month free on your own application, as a Sentinel environment, in blocking mode, stateless; upgradable to Fortress or Citadel afterwards, and without the compliance work of the institutional tiers. A $500 transfer fee covers the migration in and, if you are not satisfied, the migration back; if you subscribe, it is credited against your first month.
Invoiced in USD from the United Arab Emirates, without VAT, as an export of services. A VAT-registered business in the EU accounts for its own VAT under the reverse-charge mechanism and deducts it in the same return: no cash advance, no foreign VAT to recover.
The same grid as above, one line per tier: mix them freely, a Fortress for the application that carries your data and a Sentinel for the site next to it. From two production environments, each one comes with a staging environment at no charge. Staging is never sold alone: adding one to a tier counts a production environment in that tier, and removing the last production environment clears its staging. Nothing is sent anywhere: the estimate is computed in your browser. Sizing of each environment is established during the audit, not here.
A senior security engineer owns your account end to end: rule design, tuning, monitoring review and incident response. The person who knows your application logic is the person who answers your escalations.
Automated monitoring analyzes verdicts and traffic patterns 24/7 and pages the on-call engineer when something needs human judgment.
No tiers, no ticket roulette. The person who answers is the person who can fix it, backed by Synec's infrastructure practice.
Yes. Tyrant.sh operates behind Cloudflare and is fully compatible with its CDN, proxy and DNS services. IPv4 and IPv6 dual stack are supported. We actually recommend keeping a network WAF such as Cloudflare in front for volumetric DDoS protection: their free tier is sufficient.
Volumetric floods never reach your server. They are absorbed upstream, by hardware mitigation appliances in the datacenter network of our accredited hosting partner, before your server link: the right place for the wrong kind of traffic. A network WAF in front, if you keep one, adds a second layer, which is exactly what we recommend Cloudflare's free tier for. Tyrant starts where those layers stop, at the request: application-layer attacks are its job. The orchestrator switches the chain to under-attack mode and filters far more aggressively, while curated whitelists of ultra-legitimate third parties (Stripe, Google, payment and webhook providers) guarantee that what must never be blocked never is. Your payments keep landing in the middle of the storm.
No firewall blocks what it does not know, ours included. What we do is reduce, layer by layer, the probability that an unknown exploit reaches the application: an attacker's own noise gets the address banned before the payload is sent; a fresh address is still judged on its range, its ASN and its nature; generic attack primitives are recognized without a dedicated rule; and a public exploit against your stack gets a virtual patch before the update is applied. Should something still get through, the filesystem write lock is the next wall: the code is read-only for the runtime, so the exploit cannot install a webshell, alter a component or inject pages. It protects the code, not the data in your database, and the update plan remains the priority; the filtering is what holds during the delay. If the environment is compromised all the same, we clean it and restore it from backup at our expense: two copies exist at all times, in two datacenters run by two different providers, taken daily with three months of retention, hourly on quotation; restoration starts within minutes in business hours and completes within about an hour, depending on the volume.
No. Tyrant.sh is installed directly on your server at the reverse proxy level, which requires full infrastructure access. It is designed for full-stack applications (dedicated servers, VPS, cloud instances) operated through our accredited hosting partners. Hosted platforms do not provide the server-level access required for deployment.
Initial deployment is typically completed within 48 hours on accredited infrastructure. If your application is hosted elsewhere, the migration to an accredited environment is scoped with you during the audit. Tyrant then opens in detect-only mode: verdicts are computed and written to your logs, nothing is enforced. That observation period runs several weeks, long enough for your real usage patterns to surface, including the monthly and seasonal ones. Enforcement is switched on only once those verdicts are confirmed against your own traffic, and tuning continues from there for as long as we operate the environment.
Dubai working days and hours, on the Western calendar: Monday to Friday, 10:00 to 19:00, Dubai time (UTC+4), with the Western working week and its public holidays rather than the local ones. For a client in Paris that is 08:00 to 17:00 in summer and 07:00 to 16:00 in winter; for London, one hour earlier. Outside those hours, the platform does not stop watching: automated supervision runs around the clock, the defenses act on their own, bans, range bans, under-attack mode, whitelists, and so does most of what follows a failure. A database container that crashes at three in the morning is restarted by the orchestrator within seconds; the engineer is alerted all the same, and reads what happened, but the site was already back before anyone had to intervene. The same goes for a stalled process, a saturated PHP pool or a full log partition: recovery is automated first, alerted second, and the human comes third, for what the automation could not settle. Every major anomaly alerts an engineer, at any hour. In Sentinel, engineers do intervene at any hour in practice; what the contract guarantees is the response to incident tickets in business hours, and outside them that intervention is best effort: it usually happens, and it is not promised. In Fortress and Citadel it is promised, around the clock, with a response time and a penalty in the contract. That commitment is the difference between the two tiers, not the watching.
One environment is one application on its own virtual machine: one code base, one database set, one filesystem, one protection profile. The five domains a plan includes are the hostnames that same application answers to, a main domain and its aliases, www and bare, a second TLD, a vanity domain pointing at the same site. Two applications with their own code and their own data are two environments, even if they belong to the same company and sit behind related domains: an extranet and the corporate site, for instance, are two. The estimator counts environments, not domains.
No. Tyrant.sh is an 8+1+1 architecture: eight protection modules communicating under an ultra-strict specification (protocol, traceability, memory footprint, security, performance), plus a supply module that keeps them updated from our servers and a global orchestrator that coordinates and tunes them. Its internals are a protected trade secret. It is deployed exclusively by Synec on infrastructure operated by accredited hosting partners. For Citadel clients, a dedicated environment can be accredited, including for sovereignty requirements.
Yes. Your client backoffice gives you full control to blacklist, whitelist, add, modify or delete any rule in real time, applied through the orchestrator so every change is validated, traced and reversible. You are not expected to use it, though. Rule design, tuning and the resolution of any wrongly blocked request are your engineer's work, carried out in the same backoffice you see, so nothing is decided out of your view. In Sentinel, custom rules are written on request or in response to an incident, within one business day; in Fortress, they are also written on our initiative, from a weekly threat review.
Cloudflare WAF applies generic rules at scale, from outside your infrastructure. Tyrant.sh provides fine-tuned, application-specific protection engineered by people who understand your business logic, and it runs where a cloud WAF cannot: on your server, with full knowledge of what each endpoint serves and costs. We catch what automated WAFs structurally cannot see.
None of them. A fail2ban reads logs after the fact and bans an address once the request has already been served. ModSecurity and its descendants evaluate regular expressions one by one inside the web server. A plugin runs inside the application it is supposed to protect and shares its fate. Tyrant decides upstream, at the reverse proxy and at the kernel, with a proprietary decision-tree engine and no third-party technology anywhere in the protection chain. The log pipeline feeds analysis and the fleet-wide blacklists; it does not make verdicts.
ML-based WAFs generate opaque anomaly scores and cannot understand your business logic. A traffic spike from a marketing campaign looks like an attack to a model. A human who knows your application builds rules that distinguish real threats from legitimate usage, with clear, auditable block reasons instead of black-box scores.
Rarely, and by construction rather than by luck. The default rule set targets the unambiguous: a client asking for password.txt or sitename.zip, or probing admin paths belonging to a technology your stack does not even run. Sitting on the server, with access to the source and the file system, we know what exists and what never did, so those requests are not a judgement call. Every deployment then opens with several weeks in detect-only mode: verdicts are logged, nothing is enforced, and rules go blocking only once your real traffic confirms them. The fine-tuning that follows adds rules for what slipped through; it is not a walk-back of rules that were too aggressive. On high-traffic production deployments, we have run entire weeks with over 30% of requests blocked and not one false positive: none reported by the client, none found in our own review of the verdicts.
When one does occur, the end user gets a block page carrying a unique request ID, with an invitation to pass it to the site's administrators. There is deliberately no contact link on that page: an open channel there collects automated noise, not signal. The same ID appears in your logs, alongside the exact rule that fired and the reason it did. Your engineer traces it, lifts the block and corrects the rule: for your application alone if the case is specific to you, across the whole fleet if the rule is a generic one. Kernel-level bans require sustained hostile volume from a single IP, so reaching one by accident is close to impossible; should it happen, it is lifted from the backoffice.
The pages a visitor may see, the block page and the challenge page, can be built to your own design and maintained with the platform as a template of yours: $100 per month per environment, included from two production environments. For Citadel clients, they also carry no mention of Tyrant.
Yes. Tyrant.sh supports organizations subject to PCI-DSS, GDPR, DORA and regional financial regulations. Compliance documentation and audit logs are available through the backoffice.
At rest, on request and at every tier: partitions encrypted with LUKS2, so that a disk removed, replaced or decommissioned is unreadable without the key, including for a datacenter operator. The trade-off is operational: the volume must be unlocked at each boot, a step we handle, which adds a few minutes to a restart. Backups are encrypted twice, a LUKS2 partition for the volume and AES for each backup file inside it, so a copy that leaves the platform is unreadable on its own; they are kept in two datacenters run by two different providers, daily with three months of retention, hourly on quotation. In use, from Fortress upward and on compatible hardware: AMD SEV-SNP encrypts the memory of your virtual machine against access from the host, which is precisely where LUKS stops. On a running server, the decrypted volume is readable by the system; SEV-SNP is what closes that gap.
Never on this site, in a sales deck or in a case study: a list of protected applications is a map for attackers, and our clients operate in sectors where discretion is part of the defense. References exist, and they are given privately, during your briefing, once we know who we are talking to: with the written consent of the client concerned, asked each time, in the form that client chooses, a peer-to-peer conversation under NDA more often than not. Until then, the proof is your own traffic: the one-month trial below runs Tyrant on your application, every verdict is written to your logs, and you judge on your own numbers.
Yes: one month, free, on your own application and your own traffic. The trial is a Sentinel environment, whatever tier you end up choosing: you can move up to Fortress or Citadel afterwards, but the month itself is Sentinel, and it does not include the compliance work of the institutional tiers, documentation, auditor questionnaires, regulatory due diligence. We move your application to an accredited environment and run Tyrant in blocking mode, stateless: what a rule recognizes is blocked, request by request, and every verdict is written to your logs with its identifier and the rule that fired. The trial does not include what the full version adds on top, address memory, range bans, kernel enforcement, the fleet-wide blacklists and the backoffice; at the end, you receive the report of the month and a simulation of the full version on your logs, so that the difference is a table, not a promise.
The only cost is a transfer fee of $500. It covers the migration in and, if you are not satisfied, the migration back to where your application came from, at no further charge. If you subscribe, the $500 is credited against your first month.
Tyrant.sh is operated by Synec FZCO, a cybersecurity company for sensitive sectors, registered in Dubai Silicon Oasis (UAE) and serving clients in banking, insurance and the public sector. The engineers who operate Tyrant.sh are the engineers who built it.
Contact
Send us your domains. We will assess your exposure and deliver a tailored threat report within 48 hours.
Write to [email protected]