fideloper

It's likely that you need to update your Site within Forge and set the Web directory to /public.

When editing/viewing a Site within Forge, that option is in the Meta section.

This tells Forge to update Nginx to set the correct root (document root, the public web root directory) for the Laravel code base.

It's likely that you need to update your Site within Forge and set the Web directory to /public.

When editing/viewing a Site within Forge, that option is in the Meta section.

This tells Forge to update Nginx to set the correct root (document root, the public web root directory) for the Laravel code base.

Is it as simple as setting up the first? So, I install my application on another server, and set up the Queues?

Yes!

You have some options:

1. If your server resources are under-utilized, you can add more workers to your one server (multiple things running php artisan queue:work ..., or if you're using supervisor, increase the number of processes in the configuration).
2. If you need more workers but can't run them all on one server because of server resource usage, you can use multiple servers.

Caveats to multiple servers:

1. All servers need access to the same database instance (and likely same cache if using redis/memcached). This likely means making sure the 2nd server can reach the database on the first server. Forge can help you out there, it has settings for allowing connections to/from each server on certain ports.
2. On the 2nd server, assuming it's only used for workers and not for accepting web requests, you can disable nginx so it won't accept web requests (or even use the ufw command to disallow HTTP(S) connections on port 80/443).

The php command is likely actually running “php-cgi” and thus running php as a web request (instead of running “php” the command line client).

There likely is a php-cli command or similar available to use instead:

e.g. php-cli artisan list

Just as a sanity check - Are your app files actually in the default directory?

The mail() function is likely using the sendmail option (which is a command/binary on the server your application is hosted on, often something like /usr/sbin/sendmail).

However you're attempting to make a SMTP connection over the network. I can't say if that's to the same mail server or not as I don't know your server setup/hosting provider.

My point is that the 2 aren't really equivalent tests - the mail() option working doesn't mean connecting to a mail server over the network will work (especially if that smtp server is on a different server - altho it sounds like this is all one server?). An equivalent test would be to use MAIL_DRIVER=sendmail in your Laravel config.

That being said, the smtp option may be better for reasons related to ensuring your emails aren't put in people's spam box (which is a great reason to use Mailgun or another provider instead of your local server's mailbox. I can't overstate that - definitely use a mail service if you can).

That being said, try testing out the connection to that smtp service using the telnet command:

telnet mail.[mydomain].com 587

You may get more information that way. Here's a link that provides some info/commands you can try to run to authenticate and send an email over SMTP (this will be the equivalent of what Laravel is trying to do via the email libraries when using the smtp driver): https://www.ndchost.com/wiki/mail/test-smtp-auth-telnet

Is it as simple as setting up the first? So, I install my application on another server, and set up the Queues?

Yes!

You have some options:

1. If your server resources are under-utilized, you can add more workers to your one server (multiple things running php artisan queue:work ..., or if you're using supervisor, increase the number of processes in the configuration).
2. If you need more workers but can't run them all on one server because of server resource usage, you can use multiple servers.

Caveats to multiple servers:

1. All servers need access to the same database instance (and likely same cache if using redis/memcached). This likely means making sure the 2nd server can reach the database on the first server. Forge can help you out there, it has settings for allowing connections to/from each server on certain ports.
2. On the 2nd server, assuming it's only used for workers and not for accepting web requests, you can disable nginx so it won't accept web requests (or even use the ufw command to disallow HTTP(S) connections on port 80/443).

You don't need to do anything extra - forge takes care of:

1. Setting up firewalls (it uses ufw, which is a wrapper around iptables)
2. Setting up Fail2ban (configured to block connections for a time period after too many failed ssh attempts)
3. SSH authentication settings (only allow ssh authentication via ssh keys, instead of passwords)
4. Enabling auto updates, including security patches

These are the big things to setup. There are other things, but in general these get you 90%+ of the way there. There are only a few other technical things you may want to do (selinux or apparmor, but the effort is often not worth it. Setting up a sever per app instead of using shared app servers is another security measure. You can even setup of 2fa for SSH logins!).

Most other security measures are "human" things like having access policies about who can access what servers, or rotating SSH keys and ensuring people have updated key when they need them. That gets pretty high-effort and is usually not done in situations without having a medium/larger team.

You don't need to do anything extra - forge takes care of:

1. Setting up firewalls (it uses ufw, which is a wrapper around iptables)
2. Setting up Fail2ban (configured to block connections for a time period after too many failed ssh attempts)
3. SSH authentication settings (only allow ssh authentication via ssh keys, instead of passwords)
4. Enabling auto updates, including security patches

These are the big things to setup. There are other things, but in general these get you 90%+ of the way there. There are only a few other technical things you may want to do (selinux or apparmor, but the effort is often not worth it. Setting up a sever per app instead of using shared app servers is another security measure. You can even setup of 2fa for SSH logins!).

Most other security measures are "human" things like having access policies about who can access what servers, or rotating SSH keys and ensuring people have updated key when they need them. That gets pretty high-effort and is usually not done in situations without having a medium/larger team.

What you decide to do here depends on your use case.

For local development, mounting volumes is often required so you can have code on your local machine that the containers can see.

A note about PHP-FPM with Nginx: The most common Nginx configuration to use with php-fpm actually requires that Nginx "sees" the *.php file on the server before it decides to send it to php-fpm instead. If it doesn't find the file, it returns a 404 error. This is why if you have Nginx and PHP-FPM in separate containers, they both often need volume mounts.

I tend to install php-fpm and Nginx in one container for this reason. See Vessel for an example of that.

For production, code is often built into a Docker image (via COPY), and that container can then be deployed wherever based on that new image with that code.

I do that method, and tag each new image with the commit sha (and "retag" the latest image as tag latest - so the same image is tagged twice). This way I have a history of built images at each commit sha.

Hope that makes sense!

I'm looking into this also. You should note that sending logs via monolog to CloudWatch comes with a small time penalty while the code sends logs to CLoudWatch via it's HTTP end point (potentially on every web request, but it depends on how much logging you do).

I'm currently looking into the AWS CloudWatch agent, which is a program that runs on the server and can tail the log files / send them to CloudWatch (in addition to collect other metrics, altho I plan on only using it for collecting logs).

The benefit is that it doesn't add time to a web request (runs outside of PHP), but the drawbacks that I haven't yet determined might be:

1. Server setup / configuration setup (alleviated if you automate setting up your infrastructure)
2. I haven't yet determined if I need to adjust the log format for laravel/nginx logs to be parsed by CloudWatch