Repository navigation
docs(self-hosting): document extension sign-in, sign-up limits, media server capacity and safe migration recovery - #3521
Conversation
… server capacity and safe migration recovery
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
|
|
||
| - `CAP_ALLOWED_SIGNUP_DOMAINS` applies to **new** accounts only. Users who already have an account can still sign in from any domain. | ||
| - `CAP_BLOCKED_SIGNUP_DOMAINS` applies to existing users too: a blocked address can't sign in, and its existing web sessions and Cap app sign-ins (desktop, Chrome extension) stop working. | ||
| - Neither setting adds users to an organization. New users who weren't invited start in their own organization. |
There was a problem hiding this comment.
The claim that uninvited users start in their own organization misses the WorkOS SSO path. If WorkOS SSO is configured, provisionSsoMembership adds a new user to the SSO organization without an invitation. Admins could mistake this wording for an invitation requirement. Keep the statement that these domain settings do not add members, but qualify the next sentence with the SSO exception.
Knowledge Base Used: Data and identity platform
Prompt To Fix With AI
This is a comment left during a code review.
Path: apps/web/content/docs/self-hosting.mdx
Line: 127
Comment:
**SSO users join without invitations**
The claim that uninvited users start in their own organization misses the WorkOS SSO path. If WorkOS SSO is configured, `provisionSsoMembership` adds a new user to the SSO organization without an invitation. Admins could mistake this wording for an invitation requirement. Keep the statement that these domain settings do not add members, but qualify the next sentence with the SSO exception.
**Knowledge Base Used:** [Data and identity platform](https://app.greptile.com/cap/-/custom-context/knowledge-base/capsoftware/cap/-/docs/data-and-identity-platform.md)
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
There was a problem hiding this comment.
Fixed in 4903e4c: the sentence now names the WorkOS SSO exception.
|
|
||
| The media server runs a limited number of video jobs at once. Unless you set a limit, it uses the smallest of 4 and half the CPUs, and, if the container has a memory limit, the memory limit × 0.85 ÷ 768 MB (at least 1). A media server with 2 CPUs therefore processes one video at a time. | ||
|
|
||
| When it is full, it answers `503 Server is busy` and Cap Web keeps the video waiting and retries until a slot frees up. Videos queue behind each other instead of failing. To process more at once, set the limits on the **media server** container: |
There was a problem hiding this comment.
The promise that busy media work always waits is too broad. The faststart rewrite in multipart.ts calls /video/process directly. A busy response is caught, logged, and dropped without retrying, so self-hosters cannot expect that rewrite to run once capacity returns. Limit this promise to the workflows that retry, and mention that the faststart rewrite can be skipped when the server is full.
Knowledge Base Used: Media-server runtime service
Prompt To Fix With AI
This is a comment left during a code review.
Path: apps/web/content/docs/self-hosting.mdx
Line: 146
Comment:
**Busy work sometimes gets dropped**
The promise that busy media work always waits is too broad. The faststart rewrite in `multipart.ts` calls `/video/process` directly. A busy response is caught, logged, and dropped without retrying, so self-hosters cannot expect that rewrite to run once capacity returns. Limit this promise to the workflows that retry, and mention that the faststart rewrite can be skipped when the server is full.
**Knowledge Base Used:** [Media-server runtime service](https://app.greptile.com/cap/-/custom-context/knowledge-base/capsoftware/cap/-/docs/media-server-and-web-cluster.md)
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.There was a problem hiding this comment.
Fixed in 4903e4c: the paragraph now limits the retry promise to video processing and says the post-upload faststart rewrite is skipped when the server is full.
…that isn't retried
Things we had to find in the source while self-hosting Cap (Kubernetes, MySQL 8, S3-compatible storage), added to
self-hosting.mdx:CAP_CHROME_EXTENSION_ID(packages/web-backend/src/Extension/Http.ts). Neither compose file forwards it today (feat(self-hosting): allow configuring CAP_CHROME_EXTENSION_ID for extension login #1992 proposes that); the note on adding variables is worded so it stays right either way.CAP_ALLOWED_SIGNUP_DOMAINS(new accounts only),CAP_BLOCKED_SIGNUP_DOMAINS(existing users too: web sessions and desktop/extension sign-ins stop working) andCAP_VIDEOS_DEFAULT_PUBLIC, with the organization override.job-manager.ts, what503 Server is busydoes (the video waits with backoff inprocess-video.ts), and the twoMEDIA_SERVER_MAX_CONCURRENT_*overrides. On a 2-CPU container it processes one video at a time.ETagexposed.docker compose down -v, which deletes the MySQL and MinIO volumes. It now says to read the log, back up (database, media,DATABASE_ENCRYPTION_KEY) and report. "Reset everything" stays, labeled as deleting all data.Docs only. No textual overlap with #2299 or #3002, which also edit this file.
The PR appears safe to merge, with two non-blocking documentation corrections.
Findings
Fix with agent prompt
Summary
Updates the self-hosting guide with:
Two non-blocking corrections remain: explain the SSO membership exception and narrow the promise that busy media work always retries.
Reviews (1) · Last reviewed commit: "docs(self-hosting): document extension s..." · Reviewed by Greptile