the .env file makes sense esp. for different settings of your development server and the production sever. ie the Environment Configuration. Those data is 'outsourced'. (ok, that's not 100% correct but helps thinking about it)

the config files on the other hand are variables for specific tasks which are not server specific, eg

// config/blog.php

<?php return [ 'name' => "Freznos BlogPage", 'title' => "Freznos Motocross Blog", 'subtitle' => 'A Blog for Motocross Enthusiasts ', 'description' => 'This blog is all about the motocross sport', 'posts_per_page' => 10, ], ]; and now using it within your files, eg: // within views: <meta name="description" content="{!! $meta_description !!}"> <title>{{ $title or config('blog.title') }}</title> // @extends('blog.layout', [ 'title' => $post->title, 'meta_description' => $post->meta_description ?: config('blog.description'), ]) // // using controller: $posts = Post::with('tags') ->where('published_at', '<=', Carbon::now()) ->orderBy('published_at', 'desc') ->simplePaginate(config('blog.posts_per_page')); would (and could) you put those specific data into the .env file? and even if you would, just imagine, you have eg different pages_per_post for pagingination, depending on whether its you blog or comments or shop or admin area etc. By:Xtreem Solution [Highly Skilled Laravel Developer](https://xtreemsolution.com/hire-laravel-developer.html) [Dedicated PHP Developer](https://xtreemsolution.com/hire-php-developer.html)

That's the way it works. What you are going to end up with in the end is two (or more) sets of .env files. These files are never checked in and will be different depending on the server you are on (eg: production versus development).

Yes it a hassle that your .env.example might not match your .env but that's how it is. Configuration files are what was mentioned above but also used to "cache" your env for that server.