Security

Last updated: 6 October 2026

This page describes the security controls that are actually in place on the Faable platform. For GDPR, the DPA and the frameworks your procurement may ask about, see Compliance. If something here is not precise enough for your procurement process, write to support@faable.com and we will answer specifics.

Where your data runs

Faable runs in Europe. This is not a US platform with an optional EU region: there is no non-EU region to fall back to, and your workloads and user identities do not leave Europe.

Third-party services that handle limited operational data — transactional email, error monitoring, payments — are listed in the Privacy Policy, together with the transfer mechanism that applies to each.

Tenant isolation

Customer workloads and the Faable control plane run on separate Kubernetes clusters. The cluster that serves your applications does not host the platform’s own APIs, databases, or credentials — so a compromised workload does not sit next to the control plane.

Within the workload cluster:

• Each application runs in its own pod with its own identity, network configuration, and domains.
• Environment variables and secrets are scoped to the app that owns them; access through the API is bound to the same authorization as access to the app itself.
• Production and staging environments run in separate namespaces with separate credentials.

Traffic protection

TLS everywhere. Every custom domain and every *.faable.link deployment gets a certificate automatically, issued and renewed by the platform. Traffic is served over HTTPS with modern cipher suites; plain HTTP is redirected.

Managed request filtering at the edge. Faable operates a managed Web Application Firewall in front of every application, on every plan. Rules are maintained by us as rulesets applied fleet-wide, so protection improves for all apps without you changing anything:

Matching requests are rejected with 403 at the edge, before they reach your application — so they do not consume your compute, do not keep a scaled-to-zero app awake, and do not appear as load in your app. Each app can add its own rules by path, user-agent or query parameter from the CLI or the dashboard; see the WAF documentation for the rules, what was stopped, and what the firewall does not inspect. The firewall matches path, User-Agent and query parameter name: it does not read request bodies and is not a signature engine such as the OWASP Core Rule Set, so it does not detect SQL injection or cross-site scripting — input validation stays in your code.

Traffic visibility. Every HTTP request to your apps is recorded with its host, status, and timing, which is what drives usage metering and lets us spot abusive traffic patterns per app.

Encryption

• In transit: HTTPS/TLS between clients and the platform, and for connections between the platform and its databases and object storage.
• At rest: platform databases and object storage are encrypted at rest by the underlying storage providers. Backup buckets use server-side encryption.

Backups and recovery

Backups are compressed, encrypted in transit, and stored in a separate account from the running cluster, so losing the cluster does not lose the backups.

Backups protect the platform, not your archival strategy. They exist so we can restore Faable after an infrastructure failure. If your application holds data you cannot afford to lose, keep your own exports — this is also what the Terms of Service say.

Change management and internal access

• All infrastructure is GitOps-managed. Cluster state is declared in Git and reconciled automatically. Every infrastructure change is a reviewable, revertible commit with an author and a timestamp — there is no untracked manual change in production.
• Internal platform configuration is admin-only. Security-relevant resources such as WAF profiles are restricted to platform administrators and service accounts; tenant tokens receive 403 on both read and write.
• Least privilege internally. Staff access is limited to what a role requires, and access to customer data happens only to provide support you requested, to investigate a security incident, or where the law requires it.
• Automated tests gate deployments. Changes to the platform go through automated test suites in CI before release.

Product security features

Reporting a vulnerability

If you find a security issue in the platform, report it to support@faable.com with enough detail to reproduce it. We will acknowledge it, keep you informed while we fix it, and credit you if you want. Please do not run intrusive tests against production or against other customers’ applications — ask us first and we will find a way to test safely.

We do not currently run a paid bug bounty programme.

Reporting abuse

This is different from the section above. A vulnerability is a flaw in Faable. Abuse is something a customer has deployed on Faable — a phishing page, malware, a spam relay, an open proxy, content that infringes someone’s rights. We host applications we did not write, on *.faable.link subdomains and on customers’ own domains, and we act on them when they break our acceptable use policy.

Report it to abuse@faable.com. You do not need a Faable account, and you do not need to be the injured party.

What helps us act fast:

• the full URL or hostname — something.faable.link, or the custom domain;
• what you saw, in one or two sentences, and when you saw it;
• evidence you already have: a screenshot, the response headers, a sample message, the URL that linked to it;
• for phishing, which brand or service is being impersonated.

What happens next. We acknowledge every report, normally within two business days. We verify it ourselves rather than taking it on trust, because a takedown against a legitimate application is its own kind of harm. Where the report is confirmed, our terms let us suspend or remove the content or the account immediately and without prior notice, and we do; we tell the customer what happened and, where the problem can be fixed, how to fix it. Serious or repeated abuse ends the account, and we report it to the competent authorities where that is appropriate.

We also scan deployments automatically for known abuse signatures. That catches the categories we already know about — reports from people who run into something are how we find the ones we do not.

Incident response

If an incident affects the confidentiality, integrity, or availability of your data, we investigate, contain, and notify affected customers without undue delay, with what we know, what we are doing, and what you need to do. Personal data breaches are reported to the supervisory authority within the deadlines set by the GDPR.

Related

• Compliance — GDPR, the DPA, and the frameworks included in Pro
• Privacy Policy — what we collect, why, and for how long
• Terms of Service — acceptable use, liability, termination
• Web Application Firewall — how edge filtering works and how to add your own rules

Last updated on November 7, 2026