docs: clarify that any PostgreSQL provider works, not just Supabase#2214
docs: clarify that any PostgreSQL provider works, not just Supabase#2214ya-luotao wants to merge 1 commit intoe2b-dev:mainfrom
Conversation
The self-host guide previously stated "Supabase's DB only supported for now" but the codebase uses standard PostgreSQL (sqlc + goose) with no Supabase-specific features. Updated to list common alternatives (Cloud SQL, RDS, Neon, self-hosted) and clarify that JWT secrets are standard HS256, not Supabase-specific. https://claude.ai/code/session_01VfwkAoAckJrCGPicaGHqpt
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: dbbf9e115d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - Cloudflare account | ||
| - Domain on Cloudflare | ||
| - PostgreSQL database (Supabase's DB only supported for now) | ||
| - PostgreSQL database — any PostgreSQL provider works (e.g. [Supabase](https://supabase.com), [Neon](https://neon.tech), [Google Cloud SQL](https://cloud.google.com/sql), [AWS RDS](https://aws.amazon.com/rds/postgresql/), [Azure Database for PostgreSQL](https://azure.microsoft.com/en-us/products/postgresql), or self-hosted). Just provide a standard `postgresql://` connection string. |
There was a problem hiding this comment.
Qualify blanket PostgreSQL provider compatibility claim
The updated prerequisite says any PostgreSQL provider works with just a postgresql:// URL, but the runtime migrations still depend on a Supabase-style extensions.gen_random_bytes function (packages/db/migrations/20231220094836_create_triggers_and_policies.sql), while the base schema migration only creates the extensions schema and does not install an extension that provides that function (packages/db/migrations/20231124185944_create_schemas_and_tables.sql). On providers where pgcrypto is not already installed into extensions, the signup/API-key triggers will fail, so this doc change can send users down a broken setup path.
Useful? React with 👍 / 👎.
| - e2b-postgres-connection-string (**required**) | ||
| - e2b-supabase-jwt-secrets (optional / required to self-host the [E2B dashboard](https://github.com/e2b-dev/dashboard)) | ||
| > Get Supabase JWT Secret: go to the [Supabase dashboard](https://supabase.com/dashboard) -> Select your Project -> Project Settings -> Data API -> JWT Settings | ||
| > This is a standard HS256 JWT signing secret (minimum 16 characters). If using Supabase for auth: go to [Supabase dashboard](https://supabase.com/dashboard) -> Select your Project -> Project Settings -> Data API -> JWT Settings. If using another identity provider (Auth0, Clerk, Keycloak, etc.), use its HS256 signing secret. You can also generate your own secret for custom JWT issuers. |
There was a problem hiding this comment.
Narrow JWT secret guidance to compatible token formats
This new instruction implies tokens from Auth0/Clerk/Keycloak will work if you provide an HS256 secret, but auth validation requires both an HMAC-signed JWT and a UUID sub claim (packages/auth/pkg/auth/jwt.go checks signing method at lines 40-41 and parses sub as UUID at lines 71-78). Many non-Supabase IdP tokens do not satisfy those constraints by default, so users following this guidance are likely to hit backend-auth 401s until they mint custom compatible tokens.
Useful? React with 👍 / 👎.
No description provided.