After seeing a few of /public related posts I'm wondering if people get why we're doing this in the first place (no offense, we might genuinely need a better explanation in the docs)
Multiple people seem to have installed Flarum "the old way" and actually kept /public in the url, which completely defeats the purpose.
The thing to remember is that you don't want storage, vendor, flarum, config.php, composer.json and composer.lock be served publicly. ever. That's because they are sensitive files. config.php and storage because they contain sensitive data, vendor and flarum because they can expose untrusted code that anyone will be able to run and composer.* because they contain advanced information on your setup.
Now there are two choices. Either you don't place these folders under the webroot (where everything will be served by the web server), or you place them there but you make extra sure to tell the web server to never return them.
Which itself leads to 3 placement options in my opinion:
Dedicated folder, own webroot (recommended)
That's kind of the new standard, in particular for modern web applications like Laravel. You install Flarum in a folder wherever you want, but not under the webroot.
For example place Flarum in /home/ubuntu/flarum.
Then in the web server config, add a virtualhost (for own hostname) or alias (for subfolder), pointing the webroot to /home/ubuntu/flarum/public.
This means all files in /home/ubuntu/flarum but out of /public will never be served by the web server, keeping you safe.
Common webroot, protected folders (old school)
That would be the "old school" way or doing things, and it might be the only solution on hostings that don't allow you to customize the web root. Most hostings do allow it (maybe not for subfolders though) and you should use the recommended option if you can.
With this solution you place all files somewhere under the webroot (typically public_html) and restrict access to the dangerous files with configuration via htaccess for Apache or the server config for Nginx.
Additionally you can move index.php out of the public folder to remove that useless public directory.
This is the solution explained at https://flarum.org/docs/install.html#customizing-paths
Common webroot, remote folders (uncommon but great)
One last option that's not really explained in Flarum Docs but that is totally possible is to apply the concept of the recommended method with the setup of the second case.
In the skeleton, the sensitive files are placed one level above (out of public), but they can be anywhere on the filesystem.
You can place the content of public in your existing webroot or subdirectory and the other files in a directory outside of the webroot. For example if your website is at /var/www/my-website/public_html, you can often place files at var/www/my-website/flarum and they won't be served under the webroot.
Then use the "Customizing paths" instructions to change the paths in index.php to point to that folder out of the webroot. You can use relative paths ('storage' => __DIR__.'/../../flarum/storage',) or absolute paths to achieve it ('storage' => '/var/www/my-website/flarum/storage',). Don't forget to also update require '../vendor/autoload.php'; to also point to the place where the vendor folder now is.
I have not tested this option but it seems perfectly possible. It wasn't possible in beta 7 but in beta 8 with custom paths it should work as well as just removing the public folder.
In the end it's all about making sure these sensitive files don't get exposed. You're free to play around with the placement of the files, and beta 8 now gives you a lot of flexibility in that regard.
I want to take the opportunity to remind you that the Flarum Lab (which I run) will check that you are not exposing those files. It's a quick way to know if you correctly followed either installation method.
I'll need to add a case to check for those who actually kept that public folder right in the url, because currently the Lab won't try accessing the sensitive files one level up.
