Self-hosted operator access and changes

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 is the only diagnostic channel. You build it and you send it. Incidents follow Self-hosted support and incident response. Emergency host access belongs to you. See 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 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.

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 — what to send when you ask for help
• Self-hosted support and incident response — who runs an incident and how severity is set
• Replacing a compromised self-hosted server — contain and replace a host you no longer trust
• Self-hosted log retention and access — how long logs stay and who can read them
• Self-hosted deployment — download, verify, run and upgrade the server