Fixing a Laravel HTTP 500 Error on GoDaddy Shared Hosting (No SSH)

Why Laravel 500 errors are worse on shared hosting

A HTTP 500 error on a normal server usually comes with a stack trace in your terminal or log viewer. On GoDaddy cPanel shared hosting without SSH access, you don't get a terminal at all — just a blank white page and a File Manager. That single limitation is why this error takes people hours instead of minutes to fix.

The good news: almost every Laravel 500 error on shared hosting traces back to one of four causes. Work through them in order and you'll usually find it before you reach the fourth.

Step 1: Turn on debug mode temporarily

Open your .env file through cPanel's File Manager and set:

APP_DEBUG=true

Reload the broken page. Laravel will now show you the actual exception, file, and line number instead of a blank screen. Set this back to false the moment you're done — leaving debug mode on in production exposes your file paths, environment variables, and database structure to anyone who hits an error page.

Step 2: Check for a stale cached config

This is the trap that catches almost everyone. If a previous deploy ran php artisan config:cache, Laravel stops reading .env entirely and serves values baked into bootstrap/cache/config.php. So when you update your database password or app key in .env and upload it, nothing changes — Laravel is still using the old, now-wrong cached values, and often fails silently or throws a misleading error.

Since you don't have SSH to run php artisan config:clear, the workaround is a temporary route:

// add to routes/web.php temporarily
Route::get('/clear-config-xyz123', function () {
    Artisan::call('config:clear');
    Artisan::call('cache:clear');
    return 'Cache cleared';
});

Visit that URL once in your browser, confirm you see "Cache cleared," then delete the route immediately. Never leave a cache-clearing route live — it's a wide-open door for anyone who finds the URL.

Step 3: Check file and folder permissions

Laravel needs to write to two folders: storage/ and bootstrap/cache/. On shared hosting, FTP uploads sometimes set these to permissions Laravel can't write to, which throws a 500 the moment Laravel tries to write a log or compile a view. Through cPanel File Manager, set both folders (and their contents, recursively) to 755, and if that doesn't resolve it, try 775.

Step 4: Check your .htaccess and document root

Shared hosting often points your domain at the wrong folder — either the Laravel project root instead of /public, or a missing .htaccess file inside public/ that handles Laravel's pretty URLs. Confirm:

• Your domain's document root points to the public folder, not the Laravel project root
• The default .htaccess file that ships inside Laravel's public/ folder made it through your FTP upload — some FTP clients hide dotfiles by default and skip them
• Your vendor/ folder uploaded completely — a partial upload over a slow FTP connection is a common, easy-to-miss cause of 500s that look like code problems but are actually just missing files

In one deployment, the actual fault wasn't application logic at all — it was a stale cached config plus a user-specific session issue. Debug mode and a config:clear route found both in minutes.

Real client examples

Closing thoughts

Work through these four checks in order — debug mode, cached config, permissions, then .htaccess and document root — and you'll catch the overwhelming majority of Laravel 500 errors on shared hosting without ever needing SSH. If you've gone through all four and it's still broken, that's usually the point where it's actually application logic, and worth a second pair of eyes.

Frequently asked questions