laravel new files missing index.html, index.php, and .htaccess

The root of Laravel app is in /public folder, so some other things like /config, /storage, /vendor etc. are higher in the directory tree than your index.php. Your domain should be pointing at the /public folder. /public/index.php is where it all starts :)

Laravel has /public/index.php. You need to make the /public dir your sites document root.

Both @roborobok and @cronix are correct. You should dive deeper into the Laravel documentation to start learning more. I think this link is a great starting point:

https://laravel.com/docs/5.7/authentication

make sure and run this terminal command on a fresh version of Laravel.

php artisan make:auth

OK I guess I didn't get far enough in the documentation to see that index.php is run from the Laravel install's public folder (which I see also has the .htaccess file), which I do see in the homestead app and my own generated test app. I'm a little old-school and new to vagrant and nginx, so thanks for your patience!

@davestead Note that .htaccess only works on Apache webservers (and nginx after installing an extra extension)

Out of the box on nginx, .htaccess is just another text file and cannot be used to change your PHP values or do redirects or anything.

Just a heads up ;)

@LOSTDREAMER_NL - Yes, I know .htaccess is only for Apache, thanks, though I'm not sure I should install an extension for nginx to use it.

Can you tell me if you've had experience with both Apache and NGinx with Laravel (not together of course), and which you prefer?

nginx hands down. It's many times faster than Apache. A typical basic host entry looks like

server {
    listen 80;
    listen 443 ssl http2;
    server_name hostname.test;
    root "/home/vagrant/hostname/public";

    index index.html index.htm index.php;

    charset utf-8;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location = /favicon.ico { access_log off; log_not_found off; }
    location = /robots.txt  { access_log off; log_not_found off; }

    access_log off;
    error_log  /var/log/nginx/hostname.test-error.log error;

    sendfile off;

    client_max_body_size 100m;

    location ~ \.php$ {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass unix:/var/run/php/php7.1-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

        fastcgi_intercept_errors off;
        fastcgi_buffer_size 16k;
        fastcgi_buffers 4 16k;
        fastcgi_connect_timeout 300;
        fastcgi_send_timeout 300;
        fastcgi_read_timeout 300;
    }

    location ~ /\.ht {
        deny all;
    }

    ssl_certificate     /etc/nginx/ssl/hostname.test.crt;
    ssl_certificate_key /etc/nginx/ssl/hostname.test.key;
}

At least that's how homestead and Forge set it up.

I used to use apache constantly, but for the last 5 years or so I've only used nginx (without the mentioned extension by the way).

if you get the hang of it, it's very powerful and easily configurable. Not just a webserver, but also a reverse proxy, or a load balancer, or a man-in-the-middle. Not a month goes by where I don't learn something new I can do with it.

And using it as just a webserver is at least as easy as Apache...

@LOSTDREAMER_NL - Do you use the reverse proxy for anything? I'm not sure that's useful for Laravel or API hosting.

@davestead Reverse proxy is useful for many instances. Technically, a "load balancer" is a reverse proxy with logic that spreads the incoming load across proxied assets.

For an API, you can use a reverse proxy to have your API code highly available with two instances of Laravel. If you upgrade code, you just do them one at a time, removing the "under maintenance" instance out of the load balancer temporarily.

@davestead not specific for laravel or api hosting, no. but once you feel familiar with it, it comes in handy more often than not.

At home I'm running a few internal services, like a video script (Sonarr, on port 8989) and download program (sabnzbd, port 8080) some home grown domotics script (different pc, port 80), and some others that run on various PCs (all port 80 on some raspberries).

All http traffic from my router goes to my ubuntu box, running my dev projects on various subdomains (creating a folder in /var/www will auto create the subdomain because of a dynamic server_name setting in nginx)

# it's that easy to have auto subdomains 
server_name ~^(?<sname>.+?).my-domain.nl$;
if (!-d /var/www/$sname/public ) {
    $sname = "default"
}
root /var/www/$sname/public;

Now to also be able to get to my domotics, sabnzbd and sonar installs on other pc's in the network, i simply setup a reverse proxy on yet another subdomain.

Just something simple like:

server {
  listen 80;
  server_name videos.my-domain.nl;

  location / {
    proxy_pass http://192.168.0.100:8989;
  }

  listen 443 ssl; # managed by Certbot
  ssl_certificate /etc/letsencrypt/live/my-domain.nl/fullchain.pem; # managed by Certbot
  ssl_certificate_key /etc/letsencrypt/live/my-domain.nl/privkey.pem; # managed by Certbot
  include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
  ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

Will now route all traffic from videos.domain.nl to a pc on my network that is normally not accessible as the router doesnt forward traffic to it. it even adds SSL to the connection, so http internally and https externally.

So now I can use subdomains to proxy port 80 and 443 to any pc or port in my network.

Same goes for other stuff: I installed an open source video chat server, run it on some port that I dont open up to the internet, and than use an nginx proxy setup to link that port to a specific subdomain so I can use it on chat.my-domain.nl instead of my-domain.nl:10000

And as kobear said, in production environments, you can use it to have multiple servers host the same app, and have 1 nginx instance in front that routes traffic unto those instances.