Security

Cliux runs on a single virtual server at Amazon Web Services in Stockholm, Sweden. Every request reaches it through Cloudflare, which terminates TLS at its edge and passes the request on to the server over an encrypted connection, where a reverse proxy hands it to the application. There is no second region and no standby server; if the machine is down, the service is down, which is why the service commitments page promises no uptime figure. Mail to Cliux's addresses is received on a separate mail server at Hetzner Online GmbH in Nuremberg, Germany; it holds messages, not sites or their data.

The database is dumped every night and the last fourteen dumps are kept on the server. Each verified dump is also encrypted and copied to Backblaze B2 under a key that can write but not delete, so a compromised host cannot take the backups with it. Either of two keys can decrypt a copy: one whose private half never touches the server, and a second whose private half is kept on the server so that the monthly restore drill can run unattended. Once a month a script restores the newest off-site copy into a scratch database and compares it with the live one, so the backups are known to restore rather than assumed to.

Console sign-in is handled by Clerk. The passwords that a site's members and a shared preview's visitors set are hashed with argon2id. Every server action and API route that touches a site's data resolves the caller's tenant and refuses a mismatch, and an automated scan of the codebase fails the test suite when a new action skips that check.

Secrets live in the server's environment configuration rather than in a managed vault, database access is held by the one operator, and there is no staging environment. We are one person and one platform server, and we describe it as that rather than as an access-control programme. A support person Cliux names in its own admin console can read a site's data to answer a request about it, and every such read is recorded.

If personal data is lost, disclosed or reached by someone who should not have it, we tell the site owners whose data it is without undue delay, with what we know and what we are doing. Where the law requires, we notify the data protection authority within 72 hours of learning of it (the Personal Data Protection Board in Turkey, and the competent authority under Articles 33 and 34 of the GDPR), and the people affected when the risk to them is high.

Every push to the main branch and every pull request into it runs the linter, the type checker, the test suite, the build, a migration check and a secret scan. Production dependencies are audited on each run; an advisory that no one has reviewed fails the pipeline, and the ones we knowingly carry are listed by name, with the reason and the change that would close each, in the file security/audit-allowlist.json in the repository.

Between August and October 2026 a security specialist working with us ran penetration tests against the platform in several rounds, and we closed most of what they found, though not all of it. That was an internal exercise, not an independent external audit, and it is not a recurring programme; we will say so until it is one.

Card details never reach Cliux. Your plan is paid in Stripe's payment form inside the console, which sends your card details straight to Stripe, and what your visitors pay you goes through Stripe Checkout, or the hosted page of the provider you connect (PayPal, Square, Mollie or Adyen), into your own account, so the card data environment is that provider's rather than ours. The keys you paste to connect one of those providers are stored encrypted and are never shown back.

• No SOC 2 report and no ISO 27001 certificate; we have not been audited against either. If your procurement needs one, we are not the right platform yet.
• No second region, standby server or staging environment.
• No web application firewall or DDoS product beyond what Cloudflare and the host provide by default.
• No bug bounty; we thank researchers, we do not pay them yet.

If you find a vulnerability, write to [email protected], the address our security.txt file gives, or tell us through the contact form. Give us a reasonable time to fix it before you publish anything about it. We answer every report, and we credit researchers who want to be credited.