# Self-hosted operator access and changes

Source: https://codeherder.com/docs/self-host-operator-access/

CodeHerder staff have no access to your install. See what the operator may do, who approves changes, how to record them, and the joiner, mover and leaver steps.

This page sets the access and change policy for your self-hosted CodeHerder install. Your organization owns the policy. Your instance operator runs the server and follows it.

## No vendor access

CodeHerder staff have no account on your install. They have no IAM role, no SSM path and no network path into your AWS account. The admin plane does not ship with a self-host. Your only operator surface is `/v1/instance/`.

The [support bundle](https://codeherder.com/docs/support-bundle/) is the only diagnostic channel. You build it and you send it. Incidents follow [Self-hosted support and incident response](https://codeherder.com/docs/self-host-support/). Emergency host access belongs to you. See [Plan emergency host access](https://codeherder.com/docs/self-host-compromise/#plan-emergency-host-access).

## Who operates the instance

Your instance operator runs the server. The operator can be your own staff, or a party that your support agreement names. The operator acts on your authority. That access exists only because your organization grants it in your own AWS account and identity provider. You can remove it at any time. It is not a CodeHerder staff channel.

## Operator permissions

Grant access in two layers. Give each layer the least it needs.

| Layer | What you grant | Notes |
| --- | --- | --- |
| Your AWS account | An IAM identity that your organization issues, with MFA. | Suggested minimum: SSM Session Manager to the app host, scoped by tag. Read access to CloudWatch logs. Read-only access to the RDS instance and its alarms. Whatever the upgrade step needs. Give no IAM admin, no KMS key admin and no billing access. Your organization sets the exact policy. |
| The instance | The operator’s verified email in `CH_INSTANCE_OPERATORS`, with sign-in MFA. | The server reads the list once at boot. A change needs a restart. The operator area reaches every tenant on the install. The server writes an audit row for each `/v1/instance/` request. |

See [Self-hosted Cognito sign-in](https://codeherder.com/docs/self-host-cognito/) for the sign-in settings.

## Authorization

Your organization names an approving owner.

A standing approval covers routine work:

- Release upgrades inside an agreed window.
- Restarts.
- Reading logs and health checks.

Anything else needs approval before the change:

- IAM changes.
- Setting or secret changes.
- Changes to `CH_INSTANCE_OPERATORS`.
- Restores from backup.
- Erasure of a person, with `POST /v1/instance/humans/{id}/erase`.
- Key rotation.

## Record every change

Record each change in your own change or ticket system. CodeHerder does not hold these records. Write these fields:

| Field | Content |
| --- | --- |
| Date | When the change ran. |
| Operator | Who ran it. |
| Change | What changed. |
| Versions | The version before and after. |
| Approval | The approval reference. |
| Result | Whether it worked. |
| Rollback | How to undo it. |

Three sources back a record. The instance audit rows show each operator request. CloudTrail shows AWS actions. SSM session logs show host sessions. See [Self-hosted log retention and access](https://codeherder.com/docs/self-host-log-retention/).

## Joiner, mover and leaver

**Joiner.**

1. The approving owner approves the access.
2. Issue an IAM identity with MFA.
3. Add the person’s email to `CH_INSTANCE_OPERATORS`.
4. Restart the server.
5. The person signs in once, so the server verifies the email.
6. Record the change.

**Mover.** Review both layers. Remove what the new role does not need. Record the change.

**Leaver.**

1. Remove the IAM identity and end its sessions.
2. Remove the email from `CH_INSTANCE_OPERATORS`.
3. Restart the server.
4. Run `ch human revoke-all <human> --yes`. It revokes the person’s keys, MCP grants, device tokens and CLI installs.
5. Rotate any shared or break-glass secret the person held.
6. Record the change.

Your personnel policy sets background checks and training for anyone you grant access.

## Review access

Review access every quarter and after any leaver. Check these three things:

1. The IAM principals that can reach the host.
2. The `CH_INSTANCE_OPERATORS` list.
3. Recent instance audit rows.

Record the date, the reviewer and the result.

## Rule text for approval

This text is a template. Adapt it to your policy.

> **Operator access rule.**
>
> 1. CodeHerder staff have no access to the customer’s install. The support bundle is the only channel.
> 2. The instance operator, ______, operates the instance on the customer’s authority. The customer can revoke that access at any time.
> 3. Operator access uses least-privilege IAM with MFA, and an email in `CH_INSTANCE_OPERATORS`.
> 4. Routine work runs under a standing approval. Every other change needs approval first.
> 5. The operator records every change in the customer’s change system.
> 6. Joiners, movers and leavers follow the steps on this page. A leaver’s access ends the same day.
> 7. The customer reviews operator access every quarter and after any leaver.

## Related guides

- [Self-hosted support bundle](https://codeherder.com/docs/support-bundle/) — what to send when you ask for help
- [Self-hosted support and incident response](https://codeherder.com/docs/self-host-support/) — who runs an incident and how severity is set
- [Replacing a compromised self-hosted server](https://codeherder.com/docs/self-host-compromise/) — contain and replace a host you no longer trust
- [Self-hosted log retention and access](https://codeherder.com/docs/self-host-log-retention/) — how long logs stay and who can read them
- [Self-hosted deployment](https://codeherder.com/docs/self-hosting/) — download, verify, run and upgrade the server