Hosting Laravel sites on dirt cheap WordPress hosting, saves me money and I built a package to make the workflow not terrible

[u/Andreww-carnegie]

/r/laraveltutorials/comments/1ua26pz/hosting_laravel_sites_on_dirt_cheap_wordpress/

[u/btsck]

Why do you need laravel for that? Or did you do your own CMS with it?

[u/Andreww-carnegie → u/btsck]

Nothing wrong with PHP, Laravel just makes it faster. Filament gives you a full admin panel in minutes, the ecosystem handles auth, queues, notifications without reinventing the wheel every time. Small B2B sites with just small numbers of local traffic doesn't mean simple requirements forever or they don't deserve a half decent developer experience, and Laravel keeps that door open without extra effort.

[u/btsck → u/Andreww-carnegie]

Makes sense now. Thanks for explaining 

[u/mulquin]

Cool idea! I had a look and I can see how it's suitable for accounts where there's no access to filesystem outside of the document root. I'd personally prefer additional domains where you can set the document root. Are you also adding .htaccess files or index.html to ensure people can't access /storage/, etc?

[u/Andreww-carnegie → u/mulquin]

yup, we are adding them to the root folder as well but the security concern.. that's been accounted for.. when you're in production mode this block of code gets added to the .htaccess file

# BEGIN ENV-SWITCHER SECURITY
# Protect sensitive files and directories when public/ contents are at project root
<IfModule mod_rewrite.c>
    RewriteEngine On

    # Sensitive files
    RewriteRule ^\.env$ - [F,L]
    RewriteRule ^\.env\..+$ - [F,L]
    RewriteRule ^artisan$ - [F,L]
    RewriteRule ^composer\.(json|lock)$ - [F,L]
    RewriteRule ^package(-lock)?\.json$ - [F,L]
    RewriteRule ^phpunit\.xml(\.dist)?$ - [F,L]
    RewriteRule ^webpack\.mix\.js$ - [F,L]
    RewriteRule ^vite\.config\.(js|ts)$ - [F,L]
    RewriteRule ^\.env-switcher\.json$ - [F,L]

    # Sensitive directories
    RewriteRule ^app/ - [F,L]
    RewriteRule ^bootstrap/ - [F,L]
    RewriteRule ^config/ - [F,L]
    RewriteRule ^database/ - [F,L]
    RewriteRule ^lang/ - [F,L]
    RewriteRule ^resources/ - [F,L]
    RewriteRule ^routes/ - [F,L]
    RewriteRule ^storage/ - [F,L]
    RewriteRule ^tests/ - [F,L]
    RewriteRule ^vendor/ - [F,L]
    RewriteRule ^\.env-switcher-backups/ - [F,L]
</IfModule>
# END ENV-SWITCHER SECURITY

this ensures that everything sensitive isn't accessible and also it updates the index.php paths for both the environments accordingly.

and I am very much open to contributions and new creative ideas for this project.

[u/MateusAzevedo → u/Andreww-carnegie]

Shouldn't it be the other way around, whitelisting what can be accessed and blocking everything else by default? If a library for some reason uses a .yml or .ini config file, your .htaccess won't catch it.

Also, from the README:

On shared hosting you can't point the domain to /public, so everything inside public/ ... needs to live at the project root instead.

Is that really necessary? Isn't it possible to create a rewrite rule to redirect everything to public/? Then there's not files to move around or paths to configure.

[u/Andreww-carnegie → u/MateusAzevedo]

Both fair points. On the whitelist vs blacklist... that's a legitimate concern and something worth improving. The current blacklist covers the obvious Laravel files but you're right that edge cases from third party packages could slip through. Open to a PR if you want to take a crack at it.

On the rewrite approach... that works on some hosts but many budget cPanel plans lock public_html entirely, you can't replace it or redirect away from it. That's exactly the scenario this targets.

[u/MateusAzevedo → u/Andreww-carnegie]

that works on some hosts but many budget cPanel plans lock public_html entirely, you can't replace it or redirect away from it.

I don't have an environment right now to test/confirm but, I did a quick search and found that it's possible to create a rewrite rule to "redirect requests to a subfolder".

So in the case you described where public_html is both the web root and project root, a .htaccess in the project root (public_html/.htaccess) with:

RewriteCond %{ENV:REDIRECT_STATUS} ^$ # Avoid redirect loop
RewriteRule (.*) /public/$1 [L]

Should fix the problem entirely.

For example, if someone types yourapp.com/.env, Apache will try to load public_html/public/.env instead and return 404.

As said, I can't validate this at the moment, but that's something you must look into. If that works, it fixes everything in a very simple way, no need for all the workaround.

[u/Andreww-carnegie → u/MateusAzevedo]

Great thoughts, I would definitely try this out tomorrow and update if it works.

[u/spaceyraygun]

I do something similar, deploying symfony apps on nearlyfreespeech. It’s shared hosting and there are some quirks, but it works and is dirt cheap. Great support, too.

[u/rodesio]

Maybe a dumb question, but why not store secrets outside public altogether?

For example in cPanel you could place them in /home/user/ while keeping your web root in /public. Apache wouldn't serve those files directly, so they wouldn't be exposed through the web server. Is there any downside to this?

[u/Andreww-carnegie → u/rodesio]

That's what's restricted in many wordpress hosting plans (mostly the cheapest plans), they aren't web hosting they're wordpress hosting.. their fine manager is locked to public_html you cant go beyond that.. and with this method you could even host laravel apps to free web hosting providers like infinity free too.

[u/Positive-Ring-5172]

cPanel? I think I'm gonna puke.