[FIXED] Failed to create bucket: invalid signature

Odd, the default install of Supabase gives me this error when I try to create a new bucket: Failed to create bucket: invalid signature I'm experiencing a persistent issue with the Supabase instance deployed through Dokploy on my server. When attempting to create a storage bucket, I consistently receive the error:
Failed to create bucket: invalid signature
Failed to create bucket: invalid signature
Details: - This error occurs in the Supabase dashboard when trying to create any storage bucket - I have not modified any of the Supabase configuration files manually - The server was set up using cloud-init with security hardening (UFW, Fail2Ban, etc.) - I've already tried disabling the firewall and restarting the server, but the issue persists Logs: The storage service logs show JWT verification errors:
"originalError":{"name":"JsonWebTokenError","message":"invalid signature"},"error":"Unauthorized"
"originalError":{"name":"JsonWebTokenError","message":"invalid signature"},"error":"Unauthorized"
From checking environment variables, all services appear to be using the same JWT secret:
# Storage service
PGRST_JWT_SECRET=RLnvbg...dGW8rKo=

# Auth service
GOTRUE_JWT_SECRET=RLnvbg...dGW8rKo=
# Storage service
PGRST_JWT_SECRET=RLnvbg...dGW8rKo=

# Auth service
GOTRUE_JWT_SECRET=RLnvbg...dGW8rKo=
Troubleshooting Steps Already Tried: 1. Restarting all Supabase services 2. Disabling firewall to eliminate potential networking issues 3. Checking logs for all related services 4. Verifying environment variables for JWT settings across services Any assistance in resolving this issue would be greatly appreciated. Additional Details: - Server OS: Ubuntu (running kernel 6.8.0-55-generic) - Supabase appears to be running in Docker containers managed by Dokploy - No modifications have been made to the default Supabase setup provided by Dokploy Thank you for your help, Old Man Umby
1 Reply
Old Man Umby
Old Man UmbyOP2mo ago
I've confirmed this is an issue. I've deleted and reinstalled Supabase, making no changes, and the issue is still there. It seems to be installing this way straight out of the box. Fixing "Invalid Signature" in Supabase without changing "stub" entries in Compose file ... Assumptions * You’ve installed Supabase via Dokploy’s app templates. * Dokploy UI is at http://<your-dokploy-url>:3000. * Project name: e.g., supabase-test (adjust as needed). The Fix * Check the Current JWT_SECRET: * In the project dashboard, find the "Environment" or "Settings" section (usually a tab or button). * Look for JWT_SECRET in the list of environment variables. * Copy its value (e.g., JWT_SECRET=pregenerated-secret). * Generate a New SERVICE_ROLE_KEY: * Open jwt.io in a new tab. * Set the payload:
{
"role": "service_role",
"iss": "supabase",
"iat": 1741500000, # Or current timestamp
"exp": 1899266400, # Or ~5 years from now
"sub": "supabase-test-owner" # Use your project name + "-owner"
}
{
"role": "service_role",
"iss": "supabase",
"iat": 1741500000, # Or current timestamp
"exp": 1899266400, # Or ~5 years from now
"sub": "supabase-test-owner" # Use your project name + "-owner"
}
* In "Verify Signature", paste the JWT_SECRET from Dokploy into the secret box. * Copy the new token from the "Encoded" box (e.g., eyJhbGciOiJIUzI1NiIs...). * Update SERVICE_ROLE_KEY in Dokploy: * Back in Dokploy’s project dashboard, go to the "Environment" section. * Find SERVICE_ROLE_KEY. * Replace its value with the new token from jwt.io. * Save the changes (look for a "Save" or "Apply" button). * Restart the Project: * In the project dashboard, find the "Restart" or "Redeploy" button (usually near the top or in a "Services" tab). * Click it to restart all Supabase services. * Test in Supabase Studio: * Open http://<your-dokploy-url>/supabase-test (adjust URL to your project’s domain). * Go to the Storage section, create a bucket (e.g., test-bucket), and check if it works without errors. Why It Works - The "invalid signature" error was due to the missing sub claim in SERVICE_ROLE_KEY. Adding it fixes token validation. - "Stub" values (TENANT_ID, REGION, GLOBAL_S3_BUCKET) don’t need changing for this fix.

Did you find this page helpful?