# Who can touch your production.

> Four parties can reach a running system. See what each one may do, how secrets are kept, and what the CodeHerder agent cannot touch.

Source: https://customhosted.com/access/

№ 01 Access

Four parties can reach a system that's live: your team, our engineers, the deploy pipeline, and the CodeHerder agent. This page is the matrix — 13 capabilities, checked against each of the 4, including the 10 the agent is locked out of by design.

№ 02 The four

## The four who hold a key

What each one is, what it is for, and the single thing it may not 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. — May not: 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. — May not: 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. — May not: 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. — May not: 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.

№ 03 The artifact

## The access matrix

Every capability that touches a running system, checked against every principal above — not asserted in a paragraph, checked in a row.

| Capability | Your team | CustomHosted engineers | The deploy pipeline | The CodeHerder agent |
| --- | --- | --- | --- | --- |
| Read the repo | Yes — It is your repository. | Yes — Read-only, given once at onboarding. | Yes — It reads the repository to build and deploy it. | Yes — It reads the live repository to brief and open a pull request. |
| Open a pull request | Yes — Any of your own contributors can. | Yes — The same as any other contributor, reviewed the same way. | No — It ships a merge. It does not propose one. | Yes — Only ever on its own branch, never on the branch that ships. |
| Merge to the main branch | Yes — This is your call to make. | On request — Only if you have asked us to review and merge for you. Most teams keep this step themselves. | No — It deploys after a merge. It does not decide to merge. | No — Never. A person approves the pull request first. |
| Start a deploy | Yes — A merge starts it — there is no separate deploy step to run. | Yes — To redeploy or fix something on your account, on request. | Yes — This is its job. | No — It cannot start a deploy on its own. |
| Roll back | Yes — Revert the merge and the pipeline redeploys the last working version. | Yes — Can revert or promote the previous deploy for you, on request. | Yes — It redeploys whatever the last merge or promotion says to run. | On approval — It can open the pull request that reverts a change. A person still has to approve it. |
| Read a secret's value | On request — There is no console to read it from — ask, and we tell you. | Yes — Named accounts only, to service or rotate a value. | Yes — It reads a value to inject it into the running app, never to log it. | No — It sees that your code reads a variable, never the value stored in it. |
| Set a secret's value | On request — Sent through the quote channel and stored for you, the same as onboarding. | Yes — Stores the value you send and rotates it on request. | No — It reads a stored value. It does not create one. | No — It cannot write a secret, only reference one by name in code. |
| Open a shell on the instance | On request — Available if you want it — key-based, and scoped to what you need. | Yes — Holds the keys to the machine room, not to your application. | No — It runs the deploy script. It never gets an interactive shell. | No — Never. It changes code through a pull request, not a live session. |
| Read the database | On request — Ask for a one-off export or a read connection, not a shared login. | Yes — Named accounts, to operate, back up, and monitor it. | No — The app it deploys talks to the database. The pipeline has no login of its own. | No — Reads the code that queries the database, never a live connection or a row of your data. |
| Read a log | On request — There is no console to read it from — ask for an extract covering a window. | Yes — Named accounts only, to diagnose an incident or a reported bug. | No — It ships a build. It does not read back what a running app writes down. | No — It reads your application code, never a log store or a live system. |
| Change DNS records | On request — Once a domain is pointed here, records are managed for you. | Yes — Managed end to end — see Domains for the record sheet in full. | No — It deploys your app. DNS is a separate system it does not touch. | No — DNS is not part of the application repository it branches on. |
| Restore a backup | On request — Say what is gone; we pick the restore path and confirm before anything live changes. | Yes — Runs the restore, into a throwaway copy first. | No — A restore is a deliberate, confirmed procedure, not an automatic deploy. | No — It changes code, never a backup or a live copy of your data. |
| Close the account | Yes — Either side can end the service any time, effective at the close of the billing cycle. | On request — Closes it once you say so, and only then. | No — It ships changes to a running account. It has no say in whether the account keeps running. | No — It only ever opens a pull request. |

"On request" means it goes through the quote channel, not a console — there isn't one. "On approval" means a principal can start the action but a person has to sign off before it completes.

№ 04 Secrets

## Secrets

Where a value lives, who can read it back, and what an agent never sees.

- A secret lives in one place — Sent once, at onboarding or whenever it changes, and kept in an encrypted store — never copied into a spreadsheet, a chat message, or a second system to keep in sync.
- It is never in the code — 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.
- You can change it any time — There is no console to click into — send the new value through the quote channel, and it is stored and rotated in.
- It is redacted from logs — 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.

