Work through this before production use. Items are ordered by how much they matter.

The Shellius host itself

Shellius can sign a certificate for any bootstrapped host, so it is the most sensitive machine you run.

• [ ] Put it on its own host, not alongside unrelated services.
• [ ] Terminate TLS in front of it. Never serve it over plain HTTP.
• [ ] Restrict who can reach the host over SSH, and do not manage it with Shellius itself — that is a circular dependency during an outage.
• [ ] Keep the Docker daemon and host OS patched. Docker socket access is root.

Secrets

• [ ] Every secret in .env.prod is freshly generated, not copied from the example file.
• [ ] .env.prod is mode 0600 and owned by the account running the stack.
• [ ] SERVER_ENCRYPTION_KEY is backed up off the machine and you have verified the backup is readable.
• [ ] Secrets are not in your shell history, a ticket, or a chat thread.
• [ ] You know how to rotate JWT_SECRET (it signs everyone out) if you need to.

Accounts and roles

• [ ] The seeded admin password was changed at first sign-in.
• [ ] There is more than one super admin, so you are not locked out — but not many more.
• [ ] Built-in roles were reviewed rather than assumed. admin and super_admin hold access.prod_bypass by default.
• [ ] prodBypassEnabled is off unless you have a specific reason. With it off, nobody skips production approval, including super admins.
• [ ] SSO is configured if you have an identity provider, so offboarding a person actually removes their access.

Policies

• [ ] A deny policy covering prod exists and is written before the allow rules.
• [ ] autoApprove is used only for demo, dev, and staging.
• [ ] Principals are specific accounts, not root.
• [ ] maxSessionDuration is hours, not days.
• [ ] allowKeyDownload is off unless a workflow genuinely needs it.
• [ ] Approver routing is set to a group or named users, not left to fall back to the requester's manager by accident.

Target hosts

• [ ] Static keys in authorized_keys were removed after certificate access was confirmed working. Leaving them means you still have the original problem.
• [ ] Hosts are tagged with the environment they actually are. A production host tagged dev bypasses approval.
• [ ] PermitRootLogin is off, and root is not in any policy's principals.
• [ ] You have a break-glass route into each host that does not depend on Shellius being up — check-principals fails closed.

Operations

• [ ] Database backups run on a schedule and are shipped off the machine.
• [ ] You have restored a backup into a scratch deployment and confirmed the CA public key matched.
• [ ] The Prometheus endpoint is behind METRICS_TOKEN and not publicly exposed.
• [ ] SMTP works — without it, nobody is notified that a production request is waiting.
• [ ] Someone reviews the audit log on a schedule. An unread log is not a control.

Understand the trade-offs

Read the threat model before you decide this is enough. In particular: a compromised Shellius host means a compromised fleet, and approval stops accidents rather than a determined insider.