1. Where we stand
The platform holds no SOC 2 report and no ISO 27001 certificate today, and we do not describe our practices as equivalent to either. If your procurement process requires certification, we do not meet it yet, and you should know that now rather than after an evaluation.
What follows is what is built and running today.
2. Isolation between environments
Each environment has its own PostgreSQL database, its own storage volume and its own deployment, with its own credentials. There is no shared application process between two customers.
A neighbouring environment failing, being restored or being deleted does not affect yours. Deleting one environment does not touch the storage of another, including a copy duplicated from it.
3. Encryption and secrets
Public traffic is served over HTTPS from the moment an environment is created, using certificates managed by the platform. Plain HTTP is redirected.
Repository credentials are encrypted at rest and used only to read the branch being built. Platform secrets are held as Kubernetes secrets, are not part of application configuration, and are never returned by an API.
4. Access control
Permissions are role-based and can be scoped to a single instance or a single environment rather than to the whole team, so a contractor can be given exactly one environment.
Changes to team membership take effect immediately rather than at the end of a cache window — a revoked permission is a revoked permission.
Administrative actions are recorded in an audit log with who did what and when.
5. Authentication
Identity is handled by Keycloak, and passwords never reach the application. Sessions are cookie-based and expire.
Keycloak supports multi-factor authentication; whether it is enabled and enforced is a configuration decision of whoever operates this deployment. Ask before assuming it is on.
6. Backups
Backups run according to the plan and are stored in object storage separate from the running environment. Restoring is always customer-initiated, in one of two forms: restoring in place overwrites the environment, and a safety backup is taken before it does; cloning to a new environment leaves the source untouched.
A restore only moves forward across PostgreSQL major versions. Verify a restore before you depend on it.
7. Logs and monitoring
You can read your own environment logs and resource metrics from the interface. They are yours; we use the same signals to operate the platform and investigate incidents.
8. Updates
Base images are rebuilt and published, and you choose when to deploy a new one — an update is not applied under you while you are running.
The consequence is that staying current is a shared responsibility: we publish, you deploy. A security-relevant image is announced as such.
9. Reporting a vulnerability
Write to the security address on the contact page. Include what you found, how to reproduce it, and what an attacker could do with it. A machine-readable copy of this contact is published at /.well-known/security.txt.
We acknowledge reports as quickly as we can and prioritise them above other work. We will tell you what we found, what we changed, and when — and we are happy to credit you unless you prefer otherwise.
10. Good-faith research
If you follow the rules below, we will treat your research as authorised, and we will not pursue or support legal action against you for it. This commitment matters more than it looks: without it, the rational move for someone who finds a flaw is to say nothing.
- Test only against environments you own or have written permission to test.
- Do not access, modify or retain another customer's data. If you reach some by accident, stop, and tell us what you saw.
- No denial of service, no load testing, no spam, and no social engineering of our staff or our customers.
- Give us reasonable time to fix the issue before making it public.