The security review, answered
These are the 19 questions a reviewer asks first. Each has our answer and a link to the page that owns it. 9 answers are a plain no.
Ask, and read the answer
Each answer is printed as a word, not a colour. Each owner page has the full detail. We do not claim any compliance standard.
Who has access
- Yes
Is production limited to named principals?
4 principals hold a key: your team, CustomHosted engineers, the deploy pipeline, the CodeHerder agent. Each one has a stated limit.
- No
Can the CodeHerder agent merge, deploy, or read a secret?
It cannot merge, deploy on its own, read a secret’s value, or open a shell. A person approves the pull request, and the same pipeline you already run ships it.
- No
Is a shell left open on the server?
A shell on a dedicated instance is available on request, key-based only, scoped to what is needed — never left open because nobody asked for it.
- No
Can you stop someone who already has our credentials?
A perimeter is a wall around the outside. A leaked password or key gets in the front door — see Access for who holds a key and how one is revoked.
Secrets and traffic
- No
Is a secret ever in the code or the logs?
The running app reads it at startup. It is never written into a file in your repository, so an agent reading the codebase sees the name of the variable your code uses, never the value stored in it. A build or deploy log shows that a variable was set, never what it was set to — for a person reading the log, or an agent reading the build output.
- Yes
Is all traffic encrypted?
It stops plain, unencrypted traffic — a request over plain http:// is redirected to https:// and never served in the clear. The Strict-Transport-Security header tells a browser to skip the plain http:// address on every visit for a year. It doesn't need to trust that address again, or wait for a redirect first.
- No
Is there a web application firewall?
A standard plan checks the rules on this page and nothing more. Filtering traffic by pattern or capping request rates is a real thing we can build — just not something included by default.
Patching
- Yes
Is a critical hole patched outside the monthly window?
Triage: same day. Patch: out of band, as soon as a fix exists.
- Depends
Does a patch take the site down?
Static site: None — there is no running process to restart. Dedicated instance: A few seconds while the process restarts. A health check confirms it answers correctly before the window closes. Managed database, minor version: A brief connection blip during failover — existing connections reconnect on their own.
- No
Do you patch our own app's code for free?
A real vulnerability in your own code is a briefed change, or a piece of CustomLabs work for something too big for one pull request — not something patched silently on your behalf.
Your data
- Yes
Are backups tested?
A drill of 5 steps: restore into a throwaway environment; boot the app against it; walk the traffic paths that matter; write down what broke; destroy the copy.
- Depends
How long is a backup kept?
Every plan, by default: Daily backups · 7-day retention. Extended backup retention (30-day): Daily backups kept for 30 days instead of 7. DB Standard: 7-day PITR. DB Plus: 30-day PITR.
- No
Does a delete reach the backups?
A row you delete from the live store still exists in every backup taken before the delete. It leaves only when that backup's own retention window rolls past it.
- No
Can you guarantee where the data sits?
This site runs from one region, in the United States. Ask which region a workload can sit in before you sign, not after — the honest answer may be that we are not the right host for your obligations.
Trust and exit
- No
Do you hold a security certification?
No SOC 2 report, no ISO 27001 certificate, no PCI scope. If your work needs one of these, you need to know that now.
- Yes
Is there a channel to report a vulnerability?
The quote form is the only channel in for a security report, for a customer or an outside researcher alike. A human reads it, triages it the same way any other incident is triaged, and tells you what happens next.
- Yes
Do you tell us in writing after a breach?
A human decides whether this is a platform fault or a bug in your own code. A written note goes out on the same quote channel as everything else.
- Yes
Is there an uptime commitment?
The SLA sets the target and the credit schedule. This page prints no figure, so it cannot drift from the SLA.
- Yes
Can we leave with everything?
The exit pack lists 10 items, each in a format you can read without us.
10 of 13 capabilities are closed to the CodeHerder agent.
4 principals can touch your stack. Each card says what that principal cannot do.
Your team
The people at your organisation who already hold a key: push access to your own repository, and whatever DNS or registrar login you choose to keep for yourselves.
Cannot It cannot reach anything on our side directly. There is no console, so a secret's value, a shell, or a live database goes through a request, not a click.
CustomHosted engineers
The people who provision, watch, and fix your stack — named accounts, not a shared login.
Cannot It cannot merge or deploy to your repository on its own initiative. Only your own team can, unless you have asked us to hold that step for you.
The deploy pipeline
The automated system that builds, checks, and ships every merge — the same one for every change, agent-authored or not.
Cannot It cannot decide to merge or open a pull request. It only ever acts after a person has decided.
The CodeHerder agent
Turns a plain-language brief into a pull request, under the Agentic iteration — CodeHerder add-on ($25/mo). It reads your live repository and writes on its own branch.
Cannot It cannot merge, deploy on its own, read a secret’s value, or open a shell. A person approves the pull request, and the same pipeline you already run ships it.
Some patches restart things
A patch is not always silent. Some changes need your approval, and a dedicated instance restarts.
3 tracks
- Standing window
- MonthlyThe default path for routine updates across every infrastructure layer we run.
- Out of band
- As soon as a fix existsA vulnerability being actively exploited does not wait for the next window.
- Never without asking
- Only when briefedAnything that could change how the app behaves becomes a reviewed change first, not an automatic update.
What a window does
- Static site
- None — there is no running process to restart.
- Dedicated instance
- A few seconds while the process restarts. A health check confirms it answers correctly before the window closes.
- Managed database, minor version
- A brief connection blip during failover — existing connections reconnect on their own.
The fix arrives as a pull request
A flagged library in your own app is a briefed change. The Agentic iteration — CodeHerder add-on covers it at $25/mo. A person reads the diff before it merges.
A routine scan flags a dependency CustomHosted
The same kind of check that watches the infrastructure layers, run against your application’s own dependency list.
It's triaged as application-level, not infrastructure CustomHosted
A library your own code imports isn't ours to patch silently — it can change how the app behaves.
Briefed as a change CustomLabs
Written up the same way any other change request is. The iteration add-on is what covers it.
An agent opens the pull request CodeHerder
The upgrade lands as a real pull request against the repository, with the test suite run against it.
A human reviews and merges CustomLabs
Someone reads the diff before it goes anywhere near production — nothing here is auto-applied blind.
It ships through the same pipeline CustomHosted
The same pipeline that deploys everything else on your stack ships this too — no separate process to babysit.
You're told it's done CustomHosted
A note confirming what changed and that it merged, in the same shape as every other note on this site.
We hold this site to the same rules
Each line names the check that fails the build if the claim stops being true.
- A published disclosure address
- The disclosure policy sits at the standard address a researcher or a scanner checks first. It carries an expiry date, and the build fails if that date passes.check:security-txt
- Default response headers
- Every request gets 5 security-related response headers. The delivery page lists each one.
- A guarded supply chain
- 4 rules cover this site's own dependencies. A cooldown on brand-new releases. Exact, locked versions. Install scripts off by default. A build that fails on a critical advisory.check:supply-chain
- No stored password
- There is no account to have a password for, and no store that could hold one.check:logins
- No admin screen
- The only way to change this site is a pull request through the same pipeline as any other change — never a console reachable from the public address.check:logins
- 1 third-party host
- The pages load scripts from 1 outside host. The build fails if another one appears undisclosed.check:perf
Said plainly
Know these before you sign. The owner pages hold the same wording.
No web-application firewall or rate limiting as standard
A standard plan checks the rules on this page and nothing more. Filtering traffic by pattern or capping request rates is a real thing we can build — just not something included by default.
No certification to hand you
No SOC 2 report, no ISO 27001 certificate, no PCI scope. If your work needs one of these, you need to know that now.
We publish no region list and no residency guarantee
This site runs from one region, in the United States. Ask which region a workload can sit in before you sign, not after — the honest answer may be that we are not the right host for your obligations.
A backup outlives a delete
A row you delete from the live store still exists in every backup taken before the delete. It leaves only when that backup's own retention window rolls past it.
No staffed round-the-clock desk
The automated watching runs continuously. The people behind an escalation work business hours, with priority on an outage and best effort outside them.
We cannot stop someone who already has your credentials
A perimeter is a wall around the outside. A leaked password or key gets in the front door — see Access for who holds a key and how one is revoked.
Read the owner pages
- Access
Who holds a key, the capability matrix, and what the CodeHerder agent cannot do.
- Patching
The patch layers, the severity targets, and what a window does to each hosting shape.
- Recovery
What a backup holds, how long it stays, and the restore drill.
- Under attack
The layers that sit in front of your app, and the limits: no web application firewall, and no default rate limits.
- Your data
Where your users’ data sits, who can reach it, and what a delete does.
- Delivery
The response headers and the TLS rules every request gets.
- Domains
Who owns the DNS records, and how a certificate is issued and renewed.
- Portability
The exit pack and the steps to leave with everything.
- Status
The status page. It is not a live feed.
- SLA
The uptime terms and the credit schedule. This page prints no figure.
Ready to start?
Tell us what you're running — one fixed monthly rate, within a business day.