See [Logs](https://customhosted.com/logs) for what a log actually holds, and for how long. See [Configuration](https://customhosted.com/configuration) for where a value lives hop by hop, and the build-time-versus-run-time trap.

№ 05 In practice

## Least privilege, in practice

Named accounts, scoped keys, and what changes when a job does.

- Named accounts, not a shared login — Every engineer who can reach your stack signs in as themselves — never a shared password the whole team knows.
- A key is scoped to the one job it does — Deploying your app, reading your backups, running your database — each is its own scoped key, never one master key that opens everything.
- SSH is off by default — 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.
- Access changes when a job does — It is not left standing after it stops being needed — see joiners and leavers below for exactly when it is removed.

№ 06 The tie-in

## What the CodeHerder agent can and cannot do

The honest answer to the question every "Agentic iteration — CodeHerder" line raises.

The agent's credential works on one thing: its own branch. It reads your live repository, writes a change, and opens a pull request. It cannot merge that request, cannot start a deploy on its own, cannot read a secret's value, and cannot open a shell on the instance running your app.

A person approves the pull request. The same pipeline that ships every other change on your account ships that one too — there is no separate, faster path for an agent-authored change to skip review.

[See how the loop works →](https://customhosted.com/loop)

Read a brief in full on [Brief a change](https://customhosted.com/brief), the line-item hand-off on [Spec sheet](https://customhosted.com/spec), or what the add-on costs on [Billing](https://customhosted.com/billing).

№ 07 Changing hands

## Joiners and leavers

On your side, and ours — the same discipline, both directions.

1. 1 — A person joins your team — Add them to your own repository and DNS panel the same way you would add any other teammate. We are not part of that step, and do not need to be told.
2. 2 — A person leaves your team, or a contractor's engagement ends — Remove their repo access on your own schedule. If they also held a key to something on our side — a shell login, for instance — tell us through the quote channel and it is revoked the same day.
3. 3 — One of our engineers changes role — Their access changes with it. A key scoped to your account is removed the day it stops being their job.
4. 4 — One of our engineers leaves — Every key and account they held is revoked before their last day, not sometime after it.

№ 08 The exception

## Emergency access

When elevated access gets used, it's recorded, and you're told.

1. 1 — Elevated access is the exception — Day-to-day work runs on the named, scoped access described above — not a standing key to everything.
2. 2 — Used only to stop or fix a live incident — Opened when routine access cannot resolve a real problem fast enough, not as a shortcut around the normal path.
3. 3 — Every use is recorded — What was opened, by whom, and why, goes in the incident record — not a quiet, unlogged detour.
4. 4 — You are told — Elevated access used on your stack is named in the incident note you already get — see Monitoring for the shape of that note.

№ 09 Answers

## Access questions

The anxiety questions, verbatim, answered from the matrix above.

1. 01 Do you support single sign-on for my team? There's nothing here for it to connect to. Your team has no login console at all — access to your stack runs through your own repository and DNS, so add or remove a person there, not in a dashboard.
2. 02 Who can actually deploy to production? Your own team, by merging to your repository — the same pipeline that already ships every other change. We can deploy or roll back on your behalf, on request. The CodeHerder agent never can, on its own.
3. 03 Can the CodeHerder agent read our secrets or our database? No, on both counts. It reads your application code to brief and open a pull request. It never sees a secret's value, and it never opens a connection to your database.
4. 04 How do I revoke access when someone leaves? For your own team, remove their repository and DNS access yourself, whenever you choose. For anything they held on our side, tell us through the quote channel and it is revoked the same day — see Joiners and leavers above.
5. 05 Is this audited or certified by a third party? No. This page describes real, current operating practice, in writing — it is not a substitute for a formal audit or certification if your situation specifically requires one.
6. 06 What's the difference between an on-request and a break-glass action? An on-request action is routine — reading a secret's value, restoring a backup — worked through the quote channel on your schedule. Break-glass is the exception: elevated access opened only to stop a live incident, always recorded, and always told to you afterward.

№ 10 Keep reading

## What access connects to

- [Your data What the access above can read — this page's principals and least-privilege points, reused whole.](https://customhosted.com/your-data)
- [Logins The other half of the picture: who signs in to your app, not to production.](https://customhosted.com/logins)
- [Under attack The network perimeter — firewall, DDoS mitigation, and rate limiting — the other axis from who holds a key.](https://customhosted.com/under-attack)
- [Security The security questionnaire. It answers the access question first, then points to every other owner page.](https://customhosted.com/security)
- [The Loop The full build-iterate-run picture this page's § 06 is one row of.](https://customhosted.com/loop)
- [Brief a change What goes into the brief that becomes the pull request the agent can open, and never merge.](https://customhosted.com/brief)
- [Review This page's "Open a pull request" and "Merge" rows, narrowed and expanded — who may approve, and what to do when it goes wrong.](https://customhosted.com/review)
- [Recovery The restore procedure behind the "Restore a backup" row in the matrix, in full.](https://customhosted.com/recovery)
- [Patching The briefed-change path an application dependency travels, matching this page's merge and deploy rows.](https://customhosted.com/patching)
- [Configuration Where a value lives once it is sent — the full walk from the secrets rows above through to the running process.](https://customhosted.com/configuration)
- [Onboarding The handover checklist — repo access, DNS, and secrets — that this page's matrix picks up from.](https://customhosted.com/onboarding)
- [Repository The repository itself — who owns it, the four states it can arrive in, and this page's "Read the repo" and "Merge" rows in full.](https://customhosted.com/repository)
- [Portability What happens to access when you leave, rather than while you're a customer.](https://customhosted.com/portability)
- [Terms The binding text behind account responsibility and termination on this page.](https://customhosted.com/legal/terms)

## Want the access record for your own account?

Ask through the quote form — the same channel behind every 'on request' row above.

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