-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Description
Description
When using Cap Desktop with a self-hosted Cap Web instance, the S3 configuration API calls (/api/desktop/s3/config/*) are sent to https://cap.so instead of the custom server URL configured in Settings.
This means users with self-hosted Cap instances cannot use the S3 Config feature in Cap Desktop, even though:
- Authentication works correctly with the self-hosted server
- The custom server URL is properly saved in settings
Root Cause
The desktop app has inconsistent URL handling:
Authentication (apps/desktop/src/utils/auth.ts:39) correctly reads the runtime setting:
const serverUrl =
(await generalSettingsStore.get())?.serverUrl ?? "https://cap.so";API client (apps/desktop/src/utils/web-api.ts:35,44) uses a static build-time value:
export const apiClient = initClient(contract, {
baseUrl: `${clientEnv.VITE_SERVER_URL}/api`,
api,
});Where clientEnv.VITE_SERVER_URL is defined in apps/desktop/src/utils/env.ts:
export const clientEnv = {
VITE_SERVER_URL: import.meta.env.VITE_SERVER_URL ?? "https://cap.so",
};This is a build-time constant that defaults to https://cap.so and never reads from generalSettingsStore.serverUrl.
Reproduction
- Set up a self-hosted Cap Web instance
- In Cap Desktop, go to Settings > General and set Server URL to your self-hosted instance
- Sign in (this works because auth.ts uses the correct URL)
- Go to Settings > Integrations > S3 Config
- The page will fail to load or show errors because API calls go to
cap.soinstead of your server
Expected Behavior
All API calls in the desktop app should respect the custom server URL setting, not just authentication.
Suggested Fix
Update apps/desktop/src/utils/web-api.ts to dynamically read from generalSettingsStore instead of using the static clientEnv.VITE_SERVER_URL. This may require making the API client initialization async or creating a function that returns the current server URL.
Additional Context
- Cap version: Latest (verified in source code as of Jan 2026)
- Operating system: macOS (but affects all platforms)
- Related issue: Self-hosted Cap Web doesn't support embeds #906 (similar pattern where embeds are hardcoded to cap.so)