Level 5
Did you run composer install after pulling code from repo? It's because vendor directory remains in .gitignore and you need to pull packages on remote server from composer.lock file.
1 like
May 5, 2016
5
Level 5
From local to Bitbucket to DigitalOcean
Hi,
Let me start by saying that I have never officially launched a Laravel application for production, I have been playing around either locally (Vagrant and Homestead) or in my Digital Ocean droplet. Again I currently have a local and a remote development environment where I can create Laravel projects for practicing and testing purposes. The one thing that I have never done is deployment using Github or on my case Bitbucket (I have used FTP for my static sites).
Now, let's pretend for a moment that I created a Laravel project locally and I just want to upload it to my server /droplet (Digital Ocean) for testing purposes ONLY, I will be using Bitbucket as my central repo. What are the files that need to be modified in order to make the local project work on the remote server?
This is what I did that didnt work.
- Created project in my local machine, which was working fine.
- Committed to Bitbucket.
- Cloned the repo from Bitbucket in my remote server.
- Went into the project and ran
php artisan serve --host=youripaddress --port=8000(normally this works fine with projects created in my remote server).
But I got the following error when I tried to view the page.
RuntimeException in /var/www/my-playground/bootstrap/cache/compiled.php line 7706:
No supported encrypter found. The cipher and / or key length are invalid.
I know I'm probably missing something very basic but I honestly don't know. All of the videos I have watched show how to deploy using deployment services such as Envoyer, Fortrabbit etc. but I'm not ready to pay for these services since I don't have any projects to justify the expenses.
Level 47
A lot of things you maybe didnt do:
- Install php dependencies by running
composer update - Install front-end dependencies by running
npm install - Create a .env file that contains database info, app key, etc.
- Actually set up your server.
artisan serveis ok for development (at least sometimes) but is not designed for production. You need to set your server up and make sure your url points to it.
1 like
Level 5
It works now. Here are the steps.
- Created project in my local machine.
- Committed to Bitbucket.
- Cloned the repo from Bitbucket in my remote server.
- Renamed .env.example to .env (just make sure you have a .env file).
- Generated key by running
php artisan key:generate. - Ran
composer install. - Ran
composer update(I'm not sure if this is needed). - Ran
php artisan serve --host=youripaddress --port=8000 - Viewed in the browser
http://yourIPAddress:8000
Question: @zachleigh - Can you please clearify your last statment?
- Actually set up your server. artisan serve is ok for development (at least sometimes) but is not designed for production. You need to set your server up and make sure your url points to it.
Are you saying that we shouldn't use artisan serve in our remote-servers period or you just advising that it is not meant to be a permanent solution to serve your page?
I know that for production sites in Nginx, you would need to create a server block, I did this once already (for practice purposes).
Thank you all for your help.
Level 47
@fsdolphin
As far as I know, artisan serve is simply a wrapper around the built in php server. You can read about it here. At the top of that page is this warning:
Warning
This web server was designed to aid application development. It may also be useful for testing purposes or for application demonstrations that are run in controlled environments. It is not intended to be a full-featured web server. It should not be used on a public network.
Dire. The built in server is singled threaded meaning that it can only do one thing at a time. So if you have more than one or two users on the site, its going to brick up pretty fast. So yeah, I wouldnt use this in production.
I also stopped using it in development because it does some things a little differently than a real server does (I dont know what) and that tended to make deployment a little more difficult than it should be. I seemed to always run into the 'but it works perfectly in development!' scenario which is really frustrating and makes zero-downtime deployment impossible.
The only time I use artisan serve these days is for showing or testing things out quickly. For any serious project, I develop in the exact same environment that I deploy on, for me that is currently Ubuntu 16.04 using Apache.
1 like
Level 5
Thanks a lot for your help.
Please or to participate in this conversation.