# The security review, answered

> A pre-filled security questionnaire: who can reach production, how fast we patch, what a delete does to backups, and what we cannot promise.

Source: https://customhosted.com/security/

№ 01 Security

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.

№ 02 The questions

## 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. — Owner: CustomHosted [Access →](https://customhosted.com/access)
- 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. — Owner: CodeHerder [Access →](https://customhosted.com/access)
- 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. — Owner: CustomHosted [Access →](https://customhosted.com/access)
- 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. — Owner: You [Access →](https://customhosted.com/access)

### 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. — Owner: CustomHosted [Configuration →](https://customhosted.com/configuration)
- 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. — Owner: CustomHosted [Delivery →](https://customhosted.com/delivery)
- 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. — Owner: CustomHosted [Under attack →](https://customhosted.com/under-attack)

### Patching

- Yes — Is a critical hole patched outside the monthly window? — Triage: same day. Patch: out of band, as soon as a fix exists. — Owner: CustomHosted [Patching →](https://customhosted.com/patching)
- 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. — Owner: CustomHosted [Patching →](https://customhosted.com/patching)
- 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. — Owner: You [Patching →](https://customhosted.com/patching)

### 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. — Owner: CustomHosted [Recovery →](https://customhosted.com/recovery)
- 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. — Owner: CustomHosted [Recovery →](https://customhosted.com/recovery)
- 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. — Owner: CustomHosted [Your data →](https://customhosted.com/your-data)
- 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. — Owner: CustomHosted [Your data →](https://customhosted.com/your-data)

### 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. — Owner: CustomHosted [Under attack →](https://customhosted.com/under-attack)
- 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. — Owner: CustomHosted [Under attack →](https://customhosted.com/under-attack)
- 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. — Owner: CustomHosted [Incidents →](https://customhosted.com/incidents)
- 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. — Owner: CustomHosted [SLA →](https://customhosted.com/legal/sla)
- Yes — Can we leave with everything? — The exit pack lists 10 items, each in a format you can read without us. — Owner: You [Portability →](https://customhosted.com/portability)

№ 03 Who holds a key

## 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.

[The full capability matrix →](https://customhosted.com/access)

№ 04 Patch tracks and downtime

## Some patches restart things

A patch is not always silent. Some changes need your approval, and a dedicated instance restarts.

### 3 tracks

- **Standing window**: Monthly — The default path for routine updates across every infrastructure layer we run.
- **Out of band**: As soon as a fix exists — A vulnerability being actively exploited does not wait for the next window.
- **Never without asking**: Only when briefed — Anything 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 patch window, layer by layer →](https://customhosted.com/patching)

№ 05 A hole in your own code

## 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.

1. 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.
2. 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.
3. Briefed as a change CustomLabs — Written up the same way any other change request is. The iteration add-on is what covers it.
4. 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.
5. A human reviews and merges CustomLabs — Someone reads the diff before it goes anywhere near production — nothing here is auto-applied blind.
6. 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.
7. 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.

№ 06 This site's own security

## 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

№ 07 The honest limits

## 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.

№ 08 Keep exploring

## Read the owner pages

- [Access Who holds a key, the capability matrix, and what the CodeHerder agent cannot do.](https://customhosted.com/access)
- [Patching The patch layers, the severity targets, and what a window does to each hosting shape.](https://customhosted.com/patching)
- [Recovery What a backup holds, how long it stays, and the restore drill.](https://customhosted.com/recovery)
- [Under attack The layers that sit in front of your app, and the limits: no web application firewall, and no default rate limits.](https://customhosted.com/under-attack)
- [Your data Where your users’ data sits, who can reach it, and what a delete does.](https://customhosted.com/your-data)
- [Delivery The response headers and the TLS rules every request gets.](https://customhosted.com/delivery)
- [Domains Who owns the DNS records, and how a certificate is issued and renewed.](https://customhosted.com/domains)
- [Portability The exit pack and the steps to leave with everything.](https://customhosted.com/portability)
- [Status The status page. It is not a live feed.](https://customhosted.com/status)
- [SLA The uptime terms and the credit schedule. This page prints no figure.](https://customhosted.com/legal/sla)

## Ready to start?

Tell us what you're running — one fixed monthly rate, within a business day.

[Get a quote →](https://customhosted.com/contact)
