Hi Benjamin,

I think this is not something typically Laravel related, but more a general development question.

The answer really depends on your situation. Technical knowledge, options and capabilities as well as possible company policies.

For me, I have a staging server with GIT master branches of all my projects. For a new project, I create an empty GIT repo on the staging server, use Composer to install a new Laravel application and then clone that project to my local development laptop.

After developing locally and pushing the changes up to the staging server, I have a few colleagues test it (beta test). After they've approved (or given feedback, me pushing up more changes and another round of tests), I clone the project to a live server.

Now, this set up involves you having access to two separate servers (just for ease of configuring and management, it's actually not necessary) and a local development environment. It also assumes you or someone else within your team/company has at least some experience with GIT or some other versioning system.

I mean, the most basic 'deployment' is just FTPing all your files to a remote server and export/import the database using PhpMyAdmin. But again, that's completely up to you and your requirements.

This is a possibility.

But I like to deploy my first final app with the laravel announced recommentations for env and cache and so on. And I like to deploy Updates the same way.

If there is no version control to this, it must be the dirty way.

In that case, the two main ones you want to set in your .env files on the production/live/beta server are:

APP_ENV=production
APP_DEBUG=false

Then, in 'real' production, you can use the following Artisan commands for better performance:

php artisan route:cache
php artisan config:cache
php artisan view:cache

Just take note that you can't use the env() helper function any more after you run config:cache :

If you execute the config:cache command during your deployment process, you should be sure that you are only calling the env function from within your configuration files. Once the configuration has been cached, the .env file will not be loaded and all calls to the env function will return null.

Also, regarding the database question: that's what migrations are for. Say in an update you added a column to the Users table. To properly do this, you create a new migration 'add_dateofbirth_to_users_table' for instance. This migration only includes the date of birth column, nothing else.

Then, once you push your own code changes to production, you only need to run php artisan migrate on your live server to add this column to your database too. This way, you don't have to import/export database structures or data, you can just keep the live database and add another column.