You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/self-hosting.md
+4Lines changed: 4 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -38,6 +38,10 @@ This is the infrastructure/ops guide — getting the Clevis stack itself running
38
38
39
39
**If your GitHub App was registered before the Setup URL field above was documented here:** open the App's settings on github.com, go to the "Post installation" section, and add the Setup URL now. Orgs that already completed installation don't need to reinstall — only new installs and updates will use the new callback page going forward.
40
40
41
+
**Connecting more than one account/org:** there's no limit — install the App from the sidebar's "Switch account" menu or the Settings → Connected GitHub accounts button as many times as you need. Connecting an organization requires you to be a GitHub **owner** of it (Clevis live-checks this against GitHub); if you're only a member, ask an owner to connect it.
42
+
43
+
**After the App's permissions are widened:** when a new Clevis release adds an optional write automation (issues #286–#291), existing installations keep working but the new feature stays blocked until a GitHub org owner re-approves the App's updated permission request. Clevis shows affected org admins a "N automations need extra GitHub access" notice in Settings and on the Automation page with a "Review on GitHub" link; the notice clears automatically once the owner approves (via the `installation``new_permissions_accepted` webhook).
44
+
41
45
4. (Optional) Configure SMTP so self-registered accounts can verify their email: set `SMTP_HOST`, `SMTP_PORT` (default `587`), `SMTP_USER`, `SMTP_PASSWORD`, `SMTP_FROM` in `.env`. Without these, registration still works — accounts are created immediately — but they stay unverified and can't accept an org invitation until either SMTP is configured and the user clicks the emailed link, or they link a GitHub account instead (GitHub-verified emails are trusted immediately). Accounts created via first-run `/auth/setup` or "Sign in with GitHub" are always verified, regardless of SMTP.
42
46
43
47
5. (Optional) Give the worker its own Postgres credential, separate from the API's `DB_USER`/`DB_PASSWORD`: set `WORKER_DB_PASSWORD` in `.env`. This is a prerequisite for a future Row-Level Security migration (issue #190) and has no effect otherwise — the worker keeps working exactly as before if left unset. It only takes effect via the `db` container's first-ever startup (`docker-entrypoint-initdb.d` scripts only run once, against a fresh, empty data volume). If you're setting this on an **existing** deployment (a `db` volume that's already initialized), run this once by hand instead:
0 commit comments