How it works
What happens between connecting something and reading a finding
Code projects
A code project, in Audixa Cloud
Connect a repository or upload a ZIP
GitHub through the GitHub App, GitLab or Bitbucket through OAuth, or a ZIP of the code. Access is read-only: contents and metadata.
Verify a domain, if you want live checks
Verification is a DNS TXT record or a file at /.well-known. Until one of those succeeds, we do not send a request to your domain. You can add a domain later, or never.
Run an analysis
A worker in Audixa Cloud copies the code into a throwaway container with networking switched off, runs the checks, and destroys the workspace when it ends.
Each stage below is what the product shows while it runs. There is no invented percentage.
Read the findings, fix, re-scan
Each finding explains what could happen, shows the evidence and the steps to fix it. The next analysis tells you what is resolved, what is still there and what came back.
- Preparing
The repository or ZIP is copied into an isolated workspace. Nothing from it is executed: no install, no build, no scripts.
- Static analysis
Secrets rules and static rules for injection, missing access checks and unsafe payment flows run over the source.
- Dependency analysis
Exact versions are read from lockfiles and matched against published OSV advisories.
- Web configuration
Only for a verified domain: TLS, security headers, cookies, CORS and redirects, over standard HTTP and HTTPS.
- Normalising findings
Results become findings with severity, confidence and redacted evidence, compared with the previous analysis.
- Writing explanations
If AI is enabled, it explains each finding in plain language from the few lines it points at. It cannot add or remove a finding.
Servers and WordPress
A server, with audixa-agent
Install the agent, the Plesk extension or the cPanel/WHM plugin
audixa-agent is a single binary managed by systemd on any Linux server. The Plesk extension and the cPanel/WHM plugin install and run the same agent for you.
Pair it with your organization
The agent shows a short pairing code; you enter it in Audixa. The agent creates its own Ed25519 key on the server and proves it holds it. The private key never leaves the server.
Let it take inventory
The agent discovers the websites on the server and every WordPress installation with its plugins and themes. You do not type them in.
Audits and scans run as jobs
Server audits, WordPress audits and malware scans are queued as jobs. The agent leases them from Audixa over outbound HTTPS and runs them only within the limits below.
The cloud never connects into your server, and the agent opens no listening port.
Findings appear in Audixa and in your panel
The same findings, with the same evidence, in Audixa Cloud and inside Plesk or cPanel. Anything that would change the server waits for your confirmation.
Built to yield
Audixa never overloads your server
- Healthy
- Runs up to 3 jobs at a time, with at most 1 heavy analysis.
- Busy
- One light job at a time. No heavy analysis starts.
- Under pressure
- Starts nothing new and pauses background analysis. Queued jobs wait.
- Critical pressure
- Stops non-critical work immediately.
Server under pressure
Under pressureAudixa has temporarily paused background analysis to protect the server and will start no new work. 3 jobs are waiting and will resume on their own when load drops.
Server resources
Audixa workload
- 0
- Running
- 0
- Queued
- 3
- Waiting for resources
- Site jobs at once
- 0 / 3
- Heavy analysis
- Paused
- Server changes
- Paused
Limits per level
| Limit | Healthy | Busy | Under pressure | Critical pressure |
|---|---|---|---|---|
| Jobs on websites at once | 3 | 1 | 0 | 0 |
| Heavy analyses at once | 1 | 0 | 0 | 0 |
| Changes to the server at once | 1 | 1 | 0 | 0 |
These are hard ceilings enforced by both the agent and the cloud. A policy can lower them, never raise them.
When the level changes
- Busy
- CPU ≥ 60 %, load ≥ 0.7 per core, available memory ≤ 25 %, I/O wait ≥ 15 %, disk free ≤ 15 % or swap > 20 %
- Under pressure
- CPU > 75 %, load ≥ 0.9 per core, available memory < 15 %, I/O wait > 25 %, disk free < 10 % or swap > 50 %
- Critical pressure
- CPU > 90 %, load ≥ 1.5 per core, available memory < 8 % or disk free < 5 %
Measured every 15 seconds from /proc. Any one signal is enough.
- A level is entered as soon as any one signal crosses it, and left only after two consecutive samples below it, so the agent does not flap.
- Every process the agent starts runs at nice 10 and, where available, the idle I/O class.
- A heavy analysis and a change to the server never run at the same time, and two jobs on the same site never overlap.
- Audixa Cloud uses the lower of the agent's reported capacity and its own ceilings, and the agent can still refuse a job at the last moment. A refused job goes back to waiting without using up an attempt.
- A change already past its point of no return is allowed to finish under pressure rather than being killed half way.
Plesk and cPanel
Inside the panel you already use
- Plesk administrator, WHM root or reseller
- Sees the whole server. Can request inventory refreshes, server and WordPress audits, malware scans and backups. Quarantine, restore and unban ask for explicit confirmation.
- Plesk customer or cPanel account
- Sees only their own websites. Can request a WordPress audit or a scan of changed files on them. Nothing server-wide and nothing that changes files.
| Website | WordPress | Findings |
|---|---|---|
| shop.example.com | High· 1 | |
| blog.example.com | No open findings | |
| agency.example.org | No open findings |
Recent jobs
- WordPress audit · shop.example.comRunning
- Malware (full scan) · blog.example.comWaiting for server resources
- Server auditSucceeded
What we promise
Five commitments about your data
- We never execute code from your repository — not a build, not a test, not a package install script.
- The workspace is destroyed when the job ends, whether it succeeded, failed or timed out.
- Your source code is not retained. Findings keep up to three lines of context, with anything secret-shaped redacted first.
- Scan clones stay read-only. We open a pull request only when you ask, and we never merge it.
- From a server, only metadata, versions, hashes, paths, findings and redacted evidence leave. Never whole files, .env files, private keys, database credentials or wp-config.php values.
Why domain verification is mandatory
What happens when an analysis fails
Disconnecting
Find out what a first analysis turns up
Connect a repository or a server, run one analysis, and read the findings. If there is nothing to fix, you will see which checks said so.
No automatic changes to your code or your servers.