Kolaboro / Trust center
Trust center
Each control below is checked by a machine on every visit, not described by us. You see its status, how old the evidence is and a link to the raw evidence. When evidence is older than its limit, the control shows as stale, even if it passed last time.
Controls mapped to SOC 2 criteria, not audited. Kolaboro holds no SOC 2 report, no ISO 27001 certificate and no other certification. The mapping to the AICPA Trust Services Criteria is our own reading; an auditor could map them differently.
Safe deploys
Every push is checked live, and undone if it breaks
Our site runs on Cloudflare Pages, which sends each push to production at once. Pages has no percentage canary: we cannot send 5% of visitors to the new version first. So we do not claim one. What we do instead:
- Bundle check before the push. Our rule is that worker code is bundled locally before every push, so code that does not build never ships. This is a working rule, not yet enforced by a machine.
- Guard after the push. GitHub Actions waits until /api/open/build reports the new commit, then runs the public smoke checks: key pages answer 200, the API answers with the right shape, a signed answer verifies against our published key, and a real Chromium loads key pages at 1440 and 390 px with no JavaScript errors from our own code, and plain HTTP must redirect to HTTPS with a long HSTS header. Sideways scrolling is reported but does not trigger a rollback.
- Automatic rollback. If the checks fail twice, 90 seconds apart, the guard restores the files changed since the last commit that passed and pushes that as a new commit. Nothing is force-pushed and history is kept. It then waits for the rollback to go live and checks again.
- Public record. Every guarded deploy, failure and rollback drill is written to /data/deploys.json.
The honest limit: between a bad push going live and the rollback going live, visitors can see the broken version for a few minutes. A canary would shrink that; Pages does not offer one.
| When | Commit | Result | Checks | Wait to live | Log |
|---|---|---|---|---|---|
| Loading… | |||||
Rollback drills
The rollback path is tested without breaking production: the guard adds a check that must fail, confirms it is caught, builds the rollback commit for the latest change and checks that it would apply, but does not push it.
- Loading…
Limits
What this page does not prove
- That nobody inside Kolaboro misuses access. Admin access is checked only from outside (headers, no cached data); who holds the admin key cannot be shown publicly.
- That the controls are complete. An auditor tests design and operation over months; this page shows the latest evidence only.
- That the third-party services we rely on (Cloudflare, Supabase, GitHub, Anthropic) are secure. Their own reports cover that.
Found a problem? security.txt has our contact, and Security and your data explains how we handle reports. See also system status, engineering and the public log